Embedded Systems: Analysis and Modeling with SysML, UML and AADL

Foreword

I am pleased to be asked to write this preface for two reasons. One was to provide fair evidence in favor of pre-existing prejudices. The other was to see the use of the PACEMAKER System Specification as a common subject for the application of SysML, MARTE, and AADL.

Previously only familiar with SysML and MARTE through presentation and tutorial, I expanded and sharpened my understanding of their adaptability to each user’s (company’s) needs. From UML, SysML and MARTE come notations that neither prescribe nor proscribe design methods or tools. The power of defining one’s own semantics comes at the cost of defining one’s own semantics.

In the domain of embedded electronic control systems using software, AADL reigns supreme. I serve on SAE International AS-2C standard subcommittee that issues the AADL standard and its annex documents, so please understand my enthusiasm in the context of a true believer. AADL is not suitable for modeling an entire aircraft, just its avionics. Where SysML/MARTE hands-off to AADL for electronics and software architecture should be at the edge of the electronics (sensors, actuators, displays). Lowest-level SysML/MARTE components trace to top-level AADL components.

Tracing between SysML and AADL might be done using RDALTE¹ ² which links requirements to architecture. Currently RDALTE links to AADL, using OSATE2, but it is designed to be architecture agnostic. To easily add linking to SysML/MARTE models is a feature of RDALTE.

More personally, the PACEMAKER System Specification used in this book and many published papers was provided by Boston Scientific for use in research and education as a public service. Its origin was serendipitous.

While attending Formal Methods 2006 held at McMaster University in Hamilton, Ontario, I happened to catch a ride with Jim Woodcock. Jim originated the Verification Grand Challenge problem of a Mondex electronic wallet used as the subject of several papers at the conference. Mondex was a clean, simple problem for which a specification had been written in Z. Given the dearth of conference attendees from industry Jim pounced upon me exhorting a real-world problem, complex enough to challenge formal methodologies, but not so large as to preclude use by small, academic teams. I told him I’d try to find such a problem.

Rooting around, I found a concise, system specification of a pacemaker designed in the 1990s that was company confidential. However, the company’s confidentiality policy made no mention of publicly releasing confidential documents akin to declassification of secrets. Therefore approval of public release would need to come from upper management. With the assistance of many people in Boston Scientific’s Formal Methods Group, the document was converted to LaTeX, stripped of proprietary content and mentions of Boston Scientific products, and repeatedly reviewed. The Software Quality Research Laboratory at McMaster University agreed to host the document and its FAQ³. Finally, all approvals were obtained, and the document released, six months after that fateful car ride with Jim.

This book succinctly explains three popular languages used to model systems, each complex subjects themselves, in remarkably few pages. Those that want to understand fundamental concepts and differences of SysML, MARTE, and AADL will find this book’s use of a common subject helpful.

Brian R. LARSON

Research Associate, Kansas State University

U.S. Food and Drug Administration Scholar in Residence

March 2013

1 Requirements Development and Analysis Language Tool Environment.

2 See AADL information center at http://www.aadl.info for more details.

3 http://sqrl.mcmaster.ca/pacemaker.htm

Foreword

In the introduction to the report¹ of the mission Generic embedded software components, which was entrusted to me in 2010 by the French Minister for Industry, the Secretary of State for Forward Planning and Development of the Digital Economy, and the General Commissioner for Future Investments, there is a reminder that:

The technologies of embedded systems, embedded software, and microelectronics have the capacity to transform all the objects of the physical world – from the smallest to the largest, from the most simple to the most complex – into digital, intelligent, autonomous and communicative devices. The emergence of the Web of Objects, the connection between the world of the Web and the world of embedded systems, considerably amplifies this revolution.

Indeed, the general deployment of embedded systems significantly changes our environment, has brought about numerous innovations in products and uses, and impacts all industrial activities and services.

Mastering the engineering of embedded systems is, therefore, a key element in industrial competitiveness. However, achieving this mastery is still a complex and costly process because of the breadth of the technological field, the diversity and complexity of requirements and solutions. This is illustrated well by the different views of this type of engineering proposed by the embedded systems common technical baseline² or CTB:

– The system view describes the actual embedded system, that is its architecture, and all its hardware and software components (processing units, bus and operating system (OS) networks, middleware, application software).

– The design tools view shows all the design tools (modeling, simulation) used.

– The lifecycle view of the product describes the activities and where they are involved in the design, development and implementation of an embedded system.

