Characterization of model based development of embedded control ...

Characterization of model based development of embedded control systems from a mechatronic perspective; drivers, processes, technology and their maturity Martin Törngren and Ola Larses Division of Mechatronics, Dept. of Machine Design, KTH - {martin, olal}@md.kth.se Abstract: Model Based Development (MBD) and many similar terms flourish in current literature and conferences, indicating the high industrial and academic interest in this topic as one key technique for promoting quality and cost-efficiency in the development of embedded systems. However, MBD is currently interpreted and approached in many different ways. Many companies are still hesitating towards the introduction of MBD, while others are applying MBD – however, mainly as a basis for partial subsystem development. In this paper a definition of MBD is provided. Based on this definition the drivers, opportunities and problems facing MBD are investigated. A framework is provided to understand and compare different MBD approaches. We discuss adoption of MBD in different fields of engineering and, relating to the Capability Maturity Model, present a model of MBD maturity and illustrate its application. The model allows explanation of potential problems perceived when introducing MBD and can thus hopefully be an aid when introducing MBD or when analyzing problems with an MBD approach. The target of the analysis is disciplines related to embedded control systems, and throughout the paper examples from automotive applications are given. Problems related to MBD are concluded to be the result of mismatches between the process maturity level, the drivers and the supporting technology.

1

Introduction

The development of machinery is still undergoing the challenging transition from a pure mechanical engineering exercise to an integrated mechatronics process. In this transition, the use of embedded control systems (ECS) is radically changing the products they are embedded into. The added dimension of explicit and flexible information transfer and processing, implemented through electronics and integrated into the mechanics, on the one hand enables improved performance and entirely new functionality to be implemented, but on the other hand introduces a range of new engineering issues. The integrated and distributed functionality introduces new, and sometimes hidden, dependencies among components. Further, multidisciplinary competence in product development is required. In line with this, new development processes and organizational structures must be established, matching the new product structures [Eppinger & Salminen, 2001]. It is typical in engineering disciplines to traverse through a learning curve evolving over ad hoc approaches based on trial and error, tacit knowledge and feasible designs to more mature stages characterized by analytical synthesis methods, model building, simulation and computer aided engineering (CAE) tools, striving for more optimized designs. This process have been described by Mortensen [1999] based on a model by Duffy and Andreasen [1995]. Increasingly complex products clearly require increasingly capable tools and complexity control by use of abstraction and structuring. It is well known that a successful introduction and use of model based development (MBD) is one essential ingredient in order to achieve cost-efficient development of dependable complex systems, see for example Stevens et al. [1998]; Oliver et al. [1997], and Jeutter & Heppner [2004].

Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

1

However, while we find extensive use, and a harmonized view of MBD in areas such as mechanical engineering, the corresponding landscape for embedded control systems and embedded software is quite confusing, indicating a rather immature state of the area. The use of the term MBD, or related terms, in different contexts, for different purposes (e.g. model based design, model based testing or model based diagnostics) and with different techniques, creates a need to better characterize and understand what MBD is, why and when there is a need for it, and how MBD relates to the product itself, the development process and the organization. The cost-efficiency of MBD is sometimes questioned in industry, especially related to software development. Assuming that MBD is an advanced and mature design method, tools and processes seem to promise more than they deliver. To improve the efficiency, it is valuable to achieve a better understanding of how to apply MBD and what the common pitfalls are. In this paper we discuss and elaborate explanations to these questions. Section 2 first provides essential characteristics of embedded control systems and a brief historical background to developments in model based development of embedded control systems. A contextual perspective to MBD and experiences from the adoption of MBD in mechanical and systems engineering are provided in section 3. Section 4 then provides a definition of MBD for ECS. Sections 5 and 6 introduce our model of MBD maturity and illustrate its application. In Section 7 we discuss mismatches in maturity between the supporting processes, MBD technology and drivers. Throughout the paper we give examples mainly from automotive systems.

2

Embedded control systems; characteristics and on the evolution of model based development practice

This study is focused on mechatronic systems, that is, systems which are formed by an integration of mechanical, electronic, software and control system components. Mechatronic systems are further traditionally associated with functionality involving motion, and motion control, of mechanical devices. Examples of such integrated systems include different types of vehicles, medical equipment, robotics and manufacturing equipment. The concept of developing such systems, and achieving synergistic effects from their integration, is often referred to as a mechatronics approach in development [Wikander et al. 2001]. Such an approach conforms to traditional systems engineering and emphasizes codesign and systems optimization. Software, electronics, sensors and actuators constitute key implementation technologies in mechatronic systems. For low-end products, analogue technology can be, and is being, used. However, software is the dominating technology in more complex applications because of its flexibility and cost-efficiency. The standard solution today is to use software with microcontrollers (highly integrated electronics devices that include a microprocessor, communication facilities, and digital/analog inputs and outputs). The use of electronics and software within products has given rise to the term embedded systems. For example, IEEE [1992] defines an embedded computer system as: A computer system that is part of a larger system and performs some of the requirements of that system; for example, a computer system used in an aircraft or rapid transit system.


2

Obviously, embedded systems are not limited to mechatronic products; they are used in a variety of other applications including hand-held devices, TV-sets and games. This widespread usage of “embedded systems technology” with widely varying associated requirements complicates the treatment of embedded systems as a field of engineering. Although there is some identifiable core knowledge in the field related to electronics and software, the variety of applications means that the components, development methods and techniques will differ to a great extent [Törngren, 2003]. Apart from the integration and multidisciplinarity, other central characteristics of mechatronic embedded control systems and applications include the following: − Variety of types of functionality. ECS can be seen as hybrid systems, being composed of entities that are best described by continuous-time dynamic systems (or their discrete-time correspondents), finite state machines, and by their combination (that is hybrid). Motion control is one central part of ECS. Although its absolute size e.g. in terms of lines of code typically is relatively small compared to other functionality, the motion control functionality is coming along with real-time constraints, environment dependencies, and safety criticality, further treated below. − Hierarchical structure. ECS are normally structured into a system platform and applications. Responsibilities of the system platform include for example initialization, logging, communication services, drivers for sensor readings and outputs, and error detection. For the application there will be activities such as motion control, diagnostics related to the control, estimation of the environment state, and human machine communication. − Distributed systems. There has over the last decades been a strong trend to connect standalone controllers by networks, forming distributed systems. Another and closely related trend has been modularization, where for example, an electronic control unit is physically integrated into an engine, forming a sort of mechatronic module. Combining the concepts of networks and mechatronic modules makes it possible to reduce both the cabling and the number of connectors, the result of which is facilitated production and increased reliability. Distributed control systems first appeared in process control, and later in the 80s in aerospace, and in the 90s in the automotive industry. A common but very general definition of distributed systems is as follows: Nodes that are part of a distributed system cooperate to accomplish a common goal. A more fruitful approach is that of discussing how systems are distributed (or decentralized); Enslow [1978] defined three dimensions of distribution according to which a system can be classified. Clearly, there is a need for distributed hardware, but in addition, we may consider different distributions of data and of control (decisions) in the system. Distributed systems are characterized by the mapping problem, i.e. the need to assign functions to different nodes of a distributed system, to define the tasks of the system, and their implementation in software and/or hardware. − Tight coupling to the environment. The tight coupling between the control system and the controlled process is manifested in several ways. Apart from aspects related to physical integration, protection against a harsh environment, and handling communication with peripherals, the control system is also fundamentally related to the controlled process. Typically, models of the environment are used in control design. In many cases, the control algorithms are synthesized from a validated model of the controlled system (model based control systems development). In other cases, the controller parameters are tuned based on the overall (closed-loop) system behavior. For control systems this creates a dependency between the environment and the control system, creating a kind of contract between these two entities. Another type of environment coupling exists with humans Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

3

interacting with the embedded control system. Many control systems for example have an operator “in the loop”. This is typical for vehicular systems, and the situation arises where conflicts can occur – who is deciding the motion of the vehicle at any given point in time? Careful analysis is required and special care has to be given to the human/machine interface. − Real-time constraints. These constraints, which are closely related to the coupling to the environment, arise due to interactions with the environment. From control system specifications, for example referring to required speeds of motion, required precision and time durations, timing requirements on the embedded control system can be derived. For example, the speed (or bandwidth) of the closed loop system will provide requirements on the timing of the controller, including the sampling periods that successfully can be used, and feedback delays and jitter that can be allowed. These latter properties can also be taken into account in the control design. The derived timing requirements constitute an additional contract between the controller and its implementation, [Törngren, 1998]. − Parallel activities and triggering. Since the real world is truly parallel, there is typically a need to describe and handle several parallel activities. A typical control system normally includes both time- and event-triggered activities. In many cases, time-triggering follows naturally from the development of discrete time (sampled data) functions. Sometimes the controlled process is not discrete in time. This is the case for inherently sampled systems, one example being control of injection in a combustion engine; the point in time of injection depends on the speed and angular position of the engine parts [Åström and Wittenmark 1990]. Event-triggered functions thus include those who are inherently sampled and other functions who are not dictated or preferably implemented as periodic activities. − Resource constrained implementations. Embedded control systems are often highly resource constrained; this is for example the case in the automotive industry where the large series produced provide very strict cost constraints on hardware. In such applications, trade-offs between the system behavior (quality of service) and the resources required (processing, memory and power) is essential. − Dependability requirements. Applications using ECS often have a long life time, and are thus typically associated with strict requirements related to reliability and availability. In addition, the applications need to be maintained and this can include enhancements of performance/functionality during the product life span, and even taking away functionality during its life span. Of course these possibilities increase with the use of software. Moving systems can be dangerous, vehicular control systems are therefore normally safety related. Not only is the control system required to operate reliably; the design of the system and its context must be carefully analyzed to consider what might go wrong, and what the system should do in such cases. In safety critical control systems it is common to use diagnostics and analytical (model based) redundancy both for detecting, and to some extent for handling errors. The robustness of control systems can also be utilized to handle certain failures. Security is becoming of increasing importance because of the possibilities and relative ease with which embedded control systems behavior can be modified, e.g. by replacing memories/chips or by network intrusion. Because of this, protection against intrusion is an important issue in ECS. All in all, the use of embedded control systems has paved the way for large improvements of machinery in terms of improved performance, flexible tailoring of product variants and by enabling completely new functionality such as for example active safety functionality in cars. As a consequence, and as partly touched upon in section 1, product complexity is becoming a Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

