This chapter describes a concise case study of a Highway Toll Control System in which there are several entry and exit toll booths. Each toll booth is controlled by a real-time embedded subsystem that communicates with a Highway Toll Service subsystem, which receives entry and exit transactions from the toll booths and charges customer accounts. At each toll booth there are multiple sensors and actuators, requiring state dependent entry and exit control. Because entry and exit toll booths are similarly configured and behave in a similar way, this shorter case study concentrates on the design of the entry toll booth. There is less emphasis on the structural modeling in this case study, which has been covered in detail in other case studies.

The problem description is given in Section 23.1. Section 23.2 describes the use case model, and Section 23.3 describes the software system context modeling. Section 23.4 describes the object and class structuring. Section 23.5 describes the state machine model, and Section 23.6 describes the dynamic interaction modeling. Section 23.7 describes the design modeling, which consists of the distributed software design and distributed software deployment, followed by the design of the concurrent task architecture and detailed software design.

PROBLEM DESCRIPTION

A highway toll road has several entry and exit points, at each of which, there is a toll plaza with one or more tollbooths. To use the system, a customer purchases a RFID (radio frequency ID) transponder, which holds the encoded customer account number, from the Highway Toll Service and mounts the transponder on the windshield of the vehicle. The Highway Toll Service maintains customer accounts in a database including owner and vehicle information, and account balance. Customers purchasing a transponder must pay in advance for toll fees by credit card. Accounts are reduced by the toll charge incurred at the end of each trip. The toll charge to be paid depends on the length of the trip and category of the vehicle.

All tollbooths consist of a vehicle arrival sensor (placed fifty feet in front of the tollbooth), a vehicle departure sensor, a traffic light to indicate whether the vehicle has been authorized to pass through the tollbooth, a transponder detector, and a camera.

After structuring the system into tasks (in Chapter 13), this chapter describes the detailed software design. In this step, the internals of composite tasks that contain nested objects are designed, detailed synchronization issues of tasks accessing passive classes are addressed, connector classes are designed that encapsulate the details of inter-task communication, and each task's internal event sequencing logic is defined. Several examples are given in Pseudocode of the detailed design of task synchronization mechanisms, connector classes for inter-task communication, and task event sequencing logic.

The detailed software design is depicted on a detailed concurrent communication diagram, which adds more detail to the concurrent communication diagram developed during task structuring. It depicts the internal design of clustered tasks and the design of connector objects.

Section 14.1 describes the design of composite tasks, including the internal design of temporal and control clustering tasks. Section 14.2 describes the synchronization of access to classes using different synchronization mechanisms, including the mutual exclusion algorithm and the multiple readers and writers algorithm. Section 14.3 describes the synchronization of access to passive objects using the monitor concept. Section 14.4 describes the design of connectors for inter-task communication, in particular for synchronous and asynchronous message communication. Section 14.5 describes the detailed software design of tasks using task behavior specifications and event sequencing logic. Section 14.6 provides detailed software design examples of task communication and synchronization in real-time robot and vision systems. Finally, Section 14.7 briefly describes implementing concurrent tasks in Java using threads.

DESIGN OF COMPOSITE TASKS

A composite task is a task that encapsulates one or more nested objects. This section describes the detailed design of composite tasks, which includes tasks that were structured using the task clustering criteria. Such tasks are designed as composite active classes that contain nested passive classes. In a real-time design, typical nested classes are entity classes, input/output classes, and state machine classes.

After considering the relationship between tasks and classes, this section describes situations where it is useful to divide the responsibility between tasks and classes. Next, the design of two composite tasks is described in detail: a temporal clustering task and a control clustering task.

For improved readability, certain conventions are used in this book. These are the naming conventions used in this book and the conventions for message sequence numbering on interaction diagrams.

NAMING CONVENTIONS USED IN THIS BOOK

For improved readability, the conventions used for depicting names of classes, objects, and so on in the figures are sometimes different from the conventions used for the same names in the text. In the figures, examples are shown in Times New Roman font. In the body of the text, however, examples are shown in a different font to distinguish them from the regular Cambria Math font. Some specific additional conventions used in the book vary depending on the phase of the project. For example, the conventions for capitalization are different in the analysis model (which is less formal) than in the design model (which is more formal).

REQUIREMENTS MODELING

In both figures and text, use cases are shown with initial uppercase and spaces in multiword names – for example, Cook Food.

ANALYSIS MODELING

The naming conventions for the analysis model are as follows.

CLASSES

