One of the greatest myths of system-level design is the belief that analysis goals can be identified after models are constructed. This is akin to asserting that you’ll know what you need when you see it. This post hoc approach has never and will never result in successful design activities where complex systems are involved. System-Level analyses goals must be reflected in the specification.

System-level modeling goals must reflect the overall system design goals. Our case studies involve three different domains that require three different modeling architectures. Our first system’s primary requirement is correctness. Thus, models will concentrate on representing functional requirements similar to existing hardware description language (HDL)-based design processes. Our second system’s primary requirement is again functional correctness, but in the context of a power constraint. Thus, the models not only reflect correctness conditions, but account for interactions between functional requirements and performance constraints. The final system also involves performance constraints in the form of access control requirements. Here the objective is not defining a system, but exploring implications of a system design.

In each case study, the models developed reflect design goals as necessitated by the complexity of system-level design. Rosetta provides modeling support for each activity as reflected by the case studies. In each case, heterogeneity and model composition play a dominant role in the modeling activity.

Knowing what the analysis goals are leads to identifying the necessary system models and their associated domains. The key is identifying the best domain for each model. Two equally important observations play key roles here: (i) the most natural domain for each model and (ii) relationships between domains in the domain semi-lattice. Using the most natural domain is the ideal approach. However, if interactions do not exist between domains, or if existing interactions are weak, analysis can be made less difficult by choosing strongly interrelated domains.

Full system-level models will virtually always contain models representing functions, effects on system resources, and constraints on system resources. Functional models typically represent requirements, or “what” the system is to do, and implementations, or “how” the system achieves its goals. Models of effects on system resources map functional behavior to impacts on constraints. For example, a power model would map functional behavior to power consumption, a security model would map functional behavior to resource access and usage, and a synthesis model would map functional behavior to utilization of computing resources. Finally, constraint models represent the resources available to the system. They represent the conditions the system must operate under. For example, a power constraint indicates how much power a system may consume, a security constraint indicates access control requirements on system resources, and a synthesis constraint indicates available computing resources.

In some cases, the most appropriate modeling domains will not exist in the domain semi-lattice. When this occurs, new domains and interactions must be constructed. This should always be done by extending an existing domain, even if the only domain applicable is the static domain. The easiest mechanism is defining an engineering domain. Adding new specification vocabulary to an existing engineering domain or to a model-of-computation domain is a reasonably straightforward process, typically involving writing new functions and defining types. If an engineering domain cannot be defined directly, then a model-of-computation domain may be defined by either extending an existing model-of-computation domain or refining a unit-of-semantics domain. Defining a new unit-of-semantics domain should be a last resort and only considered when dramatically new domains are required.

Now the modeling task begins. The systems designer must construct each of the basic models. Most of these models can be constructed in some degree of isolation. However, it is critical that points of interaction between models be considered. These include interfaces and visible quantities exported from each model. For example, when modeling power consumption, it is important to think about how power will be referenced from each appropriate model. Although the functional model will have no observable power property, the power constraint and power consumption models must. Furthermore, the observations must be represented to facilitate information exchange between models.

With the basic models in place, interactions are used to compose them and perform the desired analysis. By choosing domains early in the design process with well-defined interactions between them, functors, translators, and combinators are available to compose models. If this is not possible, interactions must be defined for the specific design problem.

Choose the domain most appropriate for performing analysis. This may be the domain common to the majority of models or a domain for which excellent analysis tools are available. In most cases, this choice is made when the modeling domains are chosen and impacts the structure of the entire modeling process.

Use functors to move models to the analysis domains. If interactions between domains exist, then they are easily used individually and in composition to move move models. If interactions between domains do not exist, then following this path requires the user to write their own interactions.

Use products to combine models whenever two or more models must be concurrently satisfied. Models should be composed when and where most appropriate. The composition does not need to wait until all models are in their final domains. Remember, this does not generate analysis models nor does it fully implement interactions between domains. It bundles models together, indicating they must be satisfied concurrently or in other combinations, as indicated by composition operators.

Use combinators to generate analysis models from product and co-product models. These combinators move composite models from modeling domains to domains associated with analysis tools. At this point, analysis is performed to begin understanding system-level effects of local design decisions. If the processes of model transformation are fully automated, then different design options and analysis criteria can be selected.