Systems Modeling and Modularity Assessment for Embedded...

1

Systems Modeling and Modularity Assessment for Embedded Computer Control Applications

��

��

�� !��"�#��$�� #�� %#�

��&��#�� '��$��#��%&�

�� (��"�

DEJIU CHEN

2

��

��

�&��"��)�� #%��#)��)'�� &��"�#��$��"*�))�)�+�"!'��+�#��!!� �� #��

��, '�+��#�

��

��)�" �� -�.� ��. ��!!��/��$��'#%� %��(# �(��0%�(��#-�. ��*��!��#��)�

$��!'*� ��/ �.� #�$'�$ �"�#��$��1' ��"�#��$��$��#% #�� #%� #�� #��

�� %#2��!'*� ��/ �.� ��)��'#%� %��(# �(��0%�(��#-�3��/4%�#��-��(��"-� #��% ��#�� 52 6�!"��#��$�,'#��2��

3

TRITA - MMK 2004: 17 ISSN 1400 -1179 ISRN/KTH/MMK/R-04/17-SE

Mechatronics Lab Department of Machine Design Royal Institute of Technology S-100 44 Stockholm SWEDEN

Document type

Doctoral Thesis

Date

2004-05-17

Author(s)

DeJiu Chen [email protected]

Supervisor(s)

Prof. Martin Törngren, Prof. Jan Wikander

Title

Systems Modeling and Modularity Assessment for Embedded Computer Control Applications

Sponsor(s)

KTH and the Swedish Foundation for Strategic Research (SSF) through ARTES

Abstract

The development of embedded computer control systems (ECS) requires a synergetic integration of heterogeneous technologies and multiple engineering disciplines. With increasing amount of functionalities and expectations for high product qualities, short time-to-market, and low cost, the success of complexity control and built-in flexibility turn out to be one of the major competitive edges for many ECS products. For this reason, modeling and modularity assessment constitute two critical subjects of ECS engineering. In the development of ECS, model-based design is currently being exploited in most of the

sub-systems engineering activities. However, the lack of support for formalization and systematization associated with the overall systems modeling leads to problems in comprehension, cross-domain communication, and integration of technologies and engineering activities. In particular, design changes and exploitation of “components” are often risky due to the inability to characterize components’ properties and their system-wide contexts. Furthermore, the lack of engineering theories for modularity assessment in the context of ECS makes it difficult to identify parameters of concern and to perform early system optimization. This thesis aims to provide a more complete basis for the engineering of ECS in the areas

of systems modeling and modularization. It provides solution domain models for embedded computer control systems and the software subsystems. These meta-models describe the key system aspects, design levels, components, component properties and relationships with ECS specific semantics. By constituting the common basis for abstracting and relating different concerns, these models will also help to provide better support for obtaining holistic system views and for incorporating useful technologies from other engineering and research communities such as to improve the process and to perform system optimization. Further, a modeling framework is derived, aiming to provide a perspective on the modeling aspect of ECS development and to codify important modeling concepts and patterns. In order to extend the scope of engineering analysis to cover flexibility related attributes and multi-attribute tradeoffs, this thesis also provides a metrics system for quantifying component dependencies that are inherent in the functional solutions. Such dependencies are considered as the key factors affecting complexity control, concurrent engineering, and flexibility. The metrics system targets early system-level design and takes into account several domain specific features such as replication and timing accuracy. Keywords

Domain-Specific Architectures, Model-based System Design, Software Modularization and Components, Quality Metrics.

Language

English

5

Acknowledgment

I would like to thank my supervisors, Professor Martin Törngren and Professor Jan Wikander, for their indispensable guidance, comments, and criticism that helped this work along into its final stage. They have provided insightful direction and broad perspective regarding this research. Particularly, Professor Martin Törngren has provided endless inspirations, fruitful advices, valuable encouragement, and practical support during all of my works. Thanks are also given to all members of the Mechatronics Lab, both past and present. Jad El-Khoury has been a great collaboration partner. Through a lot of “furious” discussions, we have managed to accomplish the work on modeling survey. Ola Larses has provided many useful ideas concerning systems during our work on “Monty model”. Acknowledgment also goes to my colleagues at MMK department for their practical help. I would also like to thank the Swedish network for real-time research and graduate education (ARTES) for supporting my work. Finally, my wife, my parents, and my sister are always my firmest support. I would also give my thanks to them. Regards are also given to my relatives and friends who have provided me with support and friendship during these years. DeJiu Chen 05 2004, Stockholm

7

List of Appended Publications

Part A

DeJiu Chen. Architecture for Mechatronics Software Systems - A Survey of Related Concepts, Theories and Methods, Technical Report, TRITA-MMK 1999:30, ISSN 1400-1179, ISRN KTH/MMK/R-99/30-SE., 1999.

Part B DeJiu Chen, Martin Törngren. Towards A Framework for Architecting Mechatronics Software Systems, Proceedings of 7th IEEE International Conference on Engineering of Complex Computer Systems. Skövde, Sweden, June 11-13, 2001.

Chen conducted the development and writing. Törngren provided many advises on the concept and writing.

Part C

Jad El-khoury, DeJiu Chen, Martin Törngren. 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. Submitted for Journal publication.

This work is a result of productive teamwork of the authors. Chen and El-khoury developed the framework and carried out the survey and comparison study in close collaboration. Törngren provided many fruitful advises. Chen concentrated on the MetaH language and ADLs, and also wrote the modeling framework that was published separately at 2004 SAE World Congress, Detroit, USA.

Part D

DeJiu Chen, Martin Törngren. A Systematic Approach for Identifying Operational Relationships in Embedded Computer Control Systems, To appear at 30th Euromicro Conference on Component-Based Software Engineering Track, Aug31- Sep3, Rennes, France, 2004.


Part E

DeJiu Chen, Martin Törngren. A Metrics System for Quantifying Operational Coupling in Embedded Computer Control Systems, Submitted for publication 2004.


8

Other Publications DeJiu Chen, Jad El-Khoury, Martin Törngren, A Modeling Framework for Automotive Embedded Control Systems, SAE Tech Paper Series (2004-01-0721), 2004 SAE World Cong, Detroit, USA, March 8-11, 2004.

Ola Larses, DeJiu Chen, Engineering Mechatronics Systems: A Meta-level Description of System and System Development Based on the Montesquieu System Model in An Automotive Context, The 2nd Swedish Mechatronics Conference, 2003. Ola Larses, DeJiu Chen, The Monty Model for Engineering of Mechatronics Systems, Technical Report, TRITA-MMK 2003:11ISSN 1400-1179, ISRN/KTH/MMK/R-03/11-SE, 2003.

DeJiu Chen, Architecture for Systematic Development of Mechatronics Software Systems, Licentiate Thesis, TRITA - MMK 2001:06, ISSN 1400 –1179, ISRN KTH/MMK - 01/06 – SE, 2001.

DeJiu Chen, Martin Sanfridsson, Introduction to Distributed Real-Time Control, Technical Report, TRITA-MMK 1998:22, ISSN 1400-1179, ISRN KTH/MMK/R-98/22-SE, 2000.

DeJiu Chen, Martin Törngren, System Architecture in a Mechatronics Perspective, Compendium of Papers, SNART 99 Real-time System Conference, Linköping, 1999.

9

Table of Contents

Introduction 1. Motivation .......................................................................................................... 15 2. Thesis Outline .................................................................................................... 17 3. Problems with State of the Practices ............................................................... 17 4. Partial Solutions in State of the Art Research ................................................ 20

4.1 Systems engineering ..................................................................................... 20 4.2 Engineering Design....................................................................................... 23 4.3 Software Engineering.................................................................................... 25 4.4 Engineering of Embedded Computer Control Systems ................................ 27

5. Research Questions ........................................................................................... 30 6. Research Approach ........................................................................................... 32 7. Contributions and Thesis Summary................................................................ 33

7.1 Part A: Architecture for Mechatronics Software Systems – A Survey of Related Concepts, Theories and Methods..................................................... 34

7.2 Part B: Towards a Framework for Architecting Mechatronics Software Systems ......................................................................................................... 34

7.3 Part C: A Modeling Framework and Survey for Embedded Computer Control Systems ......................................................................................................... 35

7.4 Part D: A Systematic Approach for Identifying Operational Relationships in Embedded Computer Control Systems ......................................................... 36

7.5 Part E: A Metrics System for Quantifying Operational Coupling in Embedded Computer Control Systems ......................................................... 37

8. Conclusions and Future Research ................................................................... 38 9. References .......................................................................................................... 40

Part A: Architecture for Mechatronics Software Systems –

A Survey of Related Concepts, Theories and Methods 1. Introduction........................................................................................................49 2. Requirements and System Development..........................................................51

2.1 General Characteristics of Requirements ......................................................51 2.1.1 Functional and Nonfunctional Requirements ...................................... 51 2.1.2 Meeting, Managing, and Assessing Multiple Requirements ............... 51

2.2 Requirements and System Development .......................................................52 2.3 Discussion......................................................................................................53

3. What is Software Architecture? .......................................................................54 3.1 Architectures and Software Architecture.......................................................54 3.2 Definitions of Software Architecture.............................................................55

10

Part B: Towards a Framework for Architecting Mechatronics Software Systems

3.3 Multiple Structures of Software Architecture.................................................57 3.4 What is a Software Component? ....................................................................58 3.5 Discussion.......................................................................................................60