Classes are shown with an uppercase initial letter. In the figures, there are no spaces in multiword names – for example, HeatingElement. In the text, however, spacing is introduced to improve the readability – for example, Heating Element.

Attributes are shown with a lowercase initial letter – for example, weight. For multiword attributes, there are no spaces between the words in figures, but spaces are introduced in the text. The first word of the multiword name has an initial lowercase letter; subsequent words have an initial uppercase letter – for example, sensorValue in figures and sensor Value in text.

The type of the attribute has an initial uppercase letter – for example, Boolean, Integer, or Real.

OBJECTS

An object may be depicted in various ways, in particular as:

1. • An individual named object. In this case, the first letter of the first word is lowercase, and subsequent words have an uppercase first letter. In figures, the objects appear as, for example, aWarningAlarm and anotherWarningAlarm. In the text, these objects appear as a Warning Alarm and another Warning Alarm.

State machines (also referred to as finite state machines) are used for modeling control and sequencing in a system. This is particularly important for real-time embedded systems, which are usually highly state dependent. In particular, the actions of a state dependent system depend not only on the inputs to the system but also on what happened previously in the system, which is captured as a state. A state machine can be used to depict the states of a system, subsystem, component, or object. Notations used to define state machines are the state transition diagram, state machine diagram, statechart, and state transition table. In highly state dependent systems, these notations help substantially to understand the complexity of these systems.

A state machine specification is typically more precise and understandable than a textual or use case description. State machines can enhance or even replace use case descriptions of requirements by providing more precise specifications. In particular, state machines are essential for specifying systems with significant state dependent behavior.

In the UML notation, a state transition diagram is referred to as a state machine diagram. The UML state machine diagram notation is based on Harel's statechart notation (Harel and Gery 1996; Harel and Politi 1998). In this book the terms state machine and state machine diagram are used interchangeably. This chapter refers to a traditional state transition diagram, which is not hierarchical, as a flat state machine and uses the term hierarchical state machine to refer to the concept of hierarchical state decomposition, a concept introduced by Harel. A brief overview of the state machine notation is given in Chapter 2 (Section 2.6).

This chapter starts by considering the characteristics of flat state machines and then describes hierarchical state machines. To show the benefits of hierarchical state machines, this chapter starts with the simplest form of flat state machine and gradually shows how it can be improved upon to achieve the full modeling power of hierarchical state machines. The process of developing state machines from use cases is then described. Several examples are given throughout the chapter from two case studies, the Microwave Oven and Train Control state machines.

Section 7.1 describes events and states in state machines. Section 7.2 introduces the Microwave Oven Control state machine example.

The notation used for the COMET/RTE method is the Unified Modeling Language (UML), supplemented with the Systems Modeling Language (SysML) and Modeling and Analysis of Real-Time Embedded Systems (MARTE). This chapter provides a brief overview of these three related visual modeling notations.

The Object Management Group (OMG) maintains UML and SysML as standards. The UML notation has evolved since it was first adopted as a standard in 1997. A major revision to the standard was the introduction of UML 2.0 in 2003. Since then there have been further minor changes, and the latest version of the standard is UML 2.4. The versions of the standard before UML 2 are referred to as UML 1.x, and the current version is generally referred to as UML 2. SysML is based on UML 2, using some parts of UML 2 and extending it in other areas for systems modeling. MARTE is a more recent UML profile for real-time embedded systems. Each of these notations is of a significant size, and it is therefore beneficial for the real-time system modeler to pick and choose carefully among the multitude of diagrams and stereotypes provided by these notations.

The UML notation has grown substantially over the years and supports many diagrams. SysML and MARTE extend the modeling notations further. The approach taken in this book is to use only those parts of the UML and SysML notation that provide a distinct benefit to the design of real-time embedded systems, and to use the parts of MARTE that can be most usefully blended with UML and SysML for the design of these systems. This chapter describes the main features of the UML, SysML, and MARTE notations that are particularly suited for real-time design using the COMET/RTE method. The purpose of this chapter is not to be a full exposition of UML, SysML, and MARTE, because several detailed books exist on these topics, but rather to provide a brief overview of each. The main features of each of the diagrams used in this book are briefly described, but lesser-used features are omitted.

MODEL-DRIVEN ARCHITECTURE WITH SYSML AND UML

In the OMG's view, “modeling is the designing of software applications before coding” (OMG 2015). The OMG promotes model-driven architecture as the approach in which UML models of the software architecture are developed prior to implementation.