Figure F.1. System views (left), lifecycle (center) and design tools (right)

Examination of these different views shows the importance of modeling activities in embedded systems engineering. Therefore, with each level and each element in the system view – architecture, processors, bus and networks, software, etc. – correspond, as shown in the lifecycle and design tools of the product, the models and modeling tools that assist and validate the different stages of development.

This book is, therefore, particularly welcome. It responds to the demand from engineers and students for an approachable book that presents the protocols and principles of modeling embedded systems. We note, in this regard, that there is a particularly strong demand from many engineers with an initial training in electronics who must face a rapid evolution in their activities toward system and software design and modeling. In the report cited above, it is noted that for the SME and research departments in electronics, we are a long way from completing the transformation to embedded software. As noted in the competitiveness and innovation of SME by the electronics (CAPTRONIC) program, these businesses have today too little competence in developing embedded software (a lack of methodology and of tools) and are, therefore, more and more confronted with strict and tough requirements from their clients (instructing parties, system integrators and end users) in terms of robustness and functional reliability.

Another important issue in this book is the process followed to explore the subject. In a pedagogic manner, the presentation of each modeling method is followed by a detailed application of a commonplace case study through which the stages of the activities described in the approaches presented beforehand are clearly demonstrated.

Finally, this book illustrates the dynamism and quality of the research community in France, as much academic as industrial, in terms of modeling languages and tools for embedded systems, and also its role in the bodies standardizing these languages. On this occasion, it is necessary to reaffirm the importance of these standardization activities that allow scientific and technological advances to be recognized and validated by everyone at the international level and that are the reference for developers. In this regard, the MARTE standard (UML profile for modeling and analysis of real-time embedded systems), which is presented in part 3 of this book, is a direct result from an initiative launched in 2006 by a group of researchers from THALES and CEA LIST (of whom several are authors of this book) and which resulted in 2009 in the adoption of MARTE standard 1.0 by the Object Management Group (OMG). Moreover, several authors of parts 3 and 4 of this book are also very active in standards bodies for systems modeling language (SysML) and architecture analysis and design language (AADL).

It is my hope that this book meets great success and contributes to creating the next generation of embedded systems designers.

Dominique POTIER

March 2013

1 Briques génériques du logiciel embarqué, Dominique Potier, October 2010 (see www.ladocumentationfrancaise.fr/rapports-publics).

2 Developed in 2008 by B. Bouyssounouse (VERIMAG), T. Veitshans and C. Lecluse (CEA), the embedded systems common technical baseline is a reference, a guide and a knowledge base for embedded systems (see www.embedded-systems-portal.com/CTB).

Foreword written by Dominique POTIER.

Introduction

I.1. The issue

Since the construction of the first embedded system in the 1960s, the Apollo Guidance Computer [WIK 12a], embedded systems have continued to spread. They provide a continually increasing number of services and are part of our daily life: elevators, transport (signaling, airplanes, automobiles and railways), telephone services, medicine, energy, industry, etc.

Hence, as we speak more and more of embedded systems, we generally forget their primariy characteristics. The definition given by Wikipedia is as follows [WIK 12c]:

Embedded computer science represents the software part located in larger systems that are not strictly dedicated to computing. The assembly of software and hardware integrated into a system is called embedded system.

Therefore, a key point in the development of embedded systems is their interaction with their environment and the impact that can result in terms of safety and reliability.

The development of these systems is a difficult problem, which does not yet have a global solution. Of course, airplanes fly, robotic vehicles land on planets millions of kilometers from Earth. However, the development of embedded systems for these purposes still requires a huge amount of energy and work and the use of complex technologies that are difficult to master.

Another difficulty is that systems are plunged into the real world, which is not discrete (as is generally understood in computing), but has a richness of behaviors that sometimes hinder the formulation of simplifying assumptions.

Finally, they are generally autonomous and must face possibly unforeseen situations (e.g., incidents), or even situations that lie outside the initial design assumptions. Let us consider the SPOT [WIK 12b] communication satellites. The project started in 1978 and the first satellite was launched in 1986; the last (sixth-generation) satellites are planned to be launched in 2012 and 2013. SPOT-2, which was originally intended to last for 3 years, was functional for 20 years. This illustrates the difficulty of predicting future uses of technology at the design stage¹.

I.2. Purpose of this book

Having started as a craft, the construction of embedded systems has become industrialized in line with the increase in the diversity of their applications and use. Methodologies are sketched out, perfected and refined.