4. Creating Architecture.........................................................................................62 4.1 Approaches .....................................................................................................62 4.2 Principles ........................................................................................................63

4.2.1 Architecture and System Qualities .......................................................63 4.2.2 Design-by-contract ...............................................................................64 4.2.3 Information-hiding................................................................................64 4.2.4 Coupling-and-Cohesion........................................................................65

4.3 Architectural Styles ........................................................................................67 4.4 Discussion.......................................................................................................71

5. Techniques for Describing Architecture...........................................................71 5.1 Multiple Views to Separation-of-Concerns ....................................................72

5.1.1 Three Basic Perspectives ......................................................................72 5.1.2 The 4+1 View Model of Architecture ..................................................73 5.1.3 A Stakeholder-Oriented View Approach..............................................75 5.1.4 Six View Organization of Models ........................................................75

5.2 Architectural Description Languages .............................................................76 5.3 Discussion.......................................................................................................78

6. Techniques for Architectural Quality Analyses...............................................79 6.1 Design Space Method .....................................................................................79 6.2 SAAM – Software Architecture Analysis Method.........................................79 6.3 ATAM – Architecture Trade-off Analysis Method........................................81 6.4 Discussion.......................................................................................................83

7. Architecture-Based Development Process ........................................................83 8. Three Solution Architectures.............................................................................85

8.1 An Open System Architecture for Controls within Automation Systems − OSACA...........................................................................................................85

8.2 An Architecture for Online Modification of Control Software − Simplex ....92 8.3 A Time-Triggered Architecture − TTA..........................................................97 8.4 Discussion.....................................................................................................101

9. Conclusion..........................................................................................................102

1. Introduction...................................................................................................... 111 2. The background and key concepts ................................................................. 112 3. The Architecture Model .................................................................................. 115

3.1 Archi-parameters in the Functional Structure ............................................. 115

11

Part C: A Modeling Framework and Survey for Embedded Computer Control Systems

3.1.1 External properties of single functional units -logical domain ......... 115 3.1.2 External properties of single functional units –temporal domain ..... 116 3.1.3 Interrelations of functional units - logical domain ............................ 116 3.1.4 Interrelations of functional units – temporal domain ........................ 117 3.1.5 Interrelations of functional units – spatial domain............................ 118 3.1.6 Interactions of functional units.......................................................... 118

3.2 Archi-parameters in the implementation structure ...................................... 118 3.2.1 Logical domain.................................................................................. 118 3.2.2 Temporal domain .............................................................................. 119 3.2.3 Spatial domain................................................................................... 120

3.3 Archi-parameters in the Target Platform Structure ..................................... 120 3.3.1 Memory ............................................................................................. 120 3.3.2 Triggering.......................................................................................... 120 3.3.3 Clock synchronization....................................................................... 121 3.3.4 Task Management ............................................................................. 121 3.3.5 Communication System .................................................................... 121 3.3.6 Hardware Structure............................................................................ 121

4. The Decision Model for Flexibility ................................................................. 123 4.1 Temporal Domain........................................................................................ 123 4.2 Logical Domain ........................................................................................... 124 4.3 Spatial Domain ............................................................................................ 125

5. Conclusion and future work ........................................................................... 125

1 Introduction ............................................................................................................... 133 1.1. Approach ............................................................................................................. 133 1.2. Related Work....................................................................................................... 137

2 Comparison Framework........................................................................................... 138 2.1. Model-based Design and Analysis ...................................................................... 138 2.2. Content ................................................................................................................ 140

2.2.1. Abstractions ............................................................................................... 142 2.2.2. Inter-abstraction Relations ......................................................................... 144

2.3. Design Context .................................................................................................... 146 2.4. Analysis Context ................................................................................................. 148 2.5. Language ............................................................................................................. 149 2.6. Tool ..................................................................................................................... 150

3 Evaluation and Comparison..................................................................................... 151 3.1. Content ................................................................................................................ 151

3.1.1. Abstraction ................................................................................................. 151 3.1.2. Property...................................................................................................... 155

12

Part D: A Systematic Approach for Identifying Operational Relationships in Embedded Computer Control Systems

Part E: A Metrics System for Quantifying Operational Coupling in Embedded Computer Control Systems

3.1.3. Inter-abstractions Relations ....................................................................... 161

3.2. Design Context .................................................................................................... 170 3.2.1. Levels, Activities and Disciplines.............................................................. 170 3.2.2. Methodology .............................................................................................. 171 3.2.3. Traceability ................................................................................................ 172 3.2.4. Complexity Management........................................................................... 172 3.2.5. Reusability ................................................................................................. 174

3.3. Analysis Context ................................................................................................. 175 3.4. Language ............................................................................................................. 176

3.4.1. Representation Technique.......................................................................... 176 3.5. Tool ..................................................................................................................... 177

4 Conclusion.................................................................................................................. 178

5 Acknowledgment ....................................................................................................... 179

1. Introduction ................................................................................................................189 2. Aim and Approach .....................................................................................................190 3. Systems Ontology........................................................................................................190

3.1 Systems Concept and Basic Definitions...........................................................190 3.2 Basic definitions ...............................................................................................191 3.3 Property Dependency .......................................................................................196

4. Patterns of operational relationships........................................................................197 4.1 Communicational relationships ........................................................................197 4.2 Synchronization relationships ..........................................................................199 4.3 Implementation specific relationships ..............................................................200 4.4 Example - An ECS for Single Axis Control.....................................................201

5. Related work ...............................................................................................................203 6. Conclusion ...................................................................................................................204

1. Introduction .................................................................................................................. 213

2. Aim and Approach ....................................................................................................... 214

3. Preliminaries ................................................................................................................. 215 3.1 Systems Model ................................................................................................... 215 3.2 Measurement ...................................................................................................... 219

3.2.1 Context ....................................................................................................... 219

13

3.2.2 Parameters Affecting Coupling .................................................................. 219

4. Coupling by Individual Relationships ........................................................................ 220 4.1 Intensity Factor - ρ ............................................................................................. 220

4.1.1 Number of Replications – R ....................................................................... 221 4.1.2 Frequency - F.............................................................................................. 221 4.1.3 Accuracy factor - sA.................................................................................... 221

4.2 Target-cardinality - δ .......................................................................................... 225 4.3 Example.............................................................................................................. 226

5. Coupling by a Combination of Individual Relationships ......................................... 227 5.1 Relative Coupling Factor - κ′ ............................................................................ 227 5.2 Weighting Factor -ω(r) ....................................................................................... 229

6. Related Work ................................................................................................................ 230

7. Conclusions and future work ...................................................................................... 231

15

Introduction

1. Motivation

Embedded computer control systems (ECS) are computer-based systems, constituting subsystems in modern machinery for advanced automatic control, diagnostics, and monitoring [1]. Because of the dynamics under control, ECS differ from other general-purpose computer systems in the aspects of safety criticality and real-time. That is, failures in such systems could lead to injury or death of humans. Among other sources, a failure can be caused by violations of expected timing of executional behaviors, such as an uncontrolled jitter. From an implementation point of view, ECS should also obey some special constraints such as with respect to memory usage and power consumption.

Embedded computer control provides machinery with new functionality and high performance that cannot be realized by traditional technologies alone (e.g., hydraulics and analog electronics). Due to the concerns with safety, pollution, and flexibility, ECS have become widely used in several areas including vehicles, avionics, and robotics. For example, modern vehicular ECS range from braking and power-train control, to climate control, and to crash detection and mitigation systems. There is over the past decades an increasing trend towards higher-level functionality, formed by integrating existing ECS. One example of this is adaptive cruise control that utilizes a multitude of sensors and both power-train and braking control.

Given increasing amount of ECS functionalities and expectations for high product qualities with short time-to-market and low cost, the success of complexity control and built-in flexibility turn out to be one of the major competitive edges for many industry products. In general, complexity is mainly a subjective attribute concerning the degree to which a system can be comprehended and communicated by the stakeholders (e.g., customers, engineers, and project managers). Problems due to unhandled complexity can for example be design errors, which in turn result in delayed product delivery, and increased development cost. Flexibility includes a set of attributes concerning the degree to which a system can be adapted and varied, encompassing other quality attributes such as versatility, reusability, and modifiability. This attribute is important for the reasons of customization, economy and time-to-market, and adaptation to technology changes.

There are several system inherent factors making complexity management and flexibility engineering of ECS a challenging area. First, an embedded computer control system consists of subsystems and components of various types, such as application software, middleware and system software, hardware, as well as sensing and actuating devices. These system constituents are synergistically integrated by means of communications, synchronizations, resource sharing, and analytical

16

relationships such as in terms of functional dependencies and safety criticality. Due to the heterogeneity of system components and the multidimensionality of their relationships, the total “system content” may grow exponentially as the number of system functionality increases linearly. Further, the multidisciplinary nature of ECS adds to the system complexity by making cross-domain comprehension and communication difficult, hence a lack of system-wide perspective and coordination in decision-making. The development of ECS is multidisciplinary in the sense that the development requires a collaboration of several engineering disciplines, including automatic control, computer software, hardware, and mechanical engineering. Each design decision can have both intra- and inter-domain implications in terms of derived requirements or constraints. For example, changing a processor may lead to a different timing of software tasks, which will in turn affect the control performance and eventually result in totally different behaviors. Finally, as “soft” quality attributes, system complexity and flexibility are generally difficult to parameterize and represent, hence difficult to verify and predict in design. In general, these attributes are determined by a combination of factors ranging from system and component characteristics, to capability provided by modeling and analysis tools, and to the insight and experiences of the developers.