4

crucial issue in system development. Systems integration is today a serious problem in the automotive industry. This increased product complexity calls for more mature engineering approaches including the use of model based development.

2.1

A brief review of the historical evolution of MBD for ECS

To cope with the system complexity efficiently there has over the years been a Level of abstraction constant trend to raise the abstraction levels at which the systems are being programmed model based and modeled, see figure 1 which illustrates development this for programming languages. More than 20 years ago the programming of ECS was high-level predominantly carried out using assembly languages languages. Then the paradigm shifted to high-level programming languages with the assembler time idea to provide programmers with more powerful tools. These tools would relieve time Figure 1. Increasing the abstraction levels the programmers of the burden of knowing the implementation hardware in detail, thus giving them the possibility to work more efficiently by focusing on the applications (a kind of separation of concerns). During this paradigm shift, concerns were raised whether the compilers would be able to produce efficient and reliable code. Entering the paradigm of model based development, the same concerns are now being raised with regards to code generation from models. Partly reflecting the broad variety of embedded systems, we today find a multitude of programming and modeling languages used in embedded systems development, including for example C, C++, Ada and Lustre on the programming language side, and Simulink, Modelica, SDL and UML on the modelling side [El-khoury et al. 2003]. Relevant to our discussion on model based development it is appropriate to introduce different levels of formality. McDermid [1989] defined three levels of notation for programming languages: − informal (e.g. natural language) − structured (often use graphical notation, but may have limitations in definition of semantics making analysis difficult) − formal Modeling and programming languages are often also defined using the concepts of syntax and semantics. For example, Sztipanovits and Karsai [2001] define a modeling language to be composed of an abstract syntax, a concrete syntax and its interpretation. The abstract syntax defines the concepts, relationships, integrity constraints and model composition principles available in the language, thus determining all the syntactically correct models that can be built. The concrete syntax defines the form of visualization; graphical, textual or both. The interpretation defines the meaning of the entities of the language and the resulting models, i.e. its semantics. It should be apparent that there are similarities but also differences in emphasis between modeling and programming languages. One common denominator for programming and modeling languages is the desire to provide readable and flexible descriptions that are formal enough to enable analysis and synthesis. However, while programming languages are mainly Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

5

intended to support synthesis as detailed design in terms of constructing programs, modeling languages, on the other hand, provide abstractions of complex systems with the main purposes of describing such systems and/or to be able to analyze such systems. These different purposes (analysis and synthesis) are reflected in the provided abstractions/entities and interabstraction relations. The use of model transformations, and specifically synthesis through code generation, makes the gap between the two concepts smaller. The introduction of computer aided engineering (CAE) tools related to MBD in control engineering and for software is sketched in Figure 2. Of course, such tools can have a variety of purposes, ranging from project management to product testing. The scope considered here and as illustrated in Figure 2 is mainly concerned with support for analysis and design. Tools for computer aided control engineering (denoted CACE, or CACSD) and tools for computer aided software engineering (CASE) have evolved rather independently. For software modeling, early tools included variants of Structured Programming (e.g. by Jackson and by Yourdon), allowing graphical models of software to be developed. In the mid 90s, the various object-oriented approaches were standardized and the Unified Modeling Language appeared as a standard. While this was an important standardization effort, such tools and tools for structured programming were still semi-formal, and efficient code generation was not available. Today, more efficient code generators and model level debugging is available from commercial tools. Also, efforts like UML2/MDA [OMG, 2004] have the intention to promote platform independent design. Advances in formal methods in computer science are slowly making their way into tools and industrial usage, enabling verification of software correctness prior to deployment. CASE:

Structured programming/OO

CACE:

Block diagrams/ equation solvers

70-80s (Generations: 1st

UML

Code generation /high end systems

UML2

Standard dev. approach

mid-90s 2nd

2000s 3rd)

Year

Figure 2 A historical view of the evolution of CASE and CACE tool development

In parallel and rather independently of this, automatic control systems researchers were developing tools to bridge the gap from control theoretic algorithms and block-diagram models to real-time implementation. In the late 80s, tools for code generation – especially for so called rapid control prototyping - came available. Applications using commercial code generators were used already in the 90s, but the last couple of years have seen a dramatic increase in the use of code generation, especially in the automotive industry. CACE tools support a large body of control theoretical approaches for analysis and synthesis of dynamical systems (both continuous and discrete-time). In addition, because of the hybrid nature of control systems, computer science techniques for formal verification are also emerging in CACE tools [Ranville 2004]. The evolution of both software and application specific programming languages reflect the need for increasing the level of abstraction. A related area is that of electronic design automation used to refer to CAE tools for electronics design and manufacturing. This area has similarities to mechanical CAD and CAM and is also a mature discipline. On the design side, model based design tools can Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

6

produce hardware description languages such as VHDL enabling a broader implementation scope including both processors and various programmable logic circuits.

2.2

A snapshot of industrial practice in modeling and programming

For control systems development in the automotive industry, model based development is in many areas already the standard design approach; however, the adoption varies between different companies and subsystems (the Artist roadmap [Artist 2004] gives a good complementary overview to this section). CAE tools supporting modeling, simulation and rapid control prototyping (RCP) largely facilitate development even without available mechanics and electronics hardware, and provide means for control system verification and validation, in the lab, as well as in-vehicle [Jeutter and Heppner 2004]. Model based testing is also becoming increasingly used, where one example is the use of hardware in the loop simulation for both subsystem as well as system integration testing. In a hardware in the loop simulator, the computer control system environment (i.e. the vehicle, road, driver actions as well as other relevant environment entities) is simulated in real-time, enabling system testing.

Modelling/programming

E.g. Simulink/Stateflow

E.g. UML tool

E.g. OS synthesis Software integration framework I/O drivers Software platform (OS, com., drivers) Hardware platform

Figure 3 Software layers and tools for ECS development

Figure 3 provides a simplified view of a typical layered structure of a control unit (a so called Electronic Control Unit – ECU) in an embedded control system. Lower levels are typically programmed using C and some assembly language, including hardware drivers, real-time operating systems and communication drivers/low level protocols. Applications are increasingly developed using model based development environments such as UML and Simulink/Stateflow. Then, either the resulting design model is manually translated into Ccode, or code generation is used to integrate the resulting C-code with the platform. The use of code generation has increased significantly only over the last few years in the vehicular industry. For example, Volvo cars is using Simulink models in the design of power train controllers and carry out simulation and rapid prototyping using these models. Code generated from the models is used in the final product [Lygner, 2002].

2.3

Discussion: Comparing characteristics of ECS and mechanical engineering

While we believe that many experiences can be borrowed from more established engineering disciplines, it is also important to discuss differences. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

7

One reason for the relative maturity of mechanical engineering is probably due to its homogeneity. Consider for example the fact that that CAE tools for CAD and finite element analysis are equally well applied to design and analysis of the mechanical part(s) to be developed as well as to the tool(s) required to manufacture the part. The vice versa is not true for software where completely different tools are used because of the constraints of embedded systems (as described in chapter 2). On the other hand, it should be noted that software models are very close to, and can be directly translated into implementations. In addition, mechanical engineering and related disciplines are focused on mechanical components governed by physical laws. For example, the conservation laws regarding energy and material flow apply to mechanical systems. Forces exerted by one body on another are always bi-directional. The physical laws will provide many of the constraints for ECS (as discussed early in section 2.). Although these physical laws also govern low-level behavior of electronics, there are much fewer and more implicit constraints governing the design of embedded software, and the corresponding theory is not as well developed (or at least not so well disseminated and practiced). Embedded software will contribute to reduce the constraints on the information flow within a mechatronic application. The remaining constraints on the embedded system relate to its environment such as the available power and the required timing, and to the implementation technology and its provided speed and memory size. In embedded systems, software is used to codify and implement designs. Software is not by itself a physical entity, meaning that it does not break down or wear. While this only leaves design faults in software, this is not as big a relief as one might possibly expect. First, hardware and software interact in non-trivial ways, and faults in hardware can propagate to and influence the way the software instructions will behave. Moreover, the nature of software makes it far too easy to in a novel way develop extremely complex, and many times overly complex, designs. This is a drastic difference to mechanical engineering where design related to information flow and processing is highly constrained (thus the corresponding complexity is low) whereas problems instead lie in understanding non-linear physical phenomena. Another difference stems from the traditions of the area and traditions. The ECS area has had an emphasis on technology and to some extent on processes. This corresponds with the observation by Nambisan and Wilemon [2000] regarding software engineering. This more holistic view is better understood in the field of mechanical engineering (more on this in section 3.1). The differences in traditions are also indicated by the separations of the corresponding disciplines (in education and academic research as well as in industry) and in tool support. For example, tools that support management of data and other items in the development of complex systems have emerged independently in mechanical engineering and software engineering, [Crnkovic, 2003].