The purpose of this book is to indicate the state of the art in the development of embedded systems and, in particular, to concentrate on the modeling and analysis of these systems. These are the key operations that will determine the reliability of future systems.

There are currently three approaches to model-driven engineering (MDE²): systems modeling language (SysML), unified modeling language/modeling and analysis of real-time and embedded systems (UML/MARTE), and architecture analysis and design language (AADL). All three are the results of international collaborations and focus on different aspects of embedded systems. SysML discusses the systems engineering aspect, whereas UML/MARTE and AADL discuss, in different contexts and with different approaches, the design, analysis and development phases.

Therefore, it is important to present all three approaches in this book in order to provide the reader with a global view of their possibilities. We also demonstrate the contributions of each approach in different stages of the software lifecycle.

I.3. Structure

This book is structured into four parts.

Part 1 comprises two chapters. Chapter 1 presents some general concepts which seem useful to us. Because two of the specification languages are based on UML, presenting this notation is useful. Similarly, we also sketch the main issues in developing embedded systems.

Chapter 2 presents the simplified specifications of a case study that is common to the approaches addressed in this book: a pacemaker. The chapter discusses a simplified version of a specification published in 2007 by Boston Scientific [BOS 07]. This case study is a common thread that enables the reader to observe how the different aspects of a system are addressed using different approaches. The interesting point of this case study is that it has also been approached with methods other than those presented in this book, and this allows the reader to compare their expressiveness and the associated analytical tools.

Parts 2–4 each deal with one of the approaches addressed in this book: SysML (Part 2), MARTE (Part 3) and AADL (Part 4). They follow the same structure closely. The first chapter presents the notation associated with the process, and the second chapter discusses the modeling of the case study. These are followed by a chapter dedicated to analysis of the specification. For parts 3 and 4, an additional fourth chapter is dedicated to automatic code generation.

I.4. Acknowledgments

Before closing this introduction, the coordinators wish to thank the various people without whom this book would not have been possible:

– Dominique Potier from the System@tic competitiveness cluster, who wrote Foreword of this book;

– the numerous authors who, dispersed around France, coordinated and exchanged their opinions in order to present a consistent view of the considered approaches;

– the SEE and their editorial committee who encouraged us in our editorial efforts;

– the GDR GPL (Génie de la Programmation et du Logiciel [CNR 12]) of the CNRS which, through its grant, supported coordination meetings for the authors while preparing this book.

I.5. Bibliography

[BOS 07] BOSTON SCIENTIFIC, PACEMAKER System Specification, January 2007.

[CNR 12] CNRS, Page d’accueil du GDR GPL, 2012. Available at gdr-gpl.cnrs.fr.

[WIK 12a] WIKIPEDIA, Apollo guidance computer, 2012.Available at en.wikipedia.org/wiki/Apollo_Guidance_Computer.

[WIK 12b] WIKIPEDIA, SPOT (satellite), 2012. Available at en.wikipedia.org/wiki/SPOT_(satellite).

[WIK 12c] WIKIPEDIA,  Système embarqu, 2012. Available at fr.wikipedia.org/wiki/Systeme_embarque.

[WIK 12d] WIKIPEDIA, Zuse 3, 2012. Available at en.wikipedia.org/wiki/Z3_(computer).

1 Remember that computing is a science which is more than 70 years old, if we refer to the creation of the first computer, the Z3 [WIK 12d], by Konrad Zuze in 1941.

2 Section 1.4.1 (Chapter 1) describes this concept.

Introduction written by Fabrice KORDON, Jérôme HUGUES, Agusti CANALS and Alain DOHET.

PART 1

General Concepts

Chapter 1

Elements for the Design of Embedded Computer Systems

1.1. Introduction

The development of embedded systems is usually done using low-level languages: namely, assembly language and oftentimes C. The main reason for this is the need to elaborate programs that have a small memory footprint because they are usually deployed on very compact architectures¹. More costly development techniques have been gradually created. These development techniques are mainly based on an in-depth assessment of the requirements, intensive tests as well as very strict development procedures, which ensure a safety standard satisfying the expectations of the general public.

However, these systems that often accomplished critical missions frequently involved very expensive developing strategies, thereby being limited to a specific usage such as space travel, aeronautics, nuclear use and railroad transportation. Once these systems emerged in more mainstream industries, the approaches in development had to evolve in a cost-reducing direction. The economic revolution toward offshore development does not facilitate these aspects of viability/safety, but these new development approaches could, in the long run, become very competitive.