In earlier chapters, the term component has been used informally. This chapter describes the design of distributed component-based software architectures in which the architecture for a real-time embedded system is designed in terms of components that can be deployed to execute on different nodes in a distributed environment. It describes the component structuring criteria for designing components that can be deployed to execute in a distributed configuration. The design of component interfaces is described, with component ports that have provided and required interfaces and connectors that join compatible ports.

Components are initially designed using the subsystem structuring criteria described in Chapter 10. Additional component configuration criteria are used to ensure that components are configurable, in other words that they can be effectively deployed to distributed physical nodes in a distributed environment. Architectural structure and communication patterns described previously in Chapter 11 are also used in the design of component-based software architectures.

Components can be effectively modeled in UML with structured classes and depicted on composite structure diagrams. Structured classes have ports with provided and required interfaces. Structured classes can be interconnected through their ports via connectors that join the ports of communicating classes. Chapter 2, Section 2.10 and Chapter 10, Section 10.2.1 introduce the UML notation for composite structure diagrams. This chapter describes in detail how component-based software architectures are designed.

Section 12.1 describes concepts for distributed component-based software architectures. Section 12.2 describes the steps in designing distributed component-based software architectures. Section 12.3 describes how component interfaces are designed with provided and required interfaces. Section 12.4 describes the concepts and design of composite subsystems and components. Section 12.5 describes some examples of distributed component-based software architectures. Section 12.6 describes component structuring criteria for structuring a software architecture into configurable distributed components. Section 12.7 describes the design of sequential and concurrent service subsystems. Section 12.8 describes issues in the distribution of data in distributed systems. Section 12.9 describes component deployment to a distributed configuration. Finally, Section 12.10 describes the design of software connectors.

CONCEPTS FOR COMPONENT-BASED SOFTWARE ARCHITECTURES

A component integrates the concepts of encapsulation and concurrency. An important goal of a component-based software architecture is to provide a concurrent message-based design that is highly configurable.

Software quality attributes (Bass et al. 2013) refer to nonfunctional requirements of software, which can have a profound effect on the quality of a real-time embedded system. During requirements specification, software quality requirements are specified as nonfunctional requirements. Many software quality attributes can be addressed and evaluated at the time the software architecture is developed.

Some quality attributes are actually system quality attributes because both hardware and software considerations are needed to achieve high quality. These system quality attributes include scalability, performance, availability, safety, and security. Other quality attributes are purely software in nature because they rely entirely on the quality of the software. These software quality attributes include maintainability, modifiability, testability, traceability, and reusability. This chapter provides an overview of system and software quality attributes, and discusses how they are supported by the COMET/RTE software design method.

SCALABILITY

Scalability is the extent to which the system is capable of growing after its initial deployment. There are system and software factors to consider in scalability. From a system perspective, there are issues of adding further hardware to increase the capacity of the system. In a centralized system, the scope for scalability is limited, such as adding more memory, more disk capacity, or an additional CPU. A distributed system offers much more scope for scalability by adding more nodes to the configuration.

From a software perspective, the system needs to be designed in such a way that it is capable of growth. A distributed component-based software architecture is much more capable of scaling upward than a centralized design. Components are designed such that multiple instances of each component can be deployed to different nodes in a distributed configuration. A light rail control system that supports multiple trains and multiple stations can have a component-based software design, such that there is one instance of a train component for each train and one instance of a station component for each station. Such a software architecture can be deployed to execute in a small town, in a large city, or in a wide geographical region. A service-oriented architecture can be scaled up by adding more services or additional instances of existing services. New clients can be added to the system as needed. Clients can discover new services and take advantage of their offerings.

After structural modeling and defining the use case and state machine models, the next step is to determine the software classes and objects in the real-time embedded system. Using a model-based approach, the emphasis is on software objects that model real-world objects in the problem domain. Furthermore, since concurrency is so fundamental to real-time software design, an important issue that is addressed at this stage is whether the objects are concurrent or not. Another key issue described in this chapter is the behavior pattern of each category of object.

This chapter provides guidelines, in particular structuring criteria, on how to determine the classes and objects in the system. As with system structural modeling (see Chapter 5), software classes and objects are categorized by using stereotypes. Section 8.1 gives an overview of object and class structuring while Section 8.2 describes object and class structuring categories. Section 8.3 describes object behavior and patterns. Section 8.4 describes the different kinds of boundary classes and objects. Section 8.5 describes entity classes and objects, which were first introduced in Chapter 5. Section 8.6 describes the different kinds of control classes and objects. Section 8.7 describes application logic classes and objects.