2.4

Some trends in MBD for ECS

MBD related trends in embedded control systems include the incorporation of formal methods in tools (bridging the gap from theory to practice), development of modeling guidelines, increased tool support for distributed systems and function/platform integration, and standardization of modeling languages, platforms and architectures. Considering the requirements on embedded systems many efforts aim at improving the dependability of these systems. One way of reducing the probabilities for faults in a complex system is to reduce the manual labor and individual freedom included in the development chain. Manual labor is known to be error prone. This means that different initiatives to increase formalization are ongoing. For example, guidelines for C-coding have been issued by the automotive software organization, Misra, and guidelines for models are being developed Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

8

(see Misra, [2004] and Mathworks [2004]). MBD has an important role in this dependability effort; code generation from models is seen as one way to improve software quality [Shigematsu, 2002]. Synthesis can be expected to be introduced at all levels (from drivers over RTOS to applications). In addition, incorporation of state of the art analysis techniques such as model checking into CAE tools is slowly emerging [Ranville, 2004]. MBD tool support for ECS is today mainly limited to single processor systems, however support for distributed systems in model based environments is on its way [Artist, 2004]. Such tools enable functions to be co-designed with the software/electronics platforms they are implemented on. There are very few platform related standards for embedded control systems; the main ones exist currently for communication systems and to some extent for diagnosis and calibration purposes. There are several efforts currently addressing standardization of platforms [e.g. OSAR, 2004]. Standardization is also seen in the field of description languages and includes efforts such as the East-ADL [2004], SysML [2004], and the AADL [2004].

3

A contextual perspective to MBD

Models have always been used in engineering. Models are used implicitly in the mindset of the engineer, in terms of construction of physical models/prototypes, and in terms of symbolic models such as written documents and since the advent of computers by the use of CAE tools. There are several definitions of what a model is (see e.g. Oliver et al. [1997], Stevens et al. [1998], and Nelamkavil [1987]). We here define a model as follows; A model is a simplified representation of a real or imagined system that brings out the essential nature of this system with respect to one or more explicit purposes. Symbolic models are the main focus in this paper. Symbolic models can be further classified regarding their degree of formality, that is, the degree to which they can be unambiguously defined by mathematics. Block diagrams without well defined semantics are an example of non-formal symbolic models. Examples of models rigorously defined by mathematics include geometrical descriptions in CAD and transfer functions used to describe input-output behavior of dynamic systems. However, it is common to require that models are unambiguous such that there is only one meaning for every symbol used. This makes a distinction with respect to natural languages. The main motivations for using symbolic models are as follows (mental and physical models are only related to items 1 and 2 below). 1) analyze a system – thus answering questions about a system. Developing a model can be necessary to develop an understanding of a system, which can be for example a system under design, construction or maintenance. This entails assessment of different qualities of the system – in terms of what-if analysis, thus closely related to system verification and validation. Analysis is also carried out in order to compare alternative solutions and to optimize a system with respect to one or more qualities. 2) communicate a system – thus providing a description of a system. The model can in this case be used to communicate, for example, a chosen design or architecture. The model also documents such a design for potential future reuse. 3) synthesizing a system – thus automating portions of the design. With the use of CAE tools the possibilities to use documented models is largely enhanced with capabilities for rapid prototyping (that is, to have CAE tools more or less automatically construct either a Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

9

physical or executable prototype based on the CAE model) and capabilities for product construction (e.g. in terms of computer aided manufacturing or production code generation). Formal symbolic models (which might also be called mathematical or analytical models) have shown to be very important tools for clarifying and solving engineering problems. In mechanical engineering one often talks about modeling and simulation, rather than model based development, where simulation usually is used in a broad sense of imitating the behavior of a real system by constructing and experimenting with a computer model of the system [Neelamkavil, 1987]. CAE tools have opened the way to new design approaches and for optimization of products. Symbolic models are in a CAE setting often referred to as virtual products, allowing properties and alternative designs to be evaluated prior to the development of physical prototypes. Such efforts have the main aim of “doing it right from the beginning” and avoiding (too many) costly iterations in later development stages. Early detection of inconsistencies and defects implies a much lower cost to correct the design. Thus, used in the right way, MBD will improve the cost-efficiency of development, see Backlund [2000] and Ranville [2004] for examples of this. Related to this, the concepts of virtual products and rapid prototyping often enable concurrent engineering in the development, for example allowing concept evaluation prior to the availability of physical hardware (which can take time to develop). This in principle allows speeding up development but on the other hand creates needs for harmonizing the parallel processes. It is well known from systems engineering that modeling and simulation are not the ends themselves - they should add tractable value. Modeling and simulation are in systems engineering often referred to as a risk reduction technique indicating their use in supporting engineering decisions. Lessons learnt from systems and mechanical engineering also show that all types of models, mental, physical as well as symbolic models, have their role and place, but that that as symbolic, and in particular analytical, models improve, they are slowly displacing physical prototypes, Stevens et al. [1998]. The need for symbolic models and CAE tool support increases as the products become more complex and with more standardized products that increases the value of reuse [Larses & Adamsson, 2004]. Choosing a proper level of MBD in the design approach becomes even more important as the pressure for reduced time-to-market increases. On the other hand, introducing symbolic models and CAE tool support creates new challenges and problems: − The gap to implementation (production). Using symbolic models brings increased abstraction, which is beneficial for creative work in early design stages and for handling complex systems, but also induces a gap to the real systems and to their implementation. Unless production constraints are considered in development, production problems are likely to occur and in the worst case, the products resulting from the models can not be produced or maintained. There is thus a need to cope with this increased gap to the implementation in order to be able to benefit from the increased abstraction levels. An example of this is code generation for automotive embedded systems. Unless the gap to implementation is properly handled, the generated code may for example become too slow or consume too much memory. These implementation constraints must be considered both in model design and in tool development, clearly requiring implementation knowledge. Implementation/production competence, model validation, prototyping tools and supporting processes are essential instruments to handle this gap. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

10

− The need for experienced model developers. Developing “good” models is a non-trivial task which requires experienced and skilled engineers, who need to have a good understanding of the real-world systems and of the purposes of the model development. It is the model builders who need to ensure, for example, that the models are sufficiently accurate with respect to the needs and to avoid over-trust in the models. This is related to the above mentioned gap to implementation which “good modelers” should be able to handle. But there are many additional aspects that needs to be considered including model structuring (for readability and maintenance), robust design, and the contents and level of detail in environment models. Examples of the latter problems can be taken from finite element analysis using CAE tools where there is a need for understanding how a body can be discretized into small interconnected cells (that is so called “finite elements”) sufficiently well. A too detailed discretization will create an unnecessarily complicated model that may be too resource consuming for a CAE tool; a discretization that is very rough may on the other hand be too much of a simplification, thus creating a model that will not always be able to provide reasonable answers. Consequently, there is a need for a designer to be able to assess the validity of models and results, e.g. through rules of thumb and experiments. − Handling the increased information complexity and model integration. Using symbolic models provides the opportunity to be more explicit about all types of requirements, design alternatives and aspects. Since the different aspects and product parts are now captured by different models, also the need for integration of models appear. In addition, using CAE tools for analysis allows much more questions to be answered than what is possible through manual analysis, using only mental and physical models. While this is beneficial, it does on the other hand create much more information that needs to be taken care of somehow. The handling of increasingly complex products has given rise to tools such as product data management (PDM) and software configuration management (SCM), denoting tools that in various ways support the structuring of product related items (data, parts, programs etc.) and the process of managing the lifecycle of a product. − Tool support. Obviously, appropriate tools are needed to support the symbolic models and analysis of them. The introduction of such tools comes at a cost, including direct and indirect costs (such as for personnel training), and at a risk, especially in newer areas where the tools are not yet so mature and still may face large evolutions, and where tool providing companies may disappear.

3.1

CAE and MBD in a mature discipline; illustrated with mechanical engineering