The mere use of high-level programming languages is not, in and by itself, the solution. Embedded systems usually contain sophisticated mechanisms and runtime libraries. Because the latter cannot be certified, they are very difficult to use. Take the Ada language as an example of this. It was elaborated in the 1970s with the aim of developing low-cost embedded systems. Some of its features (usually the management of parallelism) have seen limited usage in certain fields, largely due to the code compiled having to be associated with limited runtimes (for instance, not being able to support the parallelism or the dynamic memory allocation).

One solution to maximising software viability and minimizing the cost of embedded computer systems is through the use of model-driven engineering (MDE). It indeed facilitates better interactions between the different languages and models used throughout the design/development cycle.

More particularly, it allows us to rely on dedicated models, which sometimes facilitate the reasoning process. Thus, engineers can predict certain behavioral aspects of their programs. The transformation techniques that have been developed by this community ensure the link between the different development stages.

These new approaches will not suddenly replace the existing procedures. The actors behind the development of embedded systems (particularly when they carry out critical missions) cannot afford to take any risks. However, these actors have gradually taken an interest in these new techniques and their application in adequate methodological frameworks.

In the long run, the objective is to reach high-performance industrial processes capable of ensuring trustable software, by providing, for instance, co-simulation and formal verification and allowing the target code generation to be validated right from the beginning of the modeling.

It should not surprise us that the three notations presented in this book – systems modeling language (SysML), unified modeling language/modeling and analysis of real-time and embedded systems (UML/MARTE), and architecture analysis and design language (AADL) – are heavily reliant on model engineering. Model engineering is clearly a hot topic in the community at the moment.

Chapter outline. This chapter discusses several elements that are important in the development of embedded systems in the context we have just touched upon. We pay particular attention to:

– the modeling activity (section 1.2);

– the presentation of the UML, which serves as the foundation for two of the three notations presented in this book (section 1.3);

– the presentation of the MDE (section 1.4);

– an overview of the analysis techniques and, in particular, those used in this book (section 1.5);

– the methodological aspects of system development (section 1.6).

1.2. System modeling

The modeling operation has been a widespread practice in the history of humanity. It seeks to explain the behavior of a complex system via a model that abstracts it. We can cite the different models designed for explaining celestial movements: the system of the epicycles, the Ptolemaic system, the Tycho Brahe system, the Copernican system, etc. Their objective was to predict the evolution of the planets’ position. They represent a process of ongoing fine-tuning of the understanding of a field, a new system replacing the old system when new evidence crops up showing that the old system does not correspond to reality. Modeling has, therefore, been an indispensable tool in experimental sciences for a long time.

In computer science, the big difference lies in the fact that the model does not reproduce a system we are trying to observe in order to understand its behavior. The model is placed at an earlier stage, and allows us to realize whether a solution, which is in the process of being discovered, will respect the properties expected.

Figure 1.1. Relations between the system, its model and their properties

Figure 1.1 represents the relation between different entities of a system at the core of the modeling operation. The engineer models the system while he or she is in the process of designing it. The analysis of this model (via simulation or via more formal methods, see section 1.5.1) allows us to deduce system properties. However, the relation between the properties of the model and those of the system is by no means a trivial issue.

First, the expression of the properties may vary greatly in the two cases. Usually the property of the system will be expressed in a natural language, whereas the property of the model will have the shape of an invariant or will reference quite precisely an entity of the analysis (whose meaning must be known to the users if they wish to understand it). We must thus anticipate elements of traceability between the two.

Second, the necessary abstraction of certain system elements during the modeling process (for instance, changing from discrete types to continuous types) can, when done poorly, result in a model that does not faithfully represent the system. If it is a superset, then a property that has not been verified on the model can be verified on the system; if it is a subset, then a property that has been verified on the model may not be true for the system.

Modeling is thus a challenging operation that must be carried out carefully. More particularly, the modeling choices must be documented properly. In the field of embedded systems, we will introduce several important notions regarding the concept of a model.

Structural or behavioral modeling. The former defines the structure of a system (i.e. the class diagrams or the UML instances) whereas the latter describes its behavior. When examining problematic behaviors, or identifying emerging behaviors, we must reach the second level, which generally presupposes that the modeling of the system structure already exists (at least the identification of the interacting actors).

Open or closed models. An open model describes a system. A closed model describes the system and the environment it interacts with. We can, thus, consider that the open model is included in the closed model.