To cope with complexity and flexibility, one central issue is concerned with how to model the systems, providing a holistic system view that links various domain-specific models and forms a common basis for comprehension, communication, and design decisions. Another issue is to devise corresponding engineering theories, enabling the assessments and predictions of complexity and flexibility in design. This is a necessity in order to include these attributes in system optimization such as in terms of multi-attributes tradeoff analysis. A third issue is about the modeling and analysis tools as well as flexible technologies such as middleware and communication systems, enabling complexity control and flexibility in engineering practices.

This thesis focuses on the modeling and analysis aspects, aiming to form a more complete engineering basis for model-based design and optimization of ECS. It provides system models that help to raise the abstraction level of system design from a traditional technology based view to a “functional” oriented view, forming a basis for reasoning about system-wide concerns and quality evaluation before the implementation has been done. Such models distinguish between different system aspects, such as structure and behavior, function and technology, and content and context. The models are developed by extending concepts found in systems engineering, engineering design, and software engineering with embedded computer control specific concerns. Further, based on a fine-grained classification of component properties and operational relationships in ECS, a technique for measuring the dependencies of a system part with respect to other parts or the environment is also presented. Such dependencies are considered as the key factors affecting complexity control, concurrent engineering, and product flexibility. The measurement is based on parameters such as topology, frequency, and accuracy. Compared to other existing metrics, which are often implementation-technology specific and cannot be applied in higher-level design, this technique considers

17

system-level relationships and encompasses several ECS specific parameters such as timing accuracy.

2. Thesis Outline

The thesis consists of this introductory part and five parts of results, referred to as Part A, B, C, D, and E.

The next two sections (Section 3 and 4) of this introductory part describe some of the reasons behind this research and provide an overview of our approach and main results. Section 3 describes some typical problems in current engineering practices of ECS. Section 4 provides a brief summary of the state of the art technology targeting complexity control and flexibility of ECS, and a discussion of the possibilities of adopting related technologies from several other research communities, including systems engineering, engineering design, and software engineering, to complement the engineering basis of ECS. Thereafter, in Section 5, the research problems are presented. Section 6 describes our approach to solve the problems. Finally, we summarize the research results and contributions in Section 7 and conclude this introductory part with a plane for future work in Section 8.

3. Problems with State of the Practices

The development of a system consists of the following major steps: specification, design, construction, unit testing, system integration and testing, and calibration. Normally, a system is decomposed into some subsystems, which can in turn have their own subsystems, components, as well as development cycle. Compared to other more traditional subsystems, ECS are subsystems that introduce a new dimension, i.e., targeting either an entire system or some specific subsystems identified from the physical decomposition. The development is also distinguished by its multidisciplinary nature. Depicted using the traditional V-life cycle, the entire system development shows a pattern of hierarchical-Vs, as depicted in Figure 1. The amount of sub-processes as well as the depth of the hierarchy normally depends on the degree at which subsystems can be developed by separate engineering teams or out-sourced. Today, out-sourcing is very common strategy in industry. It allows a company to focus on its core business and technology area and has advantages with respect to cost and efficiency. For example, European car manufactures do not build all of their system parts in-house. Instead, they to a large extent purchase control systems from subsystem providers such as Bosch and Siemens [2].

18

Vehicle System

Engine Brake … System

Control

Controllers … SW HW

Requirement Engineering

System Integration and Testing

Design Unit Testing

Construction

Engine Control

…

Brake

Control

…

Figure 1. Example of hierarchical V-life cycles and system decomposition hierarchy.

In engineering, modeling constitutes the primary means for system comprehension, communication, and analysis. In the development of ECS, multiple modeling techniques are involved such as differential equations, dataflow diagrams, entity-relationship diagrams, finite state machines, and task models. Most of these techniques differ in their contexts, contents, representations, analysis leverages, and tools. One generic reason for this is that in system development the information of interest is generally process-dependent, i.e., varying between different design stages and refinement levels, and stakeholder-dependent, i.e., varying according to the viewpoints of stakeholders. It is seldom the case that one single modeling technique would be sufficient. Further, the multidisciplinary nature of ECS also means that domain specific modeling techniques are involved. Originating from different engineering domains and modeling approaches, these techniques are often dedicated to the analysis of particular quality attributes (e.g., control functionality, discrete behaviors, or scheduling) or the system implementation with particular technologies (e.g., Object-Oriented software).

For the development of ECS, there are needs to integrate existing modeling techniques and to extend them with new modeling features. Integration means that traditionally implicitly coupled system models are explicitly linked and hence complete each other to constitute a more holistic system view. One example is the integration of Stateflow with Simulink in Matlab, allowing both event-based and time-based behaviors in a system functional specification. For a system wide integration of models and introduction of new features, a clear definition of the target system, of which the different aspects are articulated, organized, and represented by modeling, is necessary. However, in current engineering practices, although the maturity varies, the system descriptions often appear as simple block diagrams. Such descriptions are often highly abstract and partial, e.g., covering only subsystems and their communications. Often, designers use software both as a representation of design and the implementation. Due to the limited expressiveness

19

of programming languages, this implies that a lot of information is missing, such as timing and safety assumptions. Also, it is often difficult to distinguish between functional solutions and emergent solutions of technology, and between trivial and critical features.

Another problem in current engineering practices of ECS development is that the focus of modeling support is still on design of control functionality and the implementation aspect of computer software and hardware. There is often a lack of explicit information concerning the design context of artifacts as well as their correspondences established in the design. This makes it difficult to trace the refinements of requirements and their assignments to solutions and to identify the dependences between different system parts. Especially, the descriptions of software and hardware are often directly based on technologies for generic computer systems. On the other hand, since such general modeling techniques do not provide a system model, it is up to the users to determine the completeness of descriptions. Issues that are of particular concern in ECS, such as functional semantics, timing constraints, as well as constraints on power consumption and memory usage are often not addressed explicitly. See e.g., [2] [4]. Due to the partial specifications of systems as well as the components, it is difficult or risky to make correct changes or to reuse solutions. As pointed out by Weber and Weisbrod [3], the complexity of systems resulting from increased use of electronics and software in automotive systems makes conventional text-processing insufficient. To this end, new ways for system documentation and description are necessary.

UML has been increasingly used to support requirement specification and system modeling. There are also efforts to use formal techniques to further promote the correctness and consistency of system descriptions, such as pre-/post-conditions for interfaces and automata based languages for behavior synchronization. See e.g., [4]. However, the resulting descriptions are often difficult to understand and have many implicit assumptions. Often, the use of UML does not lead to a better system description and comprehension of ECS. One reason for this is due to the lack of well-defined semantics in general and ECS semantics in particular. Also, the problem is caused by UML’s origin in object-oriented design of generic software systems. In ECS development, not all stakeholders are familiar with UML notations. Further, there are also some practical difficulties when specifying ECS specific issues such as safety and technology constraints.

Quality evaluation and prediction constitute another important aspect of engineering. Given the importance of flexibility related attributes of complex ECS, there is a need to support objective and repeatable measurement of such attributes in design, and hence to reveal conflicts and optimize system solutions with respect to multiple attributes.

State of practice communication and middleware technologies (e.g., CAN and CORBA) enable software engineers to build distributed systems. However, flexibility related attributes are not always explicitly considered in the design. The structuring is often hardware-driven in the sense that system functions and their software programs are directly given by the hardware architecture. Often, changes

20

and reuse are restricted to ECU level. A new function also implies a new hardware, resulting in suboptimal or costly solutions with respect to the number of devices, cables, and power consumption.

When flexibility related attributes have to be assessed, it is often done by qualitative techniques without well-funded theory, according to developer’s experiences. With partially modeled system, the results may not always be sound. Another often used qualitative technique is scenarios, referring to use cases derived from the system requirements, such as a system upgrade scenario, a system modification scenario. The assessment is then performed by judging how the system under development satisfies such use cases. Still, the technique requires subjective judgment and the results are coarse, affecting the accuracy of system optimization. When applied to large and complex products, such subjective methods are often not sufficient. Also, it is difficult to find out the key parameters and to predict the effects of design, hence difficult to find the points of improvement.

The introductions of new technologies such as executable models/specifications, RCP (Rapid Control Prototyping), code generation, and HIL (Hardware-In-the-Loop simulation) have greatly improved the efficiency of ECS development. Such technologies reduce ambiguity in system descriptions and provide quick implementation feedback in design. On the other hand, the current support is delimited to control functionalities and still at the late design stage [5]. Similar technologies have also been developed for other applications, such as the Telelogic TAU/Architect tool for modeling and simulation of telecommunication systems.

4. Partial Solutions in State of the Art Research

Possible solutions to provide a more “complete” basis for engineering ECS can be found in several research communities, which are related either because of their focus on general systems and system development or because of their focus on some particular implementation aspects of the system. Each of these approaches has important benefits. At the same time, each has weaknesses meaning that an approach cannot, alone, provides sufficient support for the development of ECS.

4.1 Systems engineering

One possible solution to improve current engineering practices of ECS development is to apply concepts, methodologies, and techniques from systems engineering. Originally created to support the development of complex space and weapon systems, systems engineering is concerned with the design and analysis of the system as a whole as well as the management of (multidisplinary) activities and decisions in the process. Because of its broad range of concern, systems engineering is related to many other fields such as requirements engineering, concurrent engineering, systems theory, total quality management, and decision analysis. See