CAE support for mature disciplines is characterized by not only the availability of tools for handling of symbolic models, but also by the availability of supporting − analysis and synthesis theory − processes for MBD including modeling and analysis guidelines. − techniques and standards for model representation and exchange These aspects are here illustrated for mechanical engineering. The term Computer Aided Design (CAD) was coined already in the early 1960’s in mechanical engineering, in response to the need of dealing with geometric shapes and analysis of their behavior. The progression of CAD technology has since then developed very far and now covers advanced threedimensional so called solid (or volume) modeling and support for finite element (FEM) analysis. The current generation CAD-tools provides associative, parametric and featureInvited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

11

based modeling. Behavior models can be associated with topologies (geometry) and support for CAE assisted optimization of more complex systems is on its way [Sellgren, 2003]. Solid modeling creates a kind of virtual reality for machine design, with support also for rapid creation (prototyping) of physical objects and with direct connections to computer numerically controlled (CNC) machining. Overall design methodologies as well as detailed methods and guidelines have been developed [Pahl and Beitz, 1984; Sellgren, 2003]. With the evolution of CAD and related CAE tools followed the need to be able to interchange models between different tools and different generations of tools. The ISO 10303 standard information model, referred to as STEP, has the purpose to facilitate data transfer between different information systems. STEP is mainly used in mechanical engineering by CAE and PDM tools. It includes descriptions of geometry and product structures, and is being extended to other domains. Associated modeling and product specification languages include EXPRESS, SGML and XML. Attempts to extend STEP to systems engineering data are under way [Nasa, 2004]. Such efforts are of strong relevance for embedded control systems.

3.2

The immaturity of using models as an integration mechanism

Several disciplines and specialists are involved in the development of mechatronic systems. While model based development is widely used within engineering disciplines, supported by different modeling techniques and tools, integration between disciplines is still mainly relying on communication between engineers and extensive and labor intensive testing during systems integration. Examples of techniques where models are used today for integration purposes include − Cosimulation, where two tools exchange data to coordinate simultaneous simulation of different models. − Code integration, where code generation is used to bridge the gap between different groups, for example between control and software engineers. − Model import/export between tools relying on exchange standards. While these techniques do aid in system development, they are mainly concerned with a subsystems oriented decomposition of the system and do not address cross-cutting aspects (such as safety and reliability) and related trade-offs affecting conflicting qualities. The integration of heterogeneous models is a research area and the maturity of commercial computer based applications is low, see for example Artist [2004]. It can be noted that PDM and similar tools do not deal with model integration; they are used for information management and can be used for activity integration. Introducing system-level MBD as an integration mechanism is subject to a range of requirements. The systems are multi-disciplinary and complex, the design process is concurrent, and the models must be complete for analysis as well as support efforts to search the solution space for optimization. These requirements suggest that a multi-model approach is necessary. However, using multiple views also introduces some problematic issues. The modeling process and tools must ensure consistency and traceability of information in the models. Some problems are remedied by using centralized data storage. Besides coping with information in the dimensions within and between domains, the third dimension of time must also be considered to maintain the development history and record changes. Simple tools that calculate keyfigures is another approach that can be supportive. However, the choice of not using multiple views limits the size of the systems that can be considered. A simple tool can give good results in an isolated case, but a more extended tool can be Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

12

integrated in a seamless tool chain and reused. Complex multi-view tools have some drawbacks, but they are more easily reused.

3.3

Model Based Development in a product development context

Product development incorporates one or more products, an organization and a development process. Each of these aspects has parts and relationships that can be represented in matrix form. The functional content and non-functional requirements of any product change over time. To cope with the new requirements the product must be redesigned. Sometimes the redesign can be managed within the current product concept, using the existing design organization and process. Occasionally, major changes are necessary in one or all three of the aspects. It is intuitively clear that these three aspects strongly depend on and influence eachother. This intuition is supported by studies made by Eppinger and Salminen [2001], who conclude that the relationships and interactions between the three aspects should be aligned in order for a company to become successful, see figure 4. What is the role of models in this context? Models are used to describe the product; they are used for a given purpose in the process, and by people in a given part of the organization. Developing and using models changes the design process. According to the above discussion, an MBD process needs to be aligned with changes or adaptations in the organization, and it must be introduced aligned with the product structure. Teams

Tasks X Tasks

X X

X X

X

Teams X

X

X X X

X X

X

X

X X

X X

X X

X

Development Process Interactions

X

X

Development Organization Interactions

Alignment

Components X Components

X

X X X

X X

X X X

X

X

Product Architecture Interactions

Figure 4 The need for aligning three structures: the product, the process and the organization based on Eppinger & Salminen [2001]

Now, if the requirements on the product change, it is possible to cope with the new requirements by changing the product, the process or the organization or a combination. It is expected, due to the alignment argument, that a combination is always needed but the question is which one of the three will be the leading one. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

13

For example, in the field of automotive electronics the functionality is constantly increasing and new relations between functions are introduced, thus the complexity increases. Following the previous discussion the increased complexity can be managed either through a change in the system architecture, an improved design process or an improved (or enlarged) organization structure. The question is where to focus the efforts to achieve the most dependable and cost-efficient solution. Adopting a new modeling approach has strong influence on the required work process. This may be problematic as established work processes - the process heritage - may conflict with the new process requirements. Any new model concept and related tools need to adapt to current practice and evolve gradually as they gain acceptance in the organization. This is examined in a case study [Larses & Elkhoury 2004] where measurable keyfigures are suggested as a simple first step towards model based integration. The keyfigures point out the data to be included in meta-models, communicates the architecture strategy and directs modeling work to producing results that are useful for decision making and optimization. The reasoning is illustrated in figure 5. Model-based Optimisation Keyfigures in line with product identity

Complete models Consistent models Model-based Analysis

Select content

Multi-disciplinarity Complexity Concurrency

Proper tools and processes

Figure 5. The context of model based architecture design

4

A definition of Model Based Development for ECS

In this paper we refer to MBD as the use of explicit, codified symbolic models with a documented syntax and semantics. Relating to the discussions of model based development in the previous sections, we allow models to be more or less formal. An MBD approach is not necessarily supported by computer based tools, but it is the intention of the approach, and the greatest benefit is achieved in a computerized environment. We intentionally keep our definition of MBD broad. This allows us to consider model based development to incorporate both mathematically well defined concepts/languages (such as the synchronous languages and CAD geometry) as well as semi-formal approaches such as UML. This definition is not, however, sufficient to characterize the variety of MBD approaches being used in practice; thus the need to further examine MBD. An attempt towards an improved characterization is given by El-khoury et al. [2004], where a framework for modeling approaches is developed. It is stated that a certain modeling approach will come along with: Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

14

1. Tooling capabilities, modeling language(s) and its representations 2. Modeling content 3. Design and analysis context To assess the capabilities of an MBD technology (which could be a modeling language, a tool, or a set of tools employing one or more languages) there is thus a need to scrutinize not only tools and languages, but also the modeling semantics (the modeling content) and the intended usage context. These dimensions are depicted in figure 6. The context dimension considers which life-cycle stages an MBD approach is applied to or intended for (e.g. requirements, architectural design, detailed design, testing). Further, the context includes the purpose(s) of the model. Examples of different purposes include the need to evaluate feasibility of a design, compare alternative designs, verify properties, document/describe, educate, etc. For each purpose one or more aspects/qualities from different engineering domains are of concern such as safety, reliability, performance (weight, speed, force, energy consumption, etc.) and modularity. The context thus in a sense defines the appropriate level of abstraction for the modeling tasks at hand and domain boundaries of what a model describes. The modeling content considers what the models syntax and semantics actually do capture in terms of structures and behaviors. Within the modeling content formal rules that support analysis and verification of models are included. A given content should match a given context. The tooling and language capabilities provide the bridge for capturing and representing models with respect to the development context, the tools create instances of the models syntax and implements semantics and formal rules. There exist a range of examples of MBD tools and methods with different degrees of formalization, such as: -

CAD systems Matlab/Simulink control modeling Modelica/Dymola physical modeling Message sequence charts (MSC) Design Structure Matrix (DSM) (Relationship matrices) Excel spreadsheet calculations

3. Modeling Context Lifecycle stage Level of abstraction Focal Domain

1. Tools and representation

2. Modeling Content Syntax Semantics Formalization

Figure 6 Dimensions of model based development

It should be noted that while MBD is currently being used in disciplinary (or subsystem) practices, holistic model based design is still far from reality. One major reason for this is the differences in context and scope being addressed by different engineers and research communities. Given our definition above, with a content, context and supporting tools, it is possible to characterize an MBD approach, to identify its suitability for a given context, and to compare Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

15

different approaches. Problems with MBD can be attributed to improper modeling content for a given context or improper tools and representations to bridge modeling content to the context.

4.1

Social and Model Based Development

Now, is there an alternative to a model based approach? Larses and Adamsson [2004] suggest a distinction between Social design and MBD, where it is possible to make a strategic choice on how to approach engineering. This distinction is adopted here using the concept of MBD as a label for explicit symbolic modeling, while Social design relates to use of physical and mental models only (compare with section 3). Social design concerns qualitative reasoning, prototyping and testing. An extreme social design process is based on trial and error, and knowledge is held by individuals. Further development requires that experiences are transferred socially. The most advanced MBD approaches rely on thorough analysis by mathematically based methods and models. Such an approach often utilizes higher levels of abstraction, and also provides mathematical tools for analytically comparing and evaluating alternative solutions before any implementation is performed. See figure 7. An MBD approach