The reason we need to distinguish between the two is that we are able to subject the model of a system to different conditions of execution. Each of them is thus characterized by a dedicated specification of the environment that closes the specification. This notion is particularly useful when we study different execution modes: a nominal mode, modes that have been degraded as a consequence of certain conditions, etc.

Notations used in this book. This book deals with embedded systems and only uses the notations that enable us to describe those systems. Out of these, we have selected three. Of the three, SysML [OMG 12a] and MARTE [OMG 12b] are UML profiles, and AADL [SAE 09] is a dedicated notation that integrates, at the same time, the description of the software part and that of the hardware part of a system.

1.3. A brief presentation of UML

The first version of the UML was version 2.8 of the unified method, which was written by G. Booch and J. Rumbaugh. At the time, in 1995, Y. Jacobson was not yet part of the adventure, and the letter M stood for method.

A year later, the first versions of the UML, namely versions 0.9 and 0.91, were published, which incorporated the work of Y. Jacobson. This time, the M stood for modeling. Indeed, these three fabulous evangelists, having not agreed upon one standard method, had instead focused on the notation.

UML 1.0 and 1.1 were proposed to the Object Management Group (OMG) in 1997. Then came version 1.2 in 1998, 1.3 (a very significant revision) in 1999, 1.4 in 2001 and, finally, 1.5 in 2002. This sequence of different versions is usually called UML1.X. This was followed by UML 2.X, whose first stable version (2.0), appeared in 2003. This is a major revision now involving 13 diagrams instead of nine previously. The metamodel was also considerably modified (which is of relevance to tool designers). The notion of the profile was formalized, which has allowed, for example, the emergence of variants, such as SysML and MARTE, which we will detail in this chapter.

Let us note that the transition from 1.X to 2.X, which was supposed to facilitate the use and efficiency of the language, has given mixed results. The industry and the toolmakers had put a significant amount of time into fully supporting UML 1.X and the required adaptation has delayed the operational use of UML 2.X, which has only recently begun to be used effectively in industry.

We will introduce the main UML characteristics (in its current version in 2012, the 2.4.1 version). The 16 UML diagrams are divided into two classes: static and dynamic diagrams.

Among these 13 diagrams, the four main diagrams are considered to be classes, sequence, use cases and state machines. They are used in the parts dedicated to SySML and to MARTE but also, systematically, by all the UML users.

UML is a notation. To use it well, we also need a method. Thus, each company has created its own method usually relying on the unified method (UM) or the rational unified process (RUP) (the two are pretty close). These methods describe when and how to use this or that diagram, how to organize the model as well as the documents and the codes that are generated while still respecting the specification/design processes that are enforced throughout the enterprise such as traceability, configuration management and quality (rules for a correct usage, coding rules, etc.).

1.3.1. The UML static diagrams

These diagrams describe the static aspects of a system (relative to their organization). In this category, we may find the following diagrams: classes, composites, components, deployment, object and package.

Class diagrams. They allow us to model the domain (for the sake of simplification, the data and/or the concepts manipulated by the application), and then the application itself. We will thus have the classes of the domain, then the application classes (analysis and design). An average model generally brings about approximately 100.

Composite diagrams. They allow us to decompose a class (in general an application class) into smaller parts. This decomposition enables us to show, for example, which part implements which operation, or how the different parts communicate with each other.

Let us note that there is a second type of composite diagram, which allows us to model patterns. Once these patterns are modeled, they can be used in class diagrams.

Components diagrams. They allow us to describe a system via its components and the interactions between components through their interfaces. A component can also be decomposed into subcomponents (just like the classes decompose into smaller parts) by means of a composite diagram.

The difference between a class and a component is the subject of a wide debate. However, our viewpoint can be summed up as follows:

– A class is the basic building block of a software.

– A component is also a building block but of a different level of abstraction; it generally groups together a set of classes, but can also group together other artifacts such as configuration files.

– Classes are interlinked via different relations (heritage, association and composition) and they propose various interfaces.

– Components are interlinked via interfaces.

– Classes can be decomposed into smaller parts.

– Components can only be decomposed into other components (i.e. components having a smaller granularity).

Deployment diagrams. They allow us to model the physical architecture (architectural components) of the application: machines, processes, communication modes, etc. In general, a process is made up of components (which are composed of classes and other artifacts) and distributed to one up to n machines.

Object diagrams. They instantiate a class diagram. A class diagram is a generic