OBJECT AND CLASS STRUCTURING CRITERIA

In software applications, a class is categorized by the role it plays in the application. Object and class structuring criteria are provided to assist the designer in structuring a system into its constituent classes and objects. The approach used for identifying objects is to look for real-world objects in the problem domain and then design corresponding software objects that model the real world. After the objects have been identified, the interactions among objects are depicted in the dynamic model on sequence diagrams or communication diagrams, as described in Chapter 9.

Classes are categorized in order to group together classes with similar characteristics. Figure 8.1 shows the categorization of application classes using inheritance. As described in Chapter 5, stereotypes (See Sections 5.2 and 5.6) are used to distinguish among the various kinds of classes. Application classes are categorized according to their role in the application, in particular «boundary» class, «entity» class, «control» class, or «application logic» class. Because an object is an instance of a class, an object has the same stereotype as the class from which it is instantiated.

OVERVIEW

The material in this book may be taught in different ways depending on the time available and the knowledge level of the students. This appendix describes possible academic and industrial courses that could be based on this book.

A prerequisite of these courses is an introductory course on software engineering covering the software life cycle, and the main activities in each phase of the life cycle. This prerequisite course would cover the material described in introductory books on Software Engineering such as Pressman (2009) or Sommerville (2010).

In each of these courses, there are three components: description of the method, presentation of at least one case study using the method, and hands-on design exercise for students to apply the method to a real world problem.

SUGGESTED ACADEMIC COURSES

The following academic courses could be could be taught in graduate and advanced undergraduate courses in Computer Science, Software Engineering, Systems Engineering, and Computer Engineering programs, and are based on the material covered in this textbook.

1. A senior undergraduate or graduate level course on real-time software modeling and design.

2. A Design Lab course is held as a follow-up course or as an alternative to the real-time software modeling and design course (course 1) in which the students work in teams to develop a solution to a substantial real-time software problem. In this case, students could also implement all or part of the system.

D.3 SUGGESTED INDUSTRIAL COURSES

The following industrial courses could be based on the material covered in this book:

1. A course on real-time software modeling and design. Concepts are presented briefly from Part I, and then the course would concentrate on Part II and, depending on the length of the course, performance analysis from Part III, together with a case study from Part IV. The design lab would concentrate on working on a real-time software problem. This course could be run at any length from two to five days, depending on the level of detail covered.

2. A practical hands-on course in which each stage of the real-time software design method is followed by a hands-on design lab. The design lab could be on a problem of the company's choice, assuming an in-house course.

This chapter describes a case study for an embedded Light Rail Control System. This design is for a safety-critical system, in which the automated control of driverless trains must be done safely and in a timely manner. As is typical of embedded systems, the system interfaces with the external environment by means of several sensors and actuators. Control of each train is state dependent, which necessitates the design of a state machine to provide control of the train. As this system is an embedded system, the design approach benefits from starting with a systems engineering perspective of the total hardware/software system before the real-time software modeling and design. The Light Rail Embedded System refers to the total hardware/software system, while Light Rail Control System refers to the software system.

The problem is described in Section 21.1. Section 21.2 describes the structural modeling of the system, consisting of the structural model of the problem domain, followed by the system and software system context models. Section 21.3 describes the use case model from a software engineering perspective, describing both the functional and nonfunctional requirements of the safety-critical system. Section 21.4 describes the dynamic state machine modeling, which is particularly important to model the state dependent intricacies of this embedded system. Section 21.5 describes how the system structuring criteria are applied to this system, followed by Section 21.6, which describes how the object and class structuring criteria are applied to each subsystem. Section 21.7 describes how dynamic interaction modeling is used to develop sequence diagrams from the use cases. Section 21.8 provides an overview of the design model for the software system. Section 21.9 describes developing integrated communication diagrams, which leads to the design of the distributed software architecture in Section 21.10, and the component-based software architecture in Section 21.11. Section 21.12 describes system configuration and deployment.

PROBLEM DESCRIPTION

The Light Rail Control System consists of several trains that travel between stations along a track in both directions with a semi-circular loop at each end. Trains have to stop at each station. If a proximity sensor detects a hazard ahead, the train decelerates before stopping.

This appendix provides pseudocode templates of the event sequencing logic for the different kinds of concurrent tasks described in Chapter 13 of this textbook. These templates include event driven input tasks; periodic input and algorithm tasks; and demand driven general purpose, coordinator, output, user interaction, and state dependent control tasks.

PSEUDOCODE FOR EVENT DRIVEN INPUT TASK