A social approach

Synthesis

Decision-making

Analysis

Discussion meetings

Modeling

Experiencing

Figure 7 A comparison of components of the complementary design approaches

Social design has benefits, being intuitive and cutting a lot of work by quickly addressing prototyping and testing. However, developing prototypes can be resource and time consuming, and a failing concept requires much redesign if a prototype must be abandoned. As more extensively discussed in the next section, higher complexity increases the need for a model based approach. The social approach to a complex problem is to divide it into subproblems manageable for individuals. An MBD approach handles this complexity in the documentation provided by the models, with tools supporting analysis and integration, and maintaining the whole picture by hiding the detailed analysis in abstractions. Moreover, from the field of engineering design it is known that increasingly complex products call for extensive knowledge sharing across disciplines/functions. Such knowledge sharing needs to be provided by supporting processes and can either be implemented mainly socially through teams, or by use of MBD tools. An advantage of MBD is the possibility for tool automation, for example, enabling formal verification of system properties. Even semi-formal MBD approaches allow tool automation to some extent; for example for system testing. Other benefits include the improved ability to reuse solutions due to proper documentation achieved in the process of creating models. The improved documentation also reduces the dependencies on individuals which may be a benefit in a rapidly moving labor market where people tend to change jobs more frequently, [Hansen et al., 1999].


16

5

A model of MBD maturity

In this section we present a model of MBD maturity and then, in section 6, illustrate its application. The model takes inspiration from several sources including the state of the art as discussed in previous sections including the current MBD practices, the need to consider the modeling context and context, as well as the need for process/organization/architecture alignment. The model is also inspired by capability maturity model.

5.1

The Capability Maturity Model

There exist a variety of process maturity models to assess and improve organizational capabilities. [Sage & Lynch, 1998] A well known and widely spread model is the software capability maturity model (SW CMM) from Carnegie Mellon [Paulk et al., 1993]. A related model is the systems engineering capability maturity model (SE CMM) [Bate et al., 1995]. In both models there are five explicit steps of maturity. In the SW CMM there exist 19 key process areas, each associated to a maturity level. If the process areas of a given level are mastered, the organization achieves this overall maturity level and the process areas of the next level are considered. In the SE CMM there are 18 process areas in the three categories of engineering, project (process) and organization. The SE CMM is different from the SW CMM as all the process areas are evaluated simultaneously; there is no general maturity level instead a maturity level is allocated to each of the areas in the SE CMM. [Sage & Lynch, 1998]. The five steps of maturity in the SE CMM are quite similar to the levels of the SW CMM. In the SE CMM at the initial, informal, level all activities are performed ad-hoc and undisciplined. In the first step upwards, at the planned and tracked level, a process is established and requirements management is introduced. At the third level, well defined, the process is understood and standardized within the organization. At level four, quantitatively controlled, the process is analyzed and measured to allow active management. At the highest level, continuously improving, the organization is constantly improving and adapting to the changes in the environment or in the goals. Organizational capability is based on people, process and technology [Nambisan & Wilemon, 2000]. In the SE CMM it is suggested that the process areas of project (process), engineering and organization should be developed in parallel to achieve the most efficient system engineering. It is expected that increased engineering maturity should be supported by project and organization process maturity. The stages of the maturity process have been empirically recognized in the automotive industry [George & Wang, 2002]; further, the CMM has been used for guiding quality work in the named industry [Shigematsu, 2002]. In 2000 the CMM evolved into the CMMI [CM-SEI, 2004].

5.2

MBD maturity model

The levels of the Carnegie Mellon capability maturity model (CMM) are a good basis for reasoning about methods of system engineering. The purpose is to evaluate the appropriateness of a given work process by establishing a maturity level related to some reference model. We believe that the CMM provides a useful, however very detailed, framework for process development. For our purposes a more general and aggregated evaluation of these aspects is more suitable. The five levels of maturity can be introduced for a more narrow set of capabilities concerning model based development. For example, the use of explicit models and tools can reach different levels of maturity similar to the SE CMM. The maturity level of model based development should relate to the complexity of the product and the possibility to reuse designs as discussed previously. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

17

The three dimensions of MBD provided in our definition, in section 4, can be integrated with the product-process-organization view (figure 5) to form a model of MBD. The tooling capabilities relate to the tool support for MBD provided by the organization, the modeling content is based on the product while the context relates to the design process. In section 4 tools are placed as a link between modeling content and context. The product-processorganization framework shows that all three parts are related. Placing the maturity of the MBD process as the central issue instead of the tools, we find that this process is influenced by both the product and the organization as illustrated in figure 8. The modeling needs of the product are drivers for or against a model based development process. The availability of supporting tools in the organization is affecting the possibility to have an efficient MBD process. Product (drivers)

Process (maturity)

Organization (support)

Figure 8 The MBD process context

The three factors illustrated in figure 8 can be separately evaluated for social and model based development. The process maturity can then be compared to the drivers and support. It is assumed that each of the three can be evaluated quantitatively by different measures. The maturity level of the process should match the level of the drivers to improve efficiency. Also, the maturity level of supporting technology and tools should be incorporated in the analysis. An illustration of the framework is shown in figure 9. In the figure the five reference levels of the CMM are used, both for the social and the MBD aspects respectively, and also for the drivers and supporting technologies. The actual evaluation of the different aspects is elaborated below. Maturity 5 4 3 2 1 0 MBD Social Drivers Drivers

MBD Social Process Process

MBD Support

People Support

Figure 9 A model for contextual design process maturity

This model applied for MBD is obviously a special case for the product-process-organization framework, engineering is also performed socially. The social process is then subject to product drivers for social integration supported by people. The social and model based approaches are obviously not mutually exclusive, but rather complementary. Nambisan and Wilemon [2000] establish that product development entails people, process and technology. The technology dimension includes tools and techniques; the process dimension includes methodologies and activity/resource planning, process standards and metrics while people involve personnel deployment and management, such as teamwork, rewards and incentives. They compare research that has focused on integration mechanisms related to People and Process (social design), and research that has focused on Technology and Process (MBD). In our framework the people dimension is the supporting organization for the social process and Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

18

the technology dimension is the supporting part for the model based process. The optimal allocation of resources among these two aspects is indicated by the product drivers. The social and MBD process maturity are referenced separately according to our suggested maturity model. The social process level exists complementary to the MBD process level, maintaining a high maturity for both of these processes is resource intensive and a proper balance must be established. The model indicates if the efforts spent on maintaining the process maturity are in line with the needs. The product drivers suggest the recommended development and adoption of an MBD process, and the recommended MBD process level. A too high process maturity suggests that the cost-efficiency of development can be improved. A too low process maturity suggest that the organization will have problems to maintain the quality of the product. The support maturity shows the possible process level. The level of support is an enabling factor that indicates if the required maturity can be easily met or if new tools or processes must be invented to cope with the process needs.

5.3

Product Drivers

Naturally, the choice of development approach is related to the context. MBD, however useful for integration in some mechatronic systems, is not necessarily a good integrator for the design of all mechatronic systems. Larses and Adamsson [2004] suggest three drivers for MBD: product maturity (not to be mixed up with the maturity in the CMM model), product standardization and complexity of the product. In line with the thoughts of Hansen et al. [1999], the maturity of a given product technology and a standardization strategy increases the possibility to reuse, and also the inclination to adopt a codification strategy embodied by MBD. The product maturity level (again not to be mixed up with the process maturity level) refers to the rate of change of technology in the product. A mature product is less probable to see any major changes, and investment in tools to support a given solution technology are expected to be valid for a long period of time. Thus, the modelling efforts can be vastly reused. The maturity level is expected to be common for related companies within an industry and introduces a reference level of MBD. Similar reasoning applies to standardization. Further, when complexity is increasing, more explicit knowledge is utilized in the process of system architecting and component integration, making decisions among alternative solutions. We consider complexity to consist of three aspects; heterogeneity of rationale requires more views of the system, conflicting requirements call for more monitored variables and richness of system contents increases the amount of analysis necessary for each alternative. Thus, increased complexity would be the third driver for codification, and MBD, in line with Hansen et al. [1999]. Companies within a given industry may diverge from the level suggested by the drivers applied to the industry products in general. A given organization may apply a strategic emphasis of either MBD or social design and the focus of engineering efforts will change in response to the drivers. [Larses & Adamsson 2004] In our MBD model we suggest to quantity the drivers by use of the proposed drivers (maturity, standardization and the three aspects of complexity) of Larses and Adamsson [2004]. Each of these factors is here simply quantified by introducing another step of suggested MBD maturity level. A mature product would add one step towards MBD as would well developed standards in the area. MBD. A small product (richness of system content) with simple requirements (conflicting requirements) would rather increase the drivers for a social design approach by two steps. Ideally these steps would correspond to the CMM levels, Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

19

however each step may require a multiplication by a scale factor. The scaling of the steps is given by the level of competition in the considered industry. In an extremely competitive industry both the social and model based drivers may be high; the influencing factors (complexity, maturity and standardization) only show the relative distribution of process maturity requirements.