21

e.g., [6] [7]. Over the years, many definitions have been proposed. In INCOSE [8], it is defined as an interdisciplinary approach and means to enable the realization of successful systems. Some other definitions address the methodology and process aspect, i.e., how to integrate the disciplines and specialty groups into an integrated and balanced technical and team effort, such as in MIL-STD-499B, IEEE P1220, and ISO/IEC 15288. Others emphasize the techniques required to support design and to ensure a balanced satisfaction of customers needs throughout a system's entire life cycle, such as modeling, requirement analysis, functional decomposition and allocation, tradeoff analysis, and optimization. See e.g., [7]. One recent effort from INCOSE is to develop a systems modeling language (i.e., SysML) for rigorous transfer of specifications and related information among tools used by systems, software and hardware engineers, by extending and customizing the coming UML2.0 notations.

Systems engineering employs a top-down iterative and parallel process paradigm for system development. One overall description is the SIMILAR process model, given by Bahill and Gissing [9] based on a study of similarity between different approaches. See Figure 2. The term SIMILAR is formed by the acronyms denoting the major steps: State the Problem, Investigate Alternatives, Model, Integrate, Launch the System, Assess Performance, and Re-evaluate. This process model highlights some important concepts of systems engineering: distinction of mandatory and preference requirements, evaluation of alternative designs, use of models both for process management and for system design, modularity considerations in system integration, quality and feasibility assessment, and use of feedbacks from other design steps for decision making. Compared to the previously mentioned V-lifecycle model, the systems engineering process is not sequential, but parallel and iterative. It is applied to the development of an entire system or its subsystems. One particular aspect of systems engineering is systems architecting, referring to the process and techniques for structuring a system while balancing different customer needs and technologies [10]. Compared to systems engineering in general, systems architecting mainly targets the upper levels of a system development process.

��

��

� ��

��

��

� ��

��

��

��

��

��

� ��

��

Figure 2. The SIMILAR process model [9].

There are several potential benefits of applying concepts and general techniques found in systems engineering for the development of ECS, covering issues such as

22

process management, system modeling and optimization. It helps to change the traditional control functionality and implementation technology oriented view of ECS to a systems-oriented view. By explicitly distinguishing between functional and implementation aspects of systems, it is possible to define the roles of heterogeneous models with respect to the entire system and hence their interfaces and synchronizations in system development. Moreover, such a system-oriented view also provides a vehicle for cross-domain comprehension and communication as well as for analysis of overall system qualities. By explicitly considering all significant quality attributes and their refinements in design and performing multi-attribute tradeoff analysis throughout the design, it is possible to evaluate and optimize a system before it is fully implemented.

On the other hand, applying systems engineering to the development of ECS is not a trivial task. As an approach targeting systems in general, systems engineering adopts a very high level understanding of systems. Regardless of their domains, systems are reasoned about in terms of a set of abstract components, as well as their properties and relationships. At this abstraction level, for example, a river system, a machine, and a management system are all the same. The very generality of system comprehension means that, without defining the semantics of components and relationships, it is difficult to apply the systems based approach for ECS other than for requirement engineering and system conceptualization. The lack of ECS specific semantics also means that the complex dependencies of system components become impossible to control. Moreover, a system may be inadequately specified, ill-structured, and descriptions become inconsistent as design proceeds.

One central theme in systems engineering is trade-off analysis. A tradeoff analysis is an analytical method for evaluating and comparing system designs based on stakeholder-defined criteria, performed throughout the engineering process in order to resolve conflicts and to optimize the solutions [7][11][12]. It is carried out by assessing the FoMs (Figures-of-Merit), i.e., “utility” values to measure the fulfillment of customer demands, e.g., a performance figure can be given as “computation delay in [9, 10] ms”. For the purpose of comparison, FoMs constitute the inputs (i.e., domain variables) to decision-making functions (i.e., scoring functions) to obtain a normalized score. To this end, FoMs are preferred to be quantitative and objective. For qualitative attributes, it is suggested in [7][11] that the system developers should either find out measurable quantities to convey the required information, or refine such attributes to other quantitative attributes. Objectivity means that the measures should be observer-independent since the subjectivity is often the source of bias and error. Unfortunately, no direct support has been provided by systems engineering in the area of quality measurement, especially for ECS. While focusing on the methodology and formal techniques for combing data, it is assumed that domain engineering should solve the problem. Thus, to support engineering practices, there is a need to combine the trade-off analysis method from systems engineering with domain knowledge.

23

4.2 Engineering Design

Another approach that can be applied to improve the development of ECS is engineering design. As a discipline of design, engineering design provides theories and techniques to support effective creation of products fulfilling customer needs. One central concept is concurrent engineering, where different tasks such as product design, manufacturing, and support run in parallel. See e.g., [13]. The basic idea is to make the expertise traditionally associated with a specific stage of development process (e.g., one stage in the V-lifecycle) available at every stage of product development. After being introduced in industry, concurrent engineering has resulted in great improvements to product quality, process efficiency scheduling, management, and development cost. For historical reasons, engineering design is mainly applied in the developments of physical products such as in mechanical engineering. Except this respect, engineering design is close in nature and approach to systems engineering.

There are many theories of engineering design, such as Axiomatic Design [14] and Quality Function Deployment (QFD)[15], Systematic Design Approach[16]. Most of these theories consider design as an information processing activity and emphasize the importance of a systematic approach to design and documentation. The process is characterized by a combination of selections of means (i.e., the “hows”) to satisfy objectives/ends (i.e., the “whats”). To specify the roles and obligations of implementation means such as technology specific subsystems or components, an implementation detail independent product description, referred to as functional description or function, is often used. For example, in Axiomatic Design [14], system development is described by four general domains. See Figure 3. In the order listed, the elements contained within each domain are customer needs (CNs), functional requirements (FRs), design parameters (DPs), and process variables (PVs). In addition, there are Constraints (Cs) that set bounds on acceptable solutions. The process begins by inputting information about needs and constraints and then maps them to the consequent domains until the manufacturing process has been specified.

��

�!��

�" ��

��#�

��

" � �� !��

" � ��

" � ��

��

" � ��

� �$$��

� �$$��

� �$$��

Figure 3. Four domains of Axiomatic Design, where “{ }” denotes the characteristic vectors [14]

24

Engineering design theories provide techniques (often referred to as design tools) for setting up a model of a product, i.e., a top-down hierarchical description of the product in terms of means-end/objective tree. Such a system description provides a good overview of products with respect to the design refinement and helps to organize information and to trace design decisions and eventual problems. For example, in QFD [15], a set of matrices or charts (referred to as House of Quality, see Figure 4) is provided to document qualities introduced into the early phases of the design cycle and their allocations throughout the entire product lifecycle. In Axiomatic Design, a set of design matrices is used to document the mapping between domains from customer needs to process variables.

�

��%& ' ( �)�

�

�

