SHE/POOSL Website
Industry faces the challenge of designing hardware/software systems of increasing complexity within ever-shortening design times. Commonly, the design process involves considerating several design alternatives for realising the desired functionality. Early in the design process, the choice for a specific design alternative may have a deep impact on, for example, the performance of the final implementation. To assist the designer in taking well-founded design decisions, system-level design methodologies can be applied. System-level design methodologies are frameworks for structuring the earliest phases of the design process with the intention to find a feasible design within minimal time. They focus on constructing models that allow the analysis of functional and non-functional properties before actually realising the system in hardware and software.
Software/Hardware Engineering (SHE) is a model-driven system-level design methodology that allows analysing both correctness and performance properties of design alternatives based on models. To construct such models, SHE provides the use of different Modelling Languages. The actual evaluation is based on the application of several techniques for Formal Verification of correctness properties and Performance Analysis. The designer is assisted in constructing models and applying the analysis techniques with various guidelines and modelling patterns. A key feature of the SHE methodology is its foundation on formal methods, which ensures that the obtained analysis results are unambiguous. Recently, SHE has been extended with guidelines and synthesis techiques for Generating Real-Time Control Software, which is again based on formal methods to ensure that properties in a model (including timing properties) are being preserved by the generating software. Finally, to enable an effective and efficient application of the modelling languages as well as the analysis and synthesis techniques, SHE is accompanied with a set of user-friendly computer Tools. A consice overview of the SHE design methodology and its main features is discussed in the paper entitled Software/Hardware Engineering with the Parallel Object-Oriented Specification Language" presented at the 5th ACM/IEEE International Conference on Formal Methods and Models for Codesign (MEMOCODE) in 2007.
The remainder of this page contains some information on what System-Level Design is, why Modelling is Difficult and why Formal Methods are useful in the context of system-level design.
The research presented on this website regarding performance modelling and analysis as well as regarding code generation for real-time control have been supported by PROGRESS, the Program for Research on Embedded Systems and Software of the Dutch organisation for Scientific Research (NWO), the Dutch Ministry of Economic Affairs and the Technology Foundation STW through the funding of projects EES.5202 Modelling and Performance Analysis of Telecommunication Systems and EES.5413 Internet-Based Monitoring and Control of Embedded Systems respectively.
The trajectory from product idea to tangible system involves the development of a desirable but a priori unknown realisation based on an initial specification. Such a specification prescribes in a concise way the requirements for a system, its functional behaviour and other characteristics. Often, a number of alternative solutions can be proposed for realising the desired functionality. Such design alternatives may differ in various ways, ranging from differently partitioning the system in components to using other algorithms for performing a certain functionality. The virtually unlimited number of all possible design alternatives that can be realised with known technology is usually referred to as the design space.
Only a limited number of designs in the design space can satisfy all requirements for a system. These include functional and non-functional requirements. Functional requirements concern the correctness of the behaviour exposed by a system. An example of a desirable correctness property is the absence of deadlock. Not succeeding in meeting functional requirements may result in failures. A design is said to be correct if it satisfies all functional requirements. Non-functional requirements are related to the remaining characteristics of a system. Examples are cost, maintainability and performance properties like latency and throughput. A correct design that also satisfies all non-functional requirements is called a feasible design. The design process can therefore be described as the search for a feasible design.
A common approach for managing the complexity of designing hardware/software systems is to distinguish a number of design phases. Consecutive design phases focus on refining the amount of detail with which the question of how to realise the specified functionality such that the desired non-functional properties are satisfied is answered. It is also common to say that the level of abstraction from implementation details decreases. The relation between design phases and levels of abstraction is often explicitly indicated by using the term design level instead of design phase.
At each design level, several options can be considered for adding details on how to realise certain functionality. This implies the need for exploring design alternatives and deciding which one most likely leads to satisfying the requirements (in an optimal way). Figure 1 shows a 3D-version of the so-called abstraction pyramid. It illustrates how design decisions taken at consecutive levels may lead from the initial specification for a system to its realisation. The concepts for realising the functionality thought of when starting from the initial specification immediately restrict the number of designs that can result from the design process. This is because certain designs are based on concepts that are not considered during the first level. Decisions taken during consecutive levels continue to restrict the number of possible resulting designs until a single realisation is found.
Design decisions taken earlier in the design process have in general a bigger impact on the properties of the final realisation than those taken during later phases. For example, wrongly choosing between concepts like a bus-based architecture or a switch-based architecture when designing a router for some communication system can have more serious consequences in not satisfying the performance or cost requirements compared to choosing wrong physical dimensions of the system's output connectors. One reason for the high impact of wrong design decisions made at higher levels is that a higher reduction in the number of possible resulting designs is obtained due to these early decisions. Notice also that in case a wrong decision is made, there may be no feasible designs attainable anymore. Correction of such design errors is particularly expensive when they occurred early in the design process and remain undetected until later design phases. This is due to the necessity of redoing (parts of) the design steps performed after taking the wrong decision.
Basically, system-level design is an umbrella term for the earliest design phases. It is concerned with investigating whether (alternative) conceptual solutions for realising the desired functionality will lead to satisfying the non-functional requirements if such concepts would be used as starting point for realising the system. Structured approaches for performing system-level design are of utmost importance for tackling the difficulty of making the right decisions during the earliest design phases and hence, for minimising design time.
As indicated in Figure 1, each design phase involves developing one or more design alternatives for realising certain functionality. To investigate the feasibility of design alternatives without actually realising them, models can be used. A model is an approximate representation of a system, which is intended for the analysis of certain properties. Such a model inherently abstracts from many implementation details (which cannot all be known during the design). Hence, they are cheaper to create, debug and simulate compared to a full description intended for (automatically) synthesising a design. In order to allow founding design decisions based on analysis results obtained using models, they should have the following properties:
The reason why modelling is difficult can be explained based on the first two properties. To properly found design decisions, representative results should be obtained from the model without considering all details. Abstraction agrues to disgard irrelevant details, whereas adequacy requires to include all aspects that are relevant. The conflicting objectives of abstraction and adequacy make that the construction of appropriate models is difficult (i.e., developing a model constantly involves considering whether an aspect must be included or not). In fact, developing models is the hardest part of system-level design, because the adequacy of a model can only be confirmed after actually having the system realised.
The requirements for models constructed during system-level design (see Modelling is Difficult), have important implications for modelling languages that can be used for writing down models: they should be expressive. The expressive power of a modelling language determines how intuitively, succinctly and readable the provided primitives enable representing the characteristics of hardware/software systems. Intuitiveness, succinctness and readability are indispensable for accelerating the validation of models, which usually represents the most time-consuming part of system-level design. Important aspects that determine the expressive power of a modelling language include the following:
Formal modelling languages have some useful properties that enable improving their expressiveness. A modelling language is called formal in case the semantics of its primitives is defined mathematically. A formal semantics advances the compositionality of primitives because the semantics of combinations of them can be mathematically derived from the semantics of the individual primitives. A formal semantics has three other essential advantages: they provide the appropriate means to define rigorous frameworks that