An event driven input task is needed when there is an event driven (also referred to as interrupt-driven) input device to which the system has to interface (Section 13.3.2). The event driven I/O task is activated by an external event (such as an interrupt) from the device, reads the input data, does any necessary processing of the data, including sending a message to a consumer or updating a passive entity object, and then waits for the next external event.

PSEUDOCODE FOR PERIODIC INPUT TASK

A periodic input task interfaces with a passive input device, where the device is polled on a regular basis (Section 13.3.3). The periodic input task is activated by a timer event, reads the sampled input data, does any necessary processing of the data, and then waits for the next timer event. The task's period is the time between successive activations.

In software design, designers frequently encounter a problem that they have solved before on a previous project. Often the context of the problem is different; it might be a different application, a different platform, or a different programming language. Because of the different context, a designer usually ends up redesigning and reimplementing the solution, thereby falling into the trap of “reinventing the wheel.” The field of software patterns, including architectural and design patterns, is helping developers avoid unnecessary redesign and reimplementation.

In software development, the field of design patterns was popularized by Gamma, Helm, Johnson, and Vlissides in their book Design Patterns (1995), in which they described twenty-three design patterns. Later, Buschmann et al. (1996) described patterns that span different levels of abstraction, from high-level architectural patterns through design patterns to low-level idioms.

This chapter describes several software architectural patterns that can be used in the development of real-time embedded systems. Section 11.1 provides an overview of the different kinds of software patterns. Sections 11.2 through 11.7 describe the different software architectural patterns, with Sections 11.2 through 11.4 focusing on patterns that address the structure of the software architecture and Sections 11.5 through 11.7 discussing patterns that address the message communication among distributed components of the software architecture. Section 11.8 describes how to document software architectural patterns using a standard template. Section 11.9 describes how to apply software architectural patterns to build a new software architecture.

SOFTWARE DESIGN PATTERNS

A design pattern describes a recurring design problem to be solved, a solution to the problem, and the context in which that solution works (Buschmann et al. 1996, Gamma et al. 1995). The description is in terms of communicating objects and classes customized to solve a general design problem in a particular context. A design pattern is a larger-grained form of reuse than a class. A design pattern involves more than one class along with the interconnection among the different classes.

After the original success of the design pattern concept, other kinds of patterns were developed. The main kinds of reusable patterns are given below:

1. • Design patterns. In a widely cited book (Gamma et al. 1995), design patterns were described by four software designers – Erich Gamma, Richard Helm, Ralph Johnson, […]

Model-based systems engineering (Buede 2009, Sage 2000) and model-based software engineering (Booch 2007, Gomaa 2011, Blaha 2005) are recognized as important engineering disciplines in which the system under development is modeled and analyzed prior to implementation. In particular, embedded systems, which are software intensive systems consisting of both hardware and software components, benefit considerably from a combined approach that uses both system and software modeling. As described in Chapter 2, the modeling languages used in this book are SysML for systems modeling and UML for software modeling.

This chapter provides an overview of the real-time software design method for embedded systems called COMET/RTE (Concurrent Object Modeling and Architectural Design Method for Real-Time Embedded systems), which uses the SysML, UML, and MARTE notations. Section 4.1 starts with an overview of the COMET/RTE systems and software life cycle. Section 4.2 describes each of the main phases of COMET/RTE. Section 4.3 compares the COMET/RTE life cycle with the Unified Software Development Process, the spiral model, and agile software development. Section 4.4 provides a survey of design methods for real-time embedded systems. Finally, Section 4.5 gives an introduction to the multiple view modeling and design of real-time embedded software architectures described in this textbook.

COMET/RTE SYSTEM AND SOFTWARE LIFE CYCLE MODEL

This section presents an overview of the COMET/RTE method from a system and software life cycle perspective. COMET/RTE starts with a systems structural analysis and modeling of the total system (hardware, software, people), which leads to defining the boundary between the system and the external environment and to designing the hardware/software interface. This is followed by an iterative software development process, which is both use case–based and object-oriented. The COMET/RTE life cycle model, which is depicted in Figure 4.1, is highly iterative and encompasses both system and software modeling. Iteration is between successive phases, as well as iterating back through multiple phases using an incremental development approach.

Studies have shown that errors in requirements engineering and software architectural design are usually the last to be discovered and the most costly to fix (Boehm 2006), and this is particularly the case for real-time embedded systems. COMET/RTE focuses on requirements and design within an iterative system and software life cycle, as described in this section.