( ��

��

%( & � * �)�

�

%( & � * �)�

��

��

� ��

%& ' ( �)�

��

��

�

%( & � * ��& ' ( �)�

��$��

%& ' ( ��& ' ( �)�

��$��

Figure 4. Key content of “House of Quality” [15].

While evolved from the production of physical products, most of the theories are quite general and valid for the development of ECS. It is possible to make ECS development a more disciplined engineering approach, taking into account several important issues of system development such as time-to-market, total quality, concurrent engineering and organization of multidisplinary teams. For example, by means of a function-based view of systems, it is possible to emphasize the essential natures of systems and form a domain/technology detail independent common system representation. The documentation of means-ends traceability provides support for error avoidance, reuse, change management, and coordinating design activities across engineering domains.

On the other hand, because engineering design theories focus on the process and information management, they assume that domain knowledge is provided for comprehending a product and for making the design decisions. In other words, methods for modeling systems and for determining the dependencies between the system functions, subsystems, and components are required to improve quality during product and process development [17]. For example, QFD provides support

25

for documenting the allocations of customer demands to product “quality characteristics”, but requires inputs from domain knowledge to determine product quality characteristics as well as the allocation. (The quality characteristics measure the satisfactions of customer needs in the same way as figures of merit in systems engineering). When dealing with product quality assessment and solution tradeoffs, the focus is often on the subjective aspect such as teamwork and brainstorming.

4.3 Software Engineering

In ECS, software constitutes the primary means of embodying and implementing system functionality. This is for many reasons an important characteristic of ECS. For example, a software-based implementation, together with underlying computer hardware and other electronic devices, provides the automatic control with new design freedom and precision by relaxing the constraints in traditional technologies, such as hydraulics. This also makes it possible to achieve other intellectual properties (IP) relating to human-machine interfaces and machine-machine communications. Moreover, a software-based implementation has many advantages with respect to modification and production due to the insensitivity of software with respect to physical constraints such as weight and geometric form. For example, production and transportation have extremely low cost; modifications can be performed quickly by changing code. On the other hand, software descriptions by nature have little expressive power with respect to other system features than computation logics and instructions for managing hardware operations. Its inherent flexibility can also have many negative effects. Leveson [18] has identified several software traps such as the ease of making major and frequent changes, building unnecessarily complex software, and attaining seemingly partial success. Therefore, how to describe, design, and manage this “primary” system implementation means becomes critical issues that affect the success of complexity control and built-in flexibility for large and complex ECS.

To improve the current engineering practices of ECS development, one field of software engineering becomes of particular interest – software architecture. In general, software architecture is concerned with the design of overall software structures, and hence constitutes a basis for documenting software systems, verifying and balancing the satisfactions of multiple quality goals before coding, guiding system construction, reuse, change, and maintenance, as well as facilitating comprehension and communication [19][20]. This branch of software engineering emerges as an effort to shift software engineering from a traditional focus on coding, testing, and debugging to a disciplined engineering approach.

Considered as a cornerstone in the development of complex software systems, software architecture adopts many concepts from systems engineering and system architecting. It assumes a top-down iterative system development approach and targets the early lifecycle stages. The structures constitute the means for raising the levels of abstraction, representing major system parts, their key properties and relationships and hence system in the large. To control the complexity in system representation, software architecture exploits the concept of views to separate

26

concerns and organize models. One well-known example is the “4+1 view model” of software architecture by Krutchen [21], which has influenced the organizations of diagrams in UML. Views can also be defined according to the perspectives of information users, such as customers view, safety view, and maintenance view [22].

To improve architecture description from informal “box-and-line” diagrams, several architecture description languages (ADLs) and tools have been proposed, such as ACME[23], Wright[24], and Rapide [25]. (See Part III in the thesis for more details). There are also efforts to support architecture description using object-oriented design notations, e.g., in Rational ROSE RealTime [26]. Some of these architecture description languages aim to support software construction and hence are linked directly to the underlying programming languages. Others also provide support for architecture-based quality analysis by providing formal behavior semantics. For example, in the Rapide architecture description language, one model-of-computation (i.e., timed partially ordered sets of events (poset)) is used to specify event traces and thus to support model-based analysis of behavior and performance. Many concepts from software architecture description languages are adopted in UML2.0 Standard [43], which is currently under development.

Software architecture normally uses subjective techniques for assessing flexibility related attributes such as modifiability and maintainability. It is motivated by the fact that, at this level of design, no code details are available. For example, in the SAAM (Software Architecture Analysis Method) by Kazman et.al. [27], scenarios have been used to concretize these non-functional requirements. The evaluation is then performed by running the scenarios on architectural solutions and voting to rank their satisfaction. The same technique is used in the software architecture tradeoff analysis method, ATAM (Architecture Trade-off Analysis Method) [28]. The purpose of these methods is not to provide precise evaluation, but to discover risks and dependencies of architectural decisions.

To systematize previous design experiences and guide design decisions, software architecture also codifies the key aspects and common features of existing solutions into architecture styles [20] [29]. A style is a rough structuring solution with some constraints concerning the roles of parts, their interfaces and interactions, or the topology. Each style has some benefits and drawbacks of use. For example, in a layered style, a system is decomposed into a hierarchy ranging from application- to implementation-specific software. This style streamlines the interactions by prohibiting interactions between nonadjacent layers, hence promoting modifiability but probably increasing execution overheads.

To ensure the success of reuse, the target of software architecture has been extended from a single product to an entire product family, referred to as product lines. See e.g., [30]. A product-line-architecture (PLA) characterizes the commonality across multiple products with respect to both requirements and solutions, hence forming a basis for reusing architecture, components, and tools, and defining “cross-vendor integration standards”.

27

From an ECS point of view, software architecture constitutes the interface between the system functional solution and its software-based implementation. It provides a means for explicitly specifying and documenting the relationships between functional solutions and software solutions, such as relating to function allocations, property mappings, and functional semantics of software programs. An explicit consideration of software architecture also helps to take into account the implementation specific considerations early in system design. This makes early integration and quality verification possible, and hence provides a new opportunity for system optimization. The benefit of applying the software architecture becomes even larger when software has to be considered alone, such as in the cases of maintenance, reuse, integration of COTS, and component management. An explicit architecture helps to identify the contexts of software components by distinguishing between functional and technology specific dependencies, critical and non-critical component properties, global and local obligations, etc.

While still on its way of maturing, the focus of software architecture is traditionally on software systems for general applications that are not time- and safety-critical and normally have less restricted resources (e.g., on PCs). Due to this application specific contextual difference, many of the technologies (e.g., languages and styles) are not directly applicable to ECS without adaptation. For example, the lack of support for system functional semantics, such as the physical unit and range of data variables, makes specifications of software component incomplete. Also, many of them are delimited to the aspects of commonality management, procedural interfaces and behaviors such as by means of object-oriented technologies, considering timing, concurrency, and safety as low level issues. While adopting concepts from systems engineering (e.g., figures-of-merit and sensitivity points) for tradeoff analysis, the methods SAAM and ATAM from software architecture do not aim to support system optimization, but focus on initial risk and dependency assessment of architectural decisions. The lack of objectivity and formality means that there is little guidance for predicting effects of design and making improvements.

Another emerging field of software engineering of interest is Component-Based Software Engineering (CBSE), aiming to support the reuse and integration of existing solutions. CBSE has proven effective in generic software domains. However, current CBSE technologies do not directly support software in ECS. One reason for this is that existing approaches mainly target generic software systems and focus on the implementation aspects such as packaging of binary components and middleware for interoperability (e.g., CORBA and EJB) normally using Object-Oriented technologies [31]. Currently, several research efforts are devoted to extending CBSE for embedded systems; see e.g., [32].

4.4 Engineering of Embedded Computer Control Systems

IEEE [34] defines an embedded computer system as a system that is part of a larger system and performs some of the requirements of that system. In this view, engineering of ECS can be defined as a system engineering discipline dedicated to

28

the application area of embedded control. However, due to its wide application area and usage of a broad range of technologies, there is currently not a clear boundary between its core engineering content and supporting technologies. The methodology support is still rather weak [33]. The following discussion will be based on the target applications of approaches, not on their origins of research communities.

In the development of ECS, most of the subsystems engineering activities such as design of automatic control and real-time scheduling schemes use models for problem descriptions, analysis, synthesis, and optimization. However, the lack of formalization and systematization associated with overall system description leads to problems in system comprehension, integration of technologies, and process management. In order to cope with these problems and hence to support quick time-to-market, high quality, and low cost, support for system-level model-based-design constitutes a new trend of ECS development [33]. Compared to traditional approaches characterized by extensive testing for quality verification, this approach aims to make ECS development more systematic, supporting issues such as documentation of design and explicit architecture for comprehension, early quality verification and error detection, exploration of solution alternatives and system optimization. In fact, the concept of model-based-design is not new and can be found in many mature engineering disciplines, such as civil and mechanical engineering.

Over the years, the technological basis for model-based-design of ECS has gradually been improved. There are several directions of research efforts. An important advancement is the techniques for integration of heterogeneous models in the area of computer modeling. One example is the language and tool developed by the Ptolemy Project at Berkeley [35]. It supports model-based analysis and simulation through the use of abstract “platforms” that provide semantics for components and interactions by managing and integrating a variety of models-of-computation, such as discrete-time, state-machines, synchronous message passing, and discrete-event models. Compared to approaches that extend generic modeling techniques (e.g., extensions of UML), this approach supports a much richer set of concurrency and communication schemes. Another important advancement is the technologies of co-designs, aiming to reveal various cross-domain dependencies in ECS (e.g., effects of feedback delay jitters and data loss on control performance). One example is the OCASIM tool by Airbus which support co-simulation of control functions and its implementation in a synchronous model of computation, taking into account emergent timing features such as sampling and communication delays [2]. Another example is the research tool set developed by the AIDA project at KTH [36], which supports the co-design of control design and task scheduling. There are also many tools for software and hardware co-design. For example, the VCC tool by Cadence [37] provides support for decisions like hardware to software partitioning at early stages of automotive ECS design based on criteria of speed, power consumption, and cost. A more detailed survey of this area can be found in [38] and Part III of this thesis.

However, methodology on how to determine the required modeling content and how to separate various concerns and characterize their dependencies for complexity

29

control is still weak. For example, although providing very good support for interoperability of heterogeneous components, Ptolemy does not distinguish between functional and implementation components, as well as different levels of design refinements.

One exception is the work of Parnas and Madey [39]. They provide a definition of the key system contents to be modeled for model-based-evaluation in terms of a set of “documents”: System Requirements, System Design, Software Requirements, Software Modules, Data-flow, Protocol Design, and Chip Behavior. Parnas and Madey address the importance of overall system description and modeling of the environmental aspect. While the System Requirement Document provides a “black-box” description of environmental quantities to be measured or controlled and their relations such as physical constraints, the System Design Document describes the computers and peripheral devices within the system, their inputs and outputs, properties, communications, and relationship with the environmental quantities. The Software Requirements Document is a specialization of System Requirements and System Design Documents for the contained software and can be further refined to include a Software Behavior Specification. To allow model-based evaluation, most of these documents have to be defined using mathematical or formal techniques such as mathematical relations, abstract event traces, and state execution traces.

Leveson [40] provides an even broader perspective on modeling support for safety critical software systems. By taking into account a wide range of issues relating to systems theory, cognitive psychology, and human-machine interaction, a system modeling methodology, referred to as “intent specifications”, has been proposed. It addresses four key aspects of system modeling: Process – means-ends traceability, analysis of current design, and synthesis of subordinate design; Content – contained semantic information; Structure – management and organization of information for the purpose of usage; and Form – actual notation or format of information representation. To determining an appropriate modeling support, these four aspects have to be examined in order. While the first aspect defines the goals or tasks of modeling, the other three aspects determine if a modeling support can serve as an effective-medium for decision-making. The content aspect is considered as a very critical issue of modeling, justified by the “out of sight, out of mind” phenomenon observed from cognitive psychology studies. That is, the problem-solving performance of human can actually be impaired with incomplete models that are thought as a comprehensive and truthful representation. In particular, it is suggested that one theoretical basis for determining the completeness of modeling content is the basic system theory, which provides perspectives of systems in general. To ensure consistency of different system representations (i.e. views) and support communication, it is necessary to define a common system specification that defines the system boundary, components, component behaviors and their composition to form the whole, and the intents forming the rationale of system.

Other recent efforts also indicate the importance and awareness of exploiting concepts from systems and architecture in the development of ECS. For example, Keutzer et al [41] discuss the importance of distinguishing between functional and implementation aspects of systems and balancing their optimizations by process

30

measures. They use “platforms” to form a fixed interface between function modeling and implementation and support parallel development of implementation and functions. Thiel and Hein [42] adopt a product line approach to develop “platforms” for managing variability and changes. In the EAST-EEA (ITEA) project [44][51][52], an architecture description language for the embedded electronic architecture of automotive systems is currently under development, covering most of the issues discussed above.

Today’s methodologies and tools for ECS do not support systematic assessment of modularity except resource-driven partitioning and allocation considerations. This is probably due to the lack of a common definition of the systems and hence the key parameters that determine dependencies of components. Another reason is that the focus in the area of flexible ECS is still on the middleware technologies. There are two directions in this area. While some efforts aims to enable integration of different execution and communication schemes and adaptive configuration for quality of services (e.g., Hades [45] and Armada[46]) others focus on resolving heterogeneity and distribution of components and supporting dynamic configuration (e.g., TTA [48], Real-time CORBA [49], and Simplex [47]). It is supposed that system designs are already properly structured and modularized before being mapped onto these technologies.

5. Research Questions

To manage the increasing product complexity and meet the needs of quick time-to-market, high product qualities, and low cost, it is necessary to extend ECS engineering from its traditional focus on enabling technologies to an engineering discipline of system development. To this end, this thesis aims to answer the following two fundamental questions.

Q1. What should be provided to form an integrated view in the multidisciplinary engineering context and to support the incorporation of useful technologies from other engineering and research communities?

Q2. How can we assess flexibility related attributes inherent in early architectural solutions in a more precise way in order to support early system optimization and guide improvements?

As we have discussed, one major problem in current engineering practices of ECS is the absence of a clear description of the overall systems. The comprehension and integration of components are often hampered by the incompleteness of information and the lack of separation of concerns. In particular, design changes and exploitation of “components” become difficult or risky due to the inability to characterize component dependencies and impacts of changes. Also, this makes it difficult for us to manage and integrate techniques from other engineering disciplines and to improve the process efficiency.

31

Therefore, to answer the first question (Q1), we have attempted to provide high-level system models and define the semantics by taking into account ECS specific concerns. These ECS abstractions follow the basic systems concept that is also embedded in systems engineering, engineering design, and software architecting, The considerations are:

• By raising the levels of system descriptions to the fundamental concepts of systems, it is easier to obtain system overviews and to identify the system-wide roles and dependencies of individual efforts, hence to form a more solid basis for specifying and streamlining system solutions, engineering technologies and activities in the development of ECS.

• By providing ECS semantics to the generic systems model and software architecture, it is possible to bridge the contextual gaps between ECS engineering and other closely related engineering communities by clarifying their similarities and differences, and hence to identify and incorporate useful principles, theories, and techniques for improving ECS development.

In order to develop such system models, we have to answer the following questions:

Q1.1 – relating to system components: What are the fundamental components composing the systems? What are their key properties? What are the additional properties of software in ECS?

Q1.2 – relating to the systems as a whole: What are the key aspects and abstraction levels of the systems? What are the relationships between different aspects, levels, and components? What are the additional relationships of software in ECS that affect their compatibility?

Currently, little support exists in this area of quantitative assessment of flexibility related attributes. Existing approaches are either restricted to detailed implementations or based on subjective judgments without taking into account ECS specific concerns. To answer the second question (Q2), we have attempted to provide metrics that quantify the dependencies between components based on the systems model of ECS. In order to provide such a metrics system, we have to answer the following questions.

Q2.2 – relating to dependency metrics: Which system parameters are the contributing factors of components dependency? How can we quantity these parameters? How can we combine such parameters to measure the strength of dependencies?

32

6. Research Approach

This research has been conducted in a spiral process, as depicted in Figure 5. It follows the paradigm of engineering by addressing the exploitation, adaptation, and integration of theories found in systems engineering, engineering design, and software engineering for the development of ECS.

��

��

��

� ��

� ��

��

� � �

! �� "# ��$%� # � &' ��&! ��%�

! �� "�� ( ��%

# $�� )� ��%�

�� *�� %

� + �

��*�� "! ��%�

# ��( ��

� "� �� "� ��"

# $�� "� �� "

,�� $� ��

��' **��

�� # ��

��' ��

' ��$-��

# $ ��-��

# ��

��# � "� �� "�

Figure 5. A spiral traced research, where blocks represent the major research outputs.

In addressing the research questions, one major focus of this work is on the ontology of embedded computer control systems, aiming to find and structure overall concepts and definitions for the content and context of ECS. Due to the promises provided by software architecture for complexity control and built-in flexibility, the first phase of this work was to find an appropriate architecture definition for the software of ECS (i.e., answering questions Q1.1 and Q1.2 for the software). This included a state of the art study on this sub-discipline of software engineering, an investigation of our understanding of ECS systems based on the AIDA project [38], and a collection of our experiences on providing flexibility for embedded computer control software gained from participating in the OSACA (EU-Esprit) project [50]. The AIDA modeling framework covers some important software parameters relating to control functionality and implementation timing. The OSACA project aims to support interoperability, portability, scalability and interchangeability of control software in machine tools, based on a reference architecture for such applications and a software platform consisting of a communication system and a configuration system. These studies converged to a software architecture model, aiming to complement generic software architecture models with ECS specific key properties

33

and relationships and hence merging the semantics gaps between embedded computer control software and generic software applications.

Since ECS is essentially not a software system but a system with software as the primary functional embodiment means, one major effort in the second phase of this work was to find out an ontological definition for ECS as a whole (i.e., answering questions Q1.1 and Q1.2 for the entire system). The effort started by an investigation of current modeling techniques to classify their modeling content, context, representation, and tool support. Another purpose is to evaluate and refine our concepts of systems and modeling, represented as a modeling framework where the software architecture model is embodied. Also, this study was intended to provide inputs concerning current modeling techniques to the development of a new architecture description language in the EAST-EEA (ITEA) project [51][52], which is a European initiative to open embedded electronic architecture for automotive systems. Thereafter, this work proceeded to develop a more objective and formal definition of ECS, aiming to reduce the ambiguity and support formal reasoning of systems.

At the same time, a literature study on engineering design ([14]) and systems engineering ([7]) was also performed. Based these inputs and our previous work on modeling and software architecture, a more precise systems model was developed. This made it possible to answer the research question Q.2.1. The effort started by classifying patterns of dependency in ECS. Then, a metrics system was developed to identify related system parameters and combine these parameters into dependency measures.

7. Contributions and Thesis Summary

The primary contribution of this thesis is that it has laid a foundation for making the development of ECS a more disciplined engineering approach. The five parts of this thesis in different ways provide support for obtaining holistic and common views on the systems, and promoting collaboration with related fields of engineering research in the areas of process management, complexity control, exploitation of components, and system optimization. Especially, the five parts of this thesis make contributions in the following four subjects:

• To software design (Part A, B): Providing a foundational concept of embedded computer control software architecture by extending generic software architecture concepts with additional design dimensions, levels, and parameters.

• To model-based system design (Part C): Providing a well-structured specification of modeling features in a larger ECS engineering context, and codifying various modeling concepts and patterns.

34

• To systems specification (Part D): Providing a domain specialized ontology of systems and a practical means of precisely parameterizing concerns.

• To quality analysis (Part E): Extending the scope to cover flexibility related attributes by identifying system parameters contributing to modularity and providing a practical means of quantifying this attribute in high-level design.

7.1 Part A: Architecture for Mechatronics Software Systems – A Survey of Related Concepts, Theories and Methods

The first part, Part A, provides a survey of key concepts of software architecture from software engineering, which constitute the initial point of this research and have affected and inspired it in many ways.

It investigates many fundamental issues in the development of software systems, including incremental design, characteristics of requirements, definitions of software architecture and software components, architecture modeling and analysis, styles, etc. Further, three solution architectures (i.e., OSACA, Simplex, and TTA) are described in order to show the role of structuring for system qualities in the large. This study codifies various concepts, theories, and methods in software architecture and discusses their advantages and weaknesses for ECS.

7.2 Part B: Towards a Framework for Architecting Mechatronics Software Systems

Part B presents a software architecture model for embedded computer control software systems, resulting from our early effort to adopt the concept of software architecture for embedded computer control software systems.

Software architecture follows the basic systems concept and defines the architecture as a set of structural entities and relationships. However, due to the application specific contextual difference, it often does not take into account system features that are of vital importance for ECS, such as timing, concurrency and synchronization, and system functional semantics. Instead, technologies developed in the domain of software architecture normally focus on the commonality and procedural aspects of software systems. Since an explicit architecture is important for complexity control, structuring, and creation and integration of components, there is a need to extend or refine software architecture from its generic application based view to an embedded computer control based view.

The software architecture model presented in this part further develops the basic software architecture model proposed by Perry and Wolf [54]. It consists of a multi-dimensional expansion of the design space, followed by a multi-layered refinement hierarchy, together with many ECS specific semantics and relationship. See Figure 6. It helps to ensure that all important system aspects and features are taken into

35

consideration when reasoning about software architecture and components for embedded computer control, and to properly separate and organize the concerns. As a natural consequence of the architecture model, we also developed a design guide, called decision model, to support basic reasoning of flexibility improvements for embedded computer control software.

��

��+ ��,��

-.��$��

� ��,��

��

��" � ��

�$��" � ��

* �� $��" � ��

�( � � $��

* ��

�( �!��

Figure 6. Key concepts in the software architecture model.

7.3 Part C: A Modeling Framework and Survey for Embedded Computer Control Systems

Part C presents a framework for characterizing and comparing modeling techniques and a study of 12 modeling approaches covering different levels of design and disciplines.

Modeling constitutes an indispensable part of engineering, forming an important basis for documentation, comprehension, and decision-making. Due to the inherent multidisciplinary nature of ECS and the need for complexity control, a variety of models and modeling techniques can be exploited to support the development. Currently, an increasing amount of modeling languages and tools, which can be more or less related ECS, have been built in different research communities. As a consequence, one central problem for ECS developers is to identify, integrate, manage, and further develop appropriate modeling supports. To this end, a model-of-modeling, referred to as modeling framework, is necessary to define important modeling issues of ECS and provide necessary perspectives. There are a number of existing modeling frameworks. However, the lack of considerations of embedded computer control specific issues both in systems and in the development context limits their usefulness.

The modeling framework presented in this part aims to constitute a basis for supporting model-based system development of ECS and developing new modeling techniques. The framework defines important modeling factors, classified into

36

content, context, representation and tool support, based on a generic concept of systems and an identification of fundamental roles of modeling (see also Figure 7). The content factors characterize predefined system abstractions in a modeling approach with their properties and relationships. The context factors profile each modeling approach with respect to the targeting design and quality analysis, which provide some fundamental constraints on modeling such as of completeness, consistency, and management of information history. The representation and tool support factors characterize user support. The framework has been evaluated and refined by surveying and comparing existing modeling techniques, covering different levels of design and disciplines. It has shown to be useful as a basis both for the evaluating of new modeling techniques and for understanding existing modeling techniques [53].

! �� "��

" ��

� ��

��/ ��

� ��

�&*��*�� +&*�� "��

��*�� **��

$��

��

�� $��

��

�� $��

� ��

�� .��

��

��$��

0��

��

Figure 7. Roles of modeling in system development.

7.4 Part D: A Systematic Approach for Identifying Operational Relationships in Embedded Computer Control Systems

Part D presents a meta-level systems model for ECS and a fine-grained classification of relationship patterns established by communication, synchronization, and implementation in the system solutions.

In ECS, software components constitute the embodiments of functional modules. To modularize the design and to create and integrate software components, a more precise modeling of systems and a more exact knowledge about components are necessary. Incompatibility of software components usually arises due to the lack of exact knowledge about the system context in which the components exist, such as their system wide functional assumptions and concurrency inherent in the functional solutions. However, little support exists in this area. Existing system models and modularity metrics such as coupling and cohesion are often either too general or too specific by targeting only a specific implementation technology. Component-based software engineering (CBSE) aims to support the development of systems by integrating existing solutions, hence reducing complexity and increasing efficiency of system development. However, current CBSE technologies are still insufficient

37

for ECS software because its focus on the management of binary components and middleware technologies for interoperability.

The meta-system model presented in this part of thesis evolves our previous work on modeling and architecture. It provides a more objective definition of systems content and a more precise description using basic set theory. (A short summary can be found in Part E). Figure 8 depicts the concept behind the meta-model. Based on a system definition, various operational relationship patterns inherent in ECS functional solutions have been derived and specified. These relationships patterns contribute to varying dependencies of system modules. This work forms a basis for our next work on dependency measurement for ECS modularity.

/��

,�*�

# ��

Level

, �� 0��

Boundary ��

�

Content

FuncSol

ImplSol Impl1 Impl2 Impl3 Implm-1

Func1 Func2

Func3 Func4 Funcn

ImplEnv1

FuncEnvp

ImplEnvq

FuncEnv1

Implm

Figure 8. An illustration of means and aspects in the solution domain of embedded computer control systems.

7.5 Part E: A Metrics System for Quantifying Operational Coupling in Embedded Computer Control Systems

Part E proposes a technique for quantifying the operational coupling in embedded computer control systems.

One of the most challenging problems in the areas of high-level quality assessment and multi-attribute system optimization is to support objective and repeatable measurement of flexibility related attributes. Normally, subjective judgments are used to assess the satisfactions. However, when large and complex systems are under consideration, common sense and experiences are often not sufficient. Moreover, the lack of quantified measures also hampers the possibility of performing early system optimization. One key factor that affects the success of complexity control, concurrent engineering and product flexibilities (including reusability and modifiability) is modularity, referring to the extent to which a system is decomposed and structured into individual parts. In the context of software engineering, modularity is often considered in terms of coupling and cohesion. As a rule-of-thumb, good software systems should exhibit low coupling and high

38

cohesion. Currently, little support exists for quantifying modularity of high-level design. Existing approaches mainly target detailed software implementation, such as confining to the inheritance and method invocation relationships in OO software. Due to their restrictions to implementations details, such approaches have very limited usability in this design context.

The metrics system presented in this part provides support for measuring the inherent dependencies of system parts determined in the system functional solution, given as relationship patterns in our previous study. It measures the strength of such dependencies by considering both generic parameters such as frequency, and ECS specific parameters such as timing accuracy and replication. The aim is to form a more solid engineering basis for high-level design by progressing from subjective judgments to objective assessments. A further goal is to form a basis for developing attribute models for other “soft” qualities, such as modifiability. See Figure 9. The metrics system has two parts. The first part supports a measurement of coupling by considering individual relationship types separately. The second part provides a methodology for combining coupling by individual relationship types into an overall coupling, where domain specific heuristics and technology constraints are used to determine the weighting.

" �$�� $��

Systems characteristics

Domain of subjective and qualitative estimation

Domain of objective and quantitative measurement

111 ��$��

� ��

Attributes model for quality predictions

��

Figure 9. Closing the loop of design for flexibility related qualities.

8. Conclusions and Future Research

This thesis provides a number of improvements in the areas of systems modeling and flexibility assessment for ECS. The presented software architecture model and systems model help to obtain system wide perspective and ensure the completeness of system descriptions and component specifications. They also constitute the vehicles necessary for allowing ECS engineers to take advantage of useful technologies and expertise from the domains of systems engineering, engineering design, and software architecture. The presented modeling framework provides an important source of understanding the roles of modeling in large and complex ECS. The results have shown to be directly useful as a basis both for the development of new modeling techniques and for comparison of existing modeling techniques. The presented metrics system provides support for quantifying operational dependences of system components in high-level design of ECS, hence constituting a better

39

support for reasoning about modularity and making early tradeoff analysis and system optimization possible.

Based on the results of this research, there are many possible avenues for future research. Beyond further evaluating and refining the results as well as obtaining empirical evidences of their usability in engineering practices, we have the following most directly related areas of future research.

Based on the systems ontology given in this work, one future research area is concerned with ECS process management. We have started to consider how to use the systems model as a basis for systematizing the engineering process of ECS and defining an ECS process model with well-defined design activities and design decisions. The initial study is described in [55]. In the future, a mapping of process parameters and analysis techniques should also be defined. This will help us to codify, compare, and integrate important principles, analysis methods, and practical experiences with respect to system structure and behavior, and hence to develop an engineering framework for ECS. Future research should also consider how to develop a new software process and framework, based on the software architecture model, to guide the engineering of software and components in the ECS specific system context.

Another research area is concerned with integration of modeling techniques. Future research can develop an ECS specific system design language and modeling tools that provides a systems core for associating and integrating other more dedicated modeling techniques. This follows the idea of ACME [23], which provides a structural core for translating specifications by other ADLs.

Based the systems ontology, there are also other future research possibilities. One direction is to codify important structuring patterns and develop new approaches and methods to support system structuring. Another direction is to drive a more precise component model that takes into account both analytical and operational contexts in a hierarchical definition of systems. It is also possible to exploit the systems model for educational purposes.

Future research should also consider how to devise quality metrics that are largely missing from state of the art technologies. This requires inputs from other scientific and engineering domains. We have begun to explore ways in which the systems-model can be used as a basis for developing a complexity metrics, which characterizes the number and variety of relationships patterns in a system solution based on information theory. Another issues is concerned with the integration of various metrics in existing engineering tools and process to support system optimization throughout design.

40

9. References

[1] J. Wikander, M. Törngren. “Mechatronics as an Engineering Science”, Proceedings of the 6th UK Mechatronics Forum International Conference, 1998.

[2] ROADMAP, Hard Real-Time Development Environments, (W1.A1.N1.Y1), ARTIST Project IST-2001-34820. < http://www.artist-embedded.org/Roadmaps/ >

[3] M. Weber, J. Weisbrod. Requirements Engineering in Automotive Development: Experiences and Challenges. IEEE Software. Vol: 20, Issue: 1, Jan.-Feb. 2003.

[4] B.Graaf, M. Lormans, H.Toetenel. Embedded software engineering: The state of the practice, IEEE Software, Vol: 20, Issue: 6 , Nov.-Dec. 2003

[5] H. Hanselmann. Development Speed-Up for Electronic Control Systems, dSPACE GmbH / dSPACE, Inc., Distributed on the occasion of Convergence 98, Dearborn, USA. October 19–21, 1998.

[6] R. Stevens, B. Peter, J. Ken, A. Stuart. Systems engineering – coping with complexity, Pearson Education, Prentice Hall. 1998.

[7] W.L. Chapman, A.T. Bahill, A.W. Wymore. Engineering Modeling and Design, CRC Press. 1992.

[8] International Council on Systems Engineering (INCOSE) < http://www.incose.org>

[9] A.T. Bahill, B. Gissing. Re-evaluating systems engineering concepts using systems thinking, IEEE Transactions on Systems, Man, Cybernetics, Part C, Vol: 28, Issue:1, Nov.1998.

[10] E. Rechtin, M.W. Maier. The Art of System Architecting, CRC Press, 1997.

[11] J. Daniels, P. W. Werner, A. T. Bahill. Quantitative Methods for Tradeoff Analyses, Systems Engineering, Vol. 4, No. 3, 2001.

[12] T. Shell. The Synthesis of Optimal Systems Design Solutions, Systems Engineering, Vol. 6, No. 2, 2003.

[13] B. Prasad. Concurrent Engineering Fundamentals, Volume I: Integrated Product and Process Organization. New Jersey: PTR Prentice Hall, 1996.

[14] N. P Suh. Axiomatic design: Advances and Applications, Oxford University Press. 2001.

[15] D.P. Clausing. Total Quality Development, ASME Press, New York, 1994.

[16] G. Pahl, W. Beitz. Engineering design: a systematic approach. Design Council, London, 1984.

[17] F. Engelhardt. Improving Systems by Combining Axiomatic Design, Quality Control Tools and Designed Experiments, Research in Engineering Design, 12:204–219, 2000.

[18] N.Leveson. Safeware: System safety and computers, Addison-Wesley Publishing Company. 1995.

[19] M. Shaw, D. Garlan. Software Architecture – Perspectives on An Emerging Discipline,

41

Prentice Hall, 1996.

[20] L.Bass, P.Clements, R. Kazaman. Software Architecture in Practice, Addison-Wesley,1998.

[21] P.B. Kruchten. The 4+1 View Model of architecture, IEEE Software, Vol. 12, Issue: 6, Pages: 42 – 50, Nov. 1995.

[22] A Guide to CASE Tools in Support of System Architecting- Background, Capabilities and Selection, Draft Version, Systems Architecture Working Group (SAWG), INCOSE, Jan 1997. <http://www.incose.org/cmtes/sawg.html>

[23] D. Garlan, R. Monroe, D. Wile. ACME: An Architecture Description Interchange Language, Proceedings of CASCON’97, Nov. 1997.

[24] R.J. Allen. A Formal Approach to Software Architecture, Ph.D. Thesis, Carnegie Mellon University, CMU-CS-97-144, May, 1997.

[25] D. C. Luckham and J. Vera. An Event-Based Architecture Definition Language, IEEE Transactions on Software Engineering, pages 717-734, September 1995.

[26] IBM Rational Rose RealTime: A guide for evaluation and review, Jun 2003 <http://www-106.ibm.com/developerworks/rational/library/622.html>

[27] R. Kazman, L.Bass, G.Abowd, M.Webb. SAAM: a method for analyzing the properties of software architectures, IEEE 16th International Conference on Software Engineering, 1994.

[28] R. Kazman, M. Klein, M. Barbacci, T. Longstaff, H. Lipson, C. Jeromy. The Architecture Trade-off Analysis Method, Fourth IEEE International Conference on Engineering of Complex Computer Systems (ICECCS98), Aug. 98.

[29] D.E. Perry, A.L. Wolf. Foundations for the Study of Software Architecture, ACM SIGSOFT Software Engineering Notes, 17:4 , Oct 1992.

[30] G. Chastek, J.D. McGregor. Guidelines for Developing a Product Line Production Plan, Technical Report, CMU/SEI-2002-TR-006, 2002.

[31] M. Norris, R. Davis. A. Pengelly, Component-Based Network I, Artech House, 2000.

[32] ROADMAP, Component-based Design and Integration Platforms, (W1.A2.N1.Y1), ARTIST Project IST-2001-34820.< http://www.artist-embedded.org/Roadmaps/ >

[33] M. Törngren. Embedded Systems of Strategic Importance for Swedish Society-where are the needs and how should efforts be directed?, 7th Biannual Snart Conference on Real-Time in Sweden, Aug. 18-19, 2003, Västerås, Sweden

[34] IEEE Std 610.12-1990, IEEE Standard Glossary of Software Engineering Terminology, 1990.

[35] E. A. Lee. Overview of the Ptolemy Project, Technical Memorandum UCB/ERL M01/11, University of California, Berkeley, March 6, 2001.

[36] O. Redell, J. El-khoury, and M. Törngren. The AIDA toolset for design and implementation analysis of distributed real-time control systems, Microprocessors and Microsystems, Volume 28, Issue 4, Pages 163-182, May 2004.

42

[37] T. Demmeler, B. O’Rourke, P. Giusto. Enabling Rapid Design Exploration through Virtual Integration and Simulation of Fault Tolerant Automotive Application, Society of automotive engineers, Document Number: 2002-01-0563, 2002.

[38] M. Törngren, O. Redell. A Modelling framework to support the design and analysis of distributed real-time control systems, Journal of Microprocessors and Microsystems, Volume 24, No. 2, Elsevier, 2000.

[39] D. L. Parnas, J. Madey. Functional Documents for Computer Systems. Science of Computer Programming. Vol. 25. Elsevier, 1995.

[40] N. Leveson. Intent Specifications: An approach to building human-centered specifications. IEEE Transactions on software engineering, Vol. 26, no. 1, p. 15-35. Jan. 2000.

[41] K. Keutzer, A.R. Newton, J.M. Rabaey, A. Sangiovanni-Vincentelli. System-level design: orthogonalization of concerns and platform-based design. IEEE Transactions on Computer-Aided Design of Integrated Circuits and Systems. Vol. 19. No 12. P. 1523-1543. Dec. 2000.

[42] S. Thiel, A. Hein. Modeling and Using Product Line Variability in Automotive Systems. IEEE Software. July/August 2002. P66-72.

[43] UML™ Resource Page, <http://www.uml.org/>

[44] EAST-EEA, Embedded Electronic Architecture, <http://www.east-eea.net/>

[45] E.Anceaume, G. Cabillic, P. Chevochot, I. Puant. HADES: a middleware support for distributed safety-critical real-time applications, Proceedings of 18th International Conference on Distributed Computing Systems, 1998.

[46] T. Abdelzaher, M. Bjorklund, S. Dawson, W.-C. Feng, F. Jahanian, S. Johnson, P. Marron, A. Mehra, T. Mitton, A. Shaikh, K. Shin, Z. Wang, H. Zou. ARMADA Middleware and Communication Services, Real-Time Systems, Kluwer Academic Publishers, 1997.

[47] L. Sha, R.Rajkumar, M. Gagliardi. Evolving Dependable Real-time Systems, Proceedings of IEEE Aerospace Application Conference, Vol:1, Feb.,1996.

[48] H. Kopetz. The time-triggered model of computation, Proceedings of 19th IEEE Real-Time Systems Symposium, 1998.

[49] V. Fay-Wolfe, L.C. DiPippo, G.Cooper, R. Johnson, P. Kortmann, B. Thuraisingham. Real-time CORBA, IEEE Transactions on Parallel and Distributed Systems, Vol: 11 , Issue: 10, Pages:1073 – 1089, Oct. 2000.

[50] P. Lutz. Designing Applications for an OSACA Control, Proceedings of the International Mechanical Engineering Congress and Exposition, Dallas/USA, November 16-21, 1997.

[51] T. Thurner, J. Eisenmann, M. Haneberg, S. Voget, R. Geiger, U. Virnich. The EAST-EEA project - a middleware based software architecture for networked electronic control units in vehicles, Electronic Systems for Vehicles, Baden-Baden, Germany, VDI Berichte 1789, Sep 2003.

43

[52] H. Lönn, T. Saxena, M. Nolin, M. Törngren, FAR EAST: Modeling an Automotive Software Architecture Using the EAST ADL, ICSE 2004 workshop on Software Engineering for Automotive Systems (SEAS), Edinburgh, May 2004.

[53] T. Saxena. System Modeling Using the East ADL. MSc. Thesis, Computer Engineering, Chalmers Institute of Technology, Sweden, 2004.

[54] D.E. Perry, A.L. Wolf. Foundations for the Study of Software Architecture, ACM SIGSOFT Software Engineering Notes, 17:4. October 1992.

[55] Ola Larses, DeJiu Chen, The Monty Model for Engineering of Mechatronics Systems, Technical Report, TRITA-MMK 2003:11ISSN 1400-1179, ISRN/KTH/MMK/R-03/11-SE, 2003.

Systems Modeling and Modularity Assessment for Embedded...

Documents

Transcript of Systems Modeling and Modularity Assessment for Embedded...