What's the best way to implement a configuration of a product that has over 2000 attributes, so that we can also print a table of the config using RPE?
One answer
If this is just to compare the design with the actual system config, I'd just create a textual requirement in DNG with those attributes listed. To simplify the "compare" operation, I'd make the format of that text match as closely as possible the way those attributes are defined in the actual system config.
Comments
We have a product that will have a "recommended configuration" and "current actual configuration". There are over 2000 different settings that can be changed on these configs. Are there any other jazz tools that would accomplish modeling this and also interfaceable with RPE to print a comparison report of the two configurations? Thanks!
What constraints are there on how the "current actual configuration" is specified? For example, can it just be a text-valued requirement with one line per configuration setting? Or is it required to be in some particular format?
We'd rather each setting have it's own 'attribute', as some may require us to have some enumerations and such.
The approach I would recommend for something like this would be to use a variant management system such as pure::variants ( https://www.pure-systems.com ). That would allow you to both model your system, as well as add constraints.
Comments
Geoffrey Clemm
FORUM ADMINISTRATOR / FORUM MODERATOR / JAZZ DEVELOPER Aug 02 '21, 12:30 p.m.Can you provide more insight into how those 2000 attributes are used (possibly, some examples)? For instance, do you have a product family with 2000 variation points, where a particular product selects a value for each of those variation points? And if so, how are those values used ... just for reporting, or for configuring the product at design, build, or run time? The best way to implement those 2000 attributes will be determined by how you then plan on using those attributes.
Logan Torres
Aug 02 '21, 12:38 p.m.Those 2000 attributes are basically different options for that specific config of the system. We will be using these attributes to compare the config in the model/dng to how the actual system config is setup.