Fraunhofer Institute for Integrated Circuits IIS, Division Engineering of Adaptive SystemsToday’s electronic systems are an increasingly complex combination of hardware and software components. They contain an ever-expanding range of functions, require more computing power, have to operate a wide variety of interfaces, comply with standards, and be compatible with established market solutions. The obvious multitude of requirements should be incorporated into the system design at a very early stage. The later decisions are changed in the design, the more costly their implementation becomes, writes Dr. Roland Jancke, Head of Design Methods.
#EAS.voices: Model Based Systems Engineering
Accommodating all the new functions and expanded capacity may require a larger silicon area. In other respects, the trend is toward greater integration, be it to save installation space, reduce energy consumption, or combine specific technologies. This higher density of components leads to additional multi-physical effects, such as electrothermal and thermomechanical interactions. As for safety-critical applications, there are further requirements in the areas of safety and security as well as for the reliability and robustness those areas need. Finally, the resulting solutions must be marketable, which means that the costs of individual components and decisions must be taken into account starting at the design stage.
Such a multitude of requirements should be incorporated into the system design very early on. The later in the design process that decisions are changed, the more costly it becomes to implement them.
In addition to validating functionality, this phase of system development involves making relevant architectural decisions. These involve defining the structure of the system — i.e., dividing the overall system into subsystems. Which parts of the system are to be realized in software and which in hardware is also decided at this early stage of development. When it comes to hardware, there are again a number of variants in play, such as microprocessor, microcontroller, FPGA, ASIC, or a combination of these. Especially when dividing a highly complex hardware implementation into several ICs, or into several chiplets within a system-in-package, it’s crucial to find a good split into subsystems and to define their boundaries as appropriate. To this end, developers must look at how closely the subsystems are linked at the interfaces with regard to data exchange. What’s the required bandwidth? How many channels are needed, and with what clock frequency? What transmission latency is permitted?
Making these kinds of fundamental decisions regarding the partitioning of the system and choosing the technology for the subsystems must be done at an early stage and in an informed manner. This means being familiar with the relevant requirements and making the selection with knowledge of the consequences. One way to prepare these informed decisions is to consistently apply the principles of model-based systems engineering (MBSE) in system development.
UML diagrams depict structures and processes
This term has been used in the field of software development for many years. The MBSE approach is based on UML diagrams, which depict structures and processes independently of an implementation language. With this as a basis, software implementation can then be automatically coded. Hardware has always been developed with the help of models, starting with the first transistor models and simulation tools such as SPICE. The challenge of modern system development is to bring both worlds together and create an integrated model of the specified system very early on in the development phase. Ideally, such a model also moves away from the question of which parts are implemented in hardware and which in software, focusing instead on the functions to be realized.
This kind of model-based approach offers multiple benefits right from the outset. For example, the abstract system model can be used as a reference for implementation; as development progresses, parts of the model can be refined and replaced by more detailed views. System models can also be used to communicate with suppliers. In this case, they fulfill the purpose of an executable specification in order to avoid misinterpretations of textual descriptions of a function. Conversely, some device manufacturers already require a model of the component from their suppliers, so that they can perform simulations in advance to test the interaction of the individual parts when executing complex functions on the device. Hardware models also serve as virtual prototypes for software developers, allowing them to start development much earlier, long before the real hardware is available, thus shortening the time to market.
Check of requirements for completeness
Another benefit of MBSE is that it can be started as early as the requirements engineering phase. Once requirements have reached an initial level of formalization, they can be understood as models. This makes it possible to test the completeness and consistency of the requirements and also to establish a link between the formulated requirements and their implementation in the system at any time for purposes of traceability.
At the same time, system models can be generated directly from formalized descriptions of the requirements as a starting point for the developments described above. In addition, they can be used to automatically generate test benches with which to check that a requirement has been met. This establishes the link from system design to system validation, ultimately closing the development cycle by documenting the fulfillment of requirements and thus implementing consistent quality management.
Overall, the complexity and heterogeneity of today’s hardware-software systems require new approaches to development and quality assurance processes. The consistent and integrated implementation of MBSE extends from the requirements to the documentation. It can shorten the time to market for a product, and it plays a key role in avoiding errors in communication with suppliers or clients and in the implementation of systems.