5.4

Social process maturity

An interpretation of the social process content at a given maturity level can be derived from the specification of levels in the SE CMM [Bate et al 1995]. If product development is taking place, the first maturity level, Informal is immediately achieved. To progress to the Planned and Tracked level the process must include allocation of resources and the assignment of responsibilities. The process must be documented and training in the process must be provided. The work products must be maintained under version control and compliance of the work products to the applicable requirements are performed. The Well Defined level establishes “standard processes” across the organization. The standard process is implemented by standards and procedures, and does also incorporate verification mechanisms and completion criteria. The verification mechanisms include defect reviews on given work products. The performance is measured and the data is used for improving the process. At the fourth level, Quantitatively Controlled, detailed measures of the process performance are collected and analyzed. Quality goals are established and the performance is closely monitored. The fifth maturity level, Continuously Improving, incorporates processes to change the standard process. Changes are induced by casual analysis of defects found in the checking and verification process, new process activities are added, old activities may be changed or removed. The social maturity level can also be related to specific process areas such as: “Monitor and control technical effort”, “Plan technical effort” and “Improve organization’s systems engineering processes”; or the complete SE CMM can be applied to achieve a more detailed support for process development. However, for our purposes to understand the role, benefits and problems of MBD a more general process maturity evaluation is sufficient.

5.5

MBD process maturity

Similar to the interpretation of the social process content at a given maturity level, the MBD process content can also be derived from the specification of levels in the SE CMM [Bate et al 1995]. The initial Informal level is a completely ad-hoc process, where the use of models is non-regulated and individually used by engineers. The second stage of maturity, Planned and Tracked would require that tools are provided as a planned effort by the organization. The role of models and tools are established by plans, standards and procedures. Version control is introduced. At the third maturity level, Well Defined, a standard process is established across the organization. The use of models and tools is adopted for common purposes as a “standard process”. An important part of this, for MBD, is the availability of modeling guidelines that support developers in creating, analyzing and managing models. A part of the standard process is to include verification mechanisms like defect reviews and inspections. The Quantitatively Controlled level incorporates quantitative measures for the quality of models. The models must be possible to verify with mathematical techniques which implies Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

20

that they are formally specified. At this maturity level, models are analyzed by tools as a part of the process. In addition, to reach this level, proper modeling and abstractions must be understood by the developers (handbook/guidelines). The fifth maturity level, Continuously Improving, incorporates processes to change the standard process. Changes are induced by casual analysis of defects found in the checking and verification process. The process also provides guidelines and techniques to carry out multiattribute optimization.

5.6

Support Maturity and Technology constraints

The level of support maturity can be derived from the CMM framework and organizational process areas. If a given support technology can perform the activities necessary to achieve a given process maturity, then the support technology inherits this maturity level. If commercial tools are available the first level of maturity is reached. For the second level of maturity there must exist support services related to these tools. The syntax of the models should be checked by tools. For example, in ECS, tracing from the model level to source code level should be supported by the tools. Also, version control support must be available and possible to implement. For a well defined standardized process across the organization the tools must establish support for concurrent engineering and easy exchange of models. Further some basic verification mechanisms detecting inappropriate modeling and some semantic faults should be included in the supporting technology. Tools at this level should support several levels of testing whereby not only the models but also their successive refinement and correlation with the implementation can be tested. Examples of such support includes model level simulation, software in the loop simulation, profiling and model level debugging (where the actual software/hardware behavior is reflected back to the model level), allowing a systematic approach to testing – but still not fully analytical. To achieve the fourth level of maturity, that of a quantitatively controlled process, the supporting tools must be able to analyze the functionality and desired non-functional aspects of the models. This requires the utilization of formal models that are non-ambiguous in their interpretation. Examples of such non-functional aspects include analysis of the system robustness, performance and logical correctness. The highest level of maturity is achieved if the tools are able to measure and check the quality of models, and support model based optimization. Further, the tools must be adaptable to a given context. Templates and core models that are constantly improved are used to minimize the faults introduced in the modeling process.

6

MBD maturity in practice

The use of MBD is different depending on the field of application. In some engineering domains MBD is extensively used while in others and for integration there is less application of MBD. This section details the situation in a few different engineering domains within the automotive sector. The selected domains are related to ECS where we have chosen to include mechanical, control, software and integration engineering. A general evaluation of the maturity is given for the process, support and drivers for MBD; the maturity of the social process is omitted.


21

6.1

Mechanical engineering and CAD

The field of mechanical engineering is a very mature and established field of engineering. In the automotive sector there are many established design methodologies and theories for engineers to use, further the models and tool support are also extensive as elaborated in section 3.1. The drivers in the automotive sector suggest a high utilization of MBD. The mechanical parts in modern vehicles are highly mature, and to a great extent standardized across models and product programs. At the same time they are highly complex consisting of numerous components and connections like welds with non-linear behaviors, and also including conflicting requirements on weight, volume and strength. The desire is also often to optimize certain or several of these, while short development cycles are extremely important. The rationale of engineers is on the other hand rather homogeneous, yielding level 4 for the drivers according to our model. The strong drivers are also shown in the application of CAD-tools in the industry. All leading firms have advanced tools that can assist the engineers and designers with most of the needed analysis. Digital mock-ups reduce the need for physical prototyping, and recent design tools even incorporate virtual reality environment where the vehicle can be explored in detail. [Lohmar, 2004; Monacelli et al., 2004]. Model based development in the shape of CAD is an efficient and unquestioned tool in the automotive industry. A summary of the reasoning and evaluation is shown in figure 10. Maturity 5 4 3 2 1 0 Drivers

MBD Process

MBD Support

Figure 10 The situation for mechanical engineering in the automotive industry

6.2

Control engineering and CACE

Control theory and supporting tools have a long history of development, as elaborated in section 2. However, the emphasis has been more on the support technology rather than on supporting processes. Again, the drivers in the automotive sector suggest a high utilization of MBD. The technology is well developed but there is a lack of standardization. The subsystem based approach that has been developed is not sufficient for developing integrated vehicle dynamics handling properly. The overall dynamics behavior of the vehicle is central for several reasons, it does for example provide the “feel” of a car and can be used to improve performance and reduce wear and fuel consumption. In addition, to be able to implement active safety functionality, there is a need for a more holistic control system approach. These shortcomings have been identified and several automotive vendors and research projects are working on architecture and platforms at functional as well as software levels.


22

We therefore estimate the MBD process for automotive systems to be at level 3 (control engineering on itself on the other hand has well developed processes, and a quantification for example in the area of robotics would yield at least level 4). Matlab/Simulink is the tool predominantly used today for control engineering. A process to use the tool is implemented as a standard process across most automotive organizations. The tools as touched upon in sections 2.1-2.2 provide several levels of testing and control theoretic analysis, a kind of formal verification with which among other things system robustness can be assessed. Support for event-triggered (finite state machine) systems is becoming available (see e.g. Ranville, [2004]) but this type of analysis and tools are much less utilized. Maturity 5 4 3 2 1 0 Drivers

MBD Process

MBD Support

Figure 11 The situation for control engineering in the automotive industry

The situation in control engineering is shown in figure 11. The mismatch of lacking process maturity is for example embodied by the questioning of the use of modeling for full vehicle simulations. It is seen as difficult to model the vehicle at proper levels of abstraction and combine different models describing different parts of the vehicle.

6.3

Software engineering and CASE

There are companies and suppliers in the automotive industry that are certified for level 3 maturity but the maturity of software development in automotive industry has just about reached the lowest two levels of the SW-CMM [Huber & Näher, 2004]. The use of software is not new in the automotive industry but the ability to consider networked systems with a proper process is still in its infancy. At the same time the drivers for MBD in automotive software are growing stronger. The complexity in the networks is increasing, the technologies are becoming mature and standardizations are considered although the standardization is still very weak. There is a lack of common platforms and a common notion of a software component. However, there is much work in the field where efforts for improved standardization include Autosar [2004] and EAST-EAA [2004]. These drivers suggest that a process maturity level at 3 would be useful. The modeling language situation is still unstable, and there is a multitude of different formalisms and tools available (suggesting that the area is not yet mature), see e.g. El-khoury et al. [2004]. The difficulty in providing tools is also given by the automotive context with a strong emphasis on resource constrained implementations, a very large number of variants of the products and techniques required to ensure high quality. Currently tools are only available to support level 2 maturity. Tools that support formal analysis are available for different but not integrated aspects and so far only used to a smaller extent in the automotive industry. The improved formalization of UML in the UML 2 specification may enable tools to reach level 3 with improved verification mechanisms. To fully reach this level more experience must be collected, modeling guidelines developed and the support for analysis must be improved. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

23

The situation in software engineering is shown in figure 12. The mismatches are shown in the current attitude towards MBD within the industry. The lacking process and support compared to the drivers have initiated efforts to improve the situation. Efforts in the tool area with lacking maturity in the MBD process have caused tools to be perceived as costly, inefficient and of little value. Efforts in the process area have shown the deficit in tools.

Maturity 5 4 3 2 1 0 Drivers

MBD Process

MBD Support

Figure 12 The situation for software engineering in the automotive industry

The lacking MBD processes and support is also reflected by the emergence of several local tools that improves reuse of solutions locally in the organization but a cost-efficient standard process is not in place. Individual developers perceive the benefits of reuse, but no cross organizational process exists to cope with this need. Currently quality problems with software are seen in the automotive industry in response to the lacking process maturity and tool support compared to the drivers induced by the more complex system architectures. For example, Mercedes are removing 600 functions from their platform due to quality problems [Auer, 2004].

6.4

Mechatronics engineering and CAI

Computer aided integration (CAI) is another field where an increased need for model based approaches are seen. The systems are becoming much more complex, specifically in terms of cross-domain interactions exemplified by mechatronic systems. Global, or coordinating, functions that span subsystems are increasingly being introduced. Examples of such functions include cruise controllers, traction control and vehicle stability control. This increased complexity calls for MBD although the product maturity and standardization are still deficient with respect to integration. Methods and tools to support the documentation and analysis of function/component dependencies, qualities and other design parameters are needed. A strict process to explicate these needs is required which introduces new required competences and responsibilities. Phrased in another way, there is a need to re-apply systems engineering concepts to mechatronic systems, including architectural design as well as component development. There are several instances of integration required in automotive development, including architectural design, the support for co-design by interacting disciplines (e.g. control engineering and machine design; control engineering and software development) and to support integration of all ECUs part of the vehicle. The state of practice is here varying. However, current processes for model based integration are largely weak (see for example the survey by Adamsson [2004]), yielding level 1 for the MBD process. The integration problems perceived today also point to problems with architecture and standardization.


24

As mentioned in section 3.2, there exists some tool support for model integration and also for information management (e.g. PDM and SCM tools). Constraints and aspects affecting several domains are today mainly expressed using written documents. We consider the tool support to be slightly above the ad hoc level. The situation in mechatronics engineering and CAI is shown in figure 13.

Maturity 5 4 3 2 1 0 Drivers

MBD Process

MBD Support

Figure 13 The situation for integration in the automotive industry

7

Discussion

As outlined in this paper, the development process of ECS is expected to increasingly use modeling and CAE tools in development in response to stronger MDB drivers. However, it is clear that the tools are not yet as mature as for mechanical engineering. MBD support for model integration is still weak. In addition, the processes required to support MBD are not always fully developed. Moreover, our MBD maturity model emphasizes the need to match the processes and technology support with respect to the needs – the drivers. The topic of model based development in the field of embedded control systems is facing resistance and there exist a range of arguments. Some arguments are exemplified below: 1. 2. 3. 4.

A model can never capture reality so why model and bother? Tools are costly! Can code generation be trusted (efficient, reliable code / ECS constraints)? Models are difficult to develop, understand, and not amenable to analysis and synthesis. 5. Overtrust in models and tools: The analysis can only be as good as the model. The garbage in/garbage out syndrome. 6. Too detailed models: The modelling swamp; from abstraction to quarks. 7. Misconceptions: MBD is just about synthesizing code. The arguments are probably all well founded and the result of misuse and malpractice of MDB methods. Below these arguments are discussed and explained as mismatches in the proposed model of MBD maturity.

7.1

Mismatches of drivers, processes and support

The problems and pitfalls with MBD today can be explained by the proposed model. Issues can either be attributed to a mismatch in process maturity vs. technology maturity, or the process maturity vs. driver induced need. Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

25

The introduction of model based development and related tools requires assessment and understanding of the drivers (why), the detailed needs (what kind of support is required), and investigating how the tools can be introduced and integrated with the process and the organization. The right level of process maturity has a strong influence on the cost-efficiency of the development process. When the process maturity is lower than the drivers dictate, development efforts are used for designing solutions that could have been reused through a model based method. In addition, because of insufficient analysis, the quality of the product may be compromised. Arguments such as 1, 3 and 4 are typical symptoms in such a situation. If the situation is the other way around (process more mature than the drivers dictate), there is a risk that models are used for the sake of technology rather than engineering. The level of maturity in the tool support technology influences the reliability and quality of the modeling efforts. If a strong technology mismatches a weak process it is possible to achieve an over-belief in models – argument 5 above (such symptoms have been seen in early practices of CAE tools both in mechanical engineering and electronics design automation). Our analysis of current practices indicates potential problems here for CACE, CASE and CAI. Arguments 6 and 7 are also related to a weak process and strong technology; the risk of overmodeling and not understanding the needs for co-design coming along with code generation will increase with an unbalance between MBD processes and tools. It is very important to recognize that using mature tools in themselves solve very little. It is the analytical process maturity that ensures success in the field of MBD. Or to put it another way: A fool with a tool, is still but a fool… A low process maturity may also create a situation of underutilization of a support tool, thus creating an image of tools as costly, inefficient and of little value – argument no. 2. The high expectations and over-belief pave the way for disappointment with the performance of a tool. The same image may be produced by a lacking support tool maturity, in which case the conclusion is more correct – but yielding the same argument (no 2.) creating an image of tools as costly, inefficient and of little value. This case – where the tools are not sufficiently mature - means that an organization must choose between performing a lot of inefficient social development, or develop in-house tools that may become obsolete within a short period of time. This is for example the case for systems integration of ECS. Thus, lack of faith in tools may originate either from lacking tools or from lacking ability to use them. A major problem is achieved when the need for MBD according to the drivers exceed the maturity of supporting technology. A related problem occurs if strong drivers are not fully understood. In a situation such as in the automotive with a strong mechanical engineering tradition, the persons involved may not be able to fully understand the needs for an MBD approach to handle software, control and CAI, resulting in too weak efforts on processes and supporting tools. Argument 2 is then typically raised even if the relevant tools are available and justified from the viewpoint of the drivers.

7.2

Further work

The levels of the Carnegie Mellon capability maturity model are a good basis for reasoning about methods of system engineering. However, in order to fully understand how a costefficient design process should be implemented it is necessary to further improve the analysis Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

26

of process drivers and support aspects. One area of further work would be to develop more accurate quantification methods for these two aspects. Also, related to the discussed mismatches more qualitative guidelines for an effective and efficient implementation of MBD is a field where more work can be invested. If problems with MBD are perceived guidelines for remedies should be available. A good characterization of MBD with benefits and drawbacks is an important basis for such work, promoting understanding of what MBD is about. The mismatches found in this paper point out other possible areas of research.

8

Conclusion

Developing mechatronic products and embedded control systems is a challenging exercise where one key issue is to manage the jointly required technical and social integration. Model based development is one promising technique that can aid in achieving this integration. Model based development, in the sense of utilizing explicit models supported by tools, exists and is increasingly being used and introduced in the development of embedded control systems. The development is driven by the fact that such systems are becoming increasingly complex and require new design methods. Although very promising, model based development is today not always successful for embedded systems; this paper has established a range of pitfalls for the approach. Model based development exists in a design context of organization, process and product. The evolving systems require changes that influence these three parts. It is possible to find different solutions where either one leads the change process. Model based development, rather than social design, is necessary for the design of complex systems. The success of model based development cannot be attributed to the use of appropriate tools and models alone, the process maturity of the organization must also match the product and skills must be developed to properly use the acquired toolsets and to master the art of modeling. Matching the process maturity with proper tools and aligning the level to the requirements of the product is a challenge. Further, tools are often more immature compared to the required tool support which forces the development of expensive, specialized in-house tools. However, social methods should not be underestimated when they are applicable. The interaction between human and machine is not always efficient. Development by discussions around a large paper still has a number of strong advantages. For example: it is non volatile, it can be communicative, it comes at a low cost and you can identify the source by hand writing style, [Wolf, 2002]. Balancing the use of engineering tools and engineering hours is important for dependable, cost-efficient development of commercial products. One way of evaluating the balance between social and model based development is through the suggested use of a maturity model. Measuring and evaluating the drivers and support for a given approach can be a good guideline for a successful allocation of resources.

9

Acknowledgements

This work has been supported by KTH, the Royal Institute of Techology, by Scania and by the Swedish Agency for Innovation Systems. We would like to acknowledge comments from and fruitful cooperation with our colleagues in the Embedded Control Systems research group at KTH (www.md.kth.se/RTC). Invited paper. Summer School on Model Driven Engineering for Embedded Systems, September 2004, Brest, France: http://www.ensieta.fr/mda/

27

10 Dictionary CAx – Computer Aided X (anything) CAD – Computer Aided Design CAE – Computer Aided Engineering CACE – Computer Aided Control Engineering CASE – Computer Aided Software Engineering CAI – Computer Aided Integration CMM – Capability Maturity Model ECS – Embedded Control Systems ECU – Electronic Control Unit MBD – Model Based Development: The use of explicit, codified models with a documented syntax and semantics. PDM – Product Data Management SCM – Software configuration management

11 References AADL - http://www.aadl.info/ - accessed August 2004. Adamsson, N., 2004. Model-based development of mechatronic systems – Reducing the gaps between competencies? In procedings of TMCE 2004, The Fifth International Symposium on Tools and Methods of Competitive Engineering, Lausanne, Switzerland, Volume 1, pp. 405-414, April, 2004. Artist. 2004. Artist roadmaps, Part I http://www.artist-embedded.org/Roadmaps/ARTIST_Roadmaps_Y2.pdf Auer G. 2004. Mercedes ditches glitches with electronics. Automotive news Europe. 2004-05-31. Autosar - http://www.autosar.de/ - accessed august 2004. Backlund Göran. The Effects of Modeling Requirements in Early Phases of Buyer-Supplier Relations. Licentiate Thesis 2000. Linköping Studies in Science and Technology, Thesis No. 812. Dept. of Mechanical Engineering, Linköping University, Sweden. Bate R., Kuhn D. & Wells C. et al. 1995. A Systems Engineering Capability Maturity Model, Version 1.1, (SECMM-95-01|CMU/SEI-95-MM-003). Pittsburgh, PA:Carnegie Mellon University, Software Engineering Institute, November 1995. CM-SEI. 2004. Carnegie Mellon Software Engineering Institute. Capability Maturity Model® for Software (SWCMM®): http://www.sei.cmu.edu/cmm/ Crnkovic Ivica, Ulf Asklund, Annita Persson-Dahlqvist. Implementing and Integrating Product Data Management and Software Configuration Management. Artech House Publishers 2003 ISBN: 1-58053498-8. Duffy A.H.B. & Andreasen M.M. 1995. Enhancing the Evolution of Design Science, Proceedings of ICED 95, Vol. 1, pp. 29-35, WDK, Heurista, 1995. East-EAA (2004). http://www.east-eea.net/ - accessed August 2004. El-khoury J, Chen D-J & Törngren M. 2003. A Survey of Modeling Approaches for Embedded Computer Control Systems, Technical Report, TRITA-MMK 2003:36 ISSN 1400 –1179, ISRN KTH/MMK/R-03/11-SE, 2003. Eppinger S., & Salminen V. 2001. Patterns of Product Development Interactions Proc. International Conference On Engineering Design, ICED01 Glasgow, August 21-23, 2001, pp 283-290. George R & Wang J. 2002. Vehicle E/E System Integrity From Concept to Customer. SAE Convergence 2002. Transportation Electronics. Detroit, MI. October 21-23. 2002. SAE 2002-21-0018. Hansen M., Nohria N., & Tierney, T. 1999. What's Your Strategy for Managing Knowledge? Harvard Business Review. Vol.77, No.2.,1999, pp 106-116. Huber U. & Näher U. 2004. Failure-free electronics – seven levers for optimized electronics R&D. McKinsey & Company, Automotive & Assembly. 2004.


28

IEEE. 1992. The new IEEE standard dictionary of electrical and electronic terms. IEEE std. 100-1992. Fifth ed. Jeutter R. & Heppner B. 2004. Model-Based System Development – Is it the Solution to Control the Expanding System Complexity in the Vehicle? SAE World Congress 2004. Detroit, MI. March 8-11. 2004. SAE 2004-01-0300. Larses O. & Adamsson N. 2004. Drivers for Model Based Development., Design 2004. Dubrovnik, May 2004. Larses O., & Chen D-J. 2003. The Monty Model for Engineering of Mechatronics systems. Technical Report TRITA-MMK 2003:11 ISSN 1400-1179. Royal Institute of Technology, KTH, Stockholm, 2003. Larses O. & El-khoury J. 2004. Multidisciplinary Modeling and Tool Support for EE Architecture Design. FISITA 2004 30th World Automotive Congress, Barcelona, Spain, 23-27 May 2004 Lohmar W. 2004. The Virtual Development Process - a Reality at SEAT” FISITA 2004 30th World Automotive Congress, Reference F2004F450, Barcelona, Spain, 23-27 May 2004. Lygner M. [2002]. Model-based development tool chain at Volvo Cars. dSPACE News, 1/2002, www.dspace.de. MathWorks. 2004. The MathWorks Automotive Advisory Board, http://www.mathworks.com/industries/auto/maab.html, accessed august 2004. McDermid J.A. 1989. Assurance in high integrity software. In High Integrity Software (Sennet C.T.ed.). London: Pitman. MISRA, 2004 - http://www.misra.org.uk/index.htm Monacelli G., Sessa, F. & Milite A. 2004. An Integrated Approach to Evaluate Engineering Simulations and Ergonomics Aspects of a New Vehicle in a Virtual Environment: Physical and Virtual Correlation Methods.. FISITA 2004 30th World Automotive Congress, Reference F2004F406, Barcelona, Spain, 23-27 May 2004. Mortensen N. H., Design modelling in a Designer's Workbench, Ph.D. thesis, Lyngby, Technical University of Denmark, 1999. Nambisan S., & Wilemon, D., Software development and new product development: potentials for cross-domain knowledge sharing. IEEE Transactions on Engineering Management, Vol.47, No.2., 2000, pp211-220. Nasa, 2004: http://step.jpl.nasa.gov/AP233/AP233-overview.html (accessed, July 2004). Nelamkavil. 1987. Computer simulation and modelling. ISBN 0 471 91129 1, John Wiley & Sons, 1987. Oliver David W., Timothy P. Kelliher, James G., Jr. Keegan. Engineering Complex Systems With Models and Objects. Publisher: McGraw-Hill Companies; (January 1, 1997). Pahl G. & Beitz W. (1996) Engineering Design – a systematic approach. Springer-Verlag. 1996. Paulk M, Curtis B, Chrissis M. B. & Weber C. 1993. Capability Maturity Model for Software, Version 1.1, (CMU/SEI-93-TR-024). Pittsburgh, PA:Carnegie Mellon University, Software Engineering Institute, February 1993. Ranville S. 2004. Case Study of Commercially Available Tools that Apply Formal Methods to a Matlab/Simulink/Stateflow Model. SAE World Congress 2004. Detroit, MI. March 8-11. 2004. SAE 2004-01-1765. Reuter J. Analysis and Comparison of 3 Code Generation Tools. SAE World Congress 2004. Detroit, MI. March 8-11. 2004. SAE 2004-01-0702. Sage A.P. & Lynch C.L. (1998). Systems Integration and Architecting: An Overview of Principles, Practices and Perspectives. Systems Engineering. Vol 1. No 3. P176-227. Sellgren U. 2003. Simulations in product realization - a methodology state of the art report. Technical report, Dept. of Machine Design, Royal Inst. of Technology, 2003. ISRN KTH/MMK/R-03/05-SE. ISSN 14001179. Shigematsu T. 2002. Software Quality Management Applied to Automotive Embedded Systems. SAE Convergence 2002. Transportation Electronics. Detroit, MI. October 21-23. 2002. SAE 2002-21-0017. Stevens R., Brook P., Jackson K. & Arnold S. 1998. Systems Engineering - coping with complexity. Pearson Education 1998. ISBN 0-13-095085-8


29

Sztipanovitz J. & Karsai G. Embedded Software: Challenges and Opportunities. In proc. of EMSOFT 2001, LNCS 2211, pp. 403-415, 2001. Springer-Verlag Berlin Heidelberg 2001. SysML - http://www.sysml.org/index.htm - accessed August 2004. Törngren M. 1998. Fundamentals of implementing Real-time Control applications in Distributed Computer Systems. Journal of Real-time Systems, 14, p. 219-250. Kluwer Academic Publishers. Törngren M. 2003. Embedded Systems of Strategic Importance for Swedish Society -where are the needs and how should efforts be directed? Essay and summary from the panel debate at Realtime in Sweden, 2003: http://www.snart.org/conference/2003/PanelSummary-RTiS03/ UML2/MDA - http://www.omg.org/ - accessed August 2004. Wikander J., Törngren M. & Hanson M. (2001). Mechatronics Engineering - Science and Education, Invited Paper. IEEE Robotics and Automation Magazine, Vol 8, No. 2, 2001. Wolf Wayne, 2002. Household hints for Embedded System Designers. IEEE Computer, – Column on Embedded Computing, May 2002.


30

Characterization of model based development of embedded control ...

Characterization of model based development of embedded control ...

Suggest Documents

Characterization of model based development of embedded control ...

Model-Based Development of Embedded Systems*

Model-based Development of Embedded Systems: Executable ...

A Model-based Embedded Control Hardware ...

A Model-Based Embedded Control Hardware ...

Model-Based Development of an Engine Control

On Model Based Synthesis of Embedded Control ... - Semantic Scholar

Model-Based Design of Embedded Control Software for ... - UniTN

Model-based development of embedded systems - the MADES ...

Model-Based Development of Embedded Systems - Software and ...

Model-Based Development of Distributed Embedded Real-Time ...

Model-based Development of an Embedded Steering ... - IEEE Xplore

Model-Based Development of Distributed Embedded Real ... - CiteSeerX

Model-based Embedded Software

model based control of

Component-Based Design of Embedded Control Systems ...

Model-Based Debugging of Embedded Software Systems

MODEL-BASED VERIFICATION OF EMBEDDED SOFTWARE

Model-Based Testing of Embedded Systems ...

Model-Based Engineering of Real-Time Embedded

Component-Based Development of Networked Embedded Applications

model based control of - CiteSeerX

A Model Based Development Approach for Distributed Embedded

A Model Based Development Approach for Distributed Embedded