Dynamic software architecture for embedded systems

Software dynamics firmly under control

Authors: Frank Slomka, Christian Hausner, Institute for Embedded Systems/Real-Time Systems, University of Ulm

Contribution – Embedded Software Engineering Congress 2015

UML and its extensions SysML and MARTE are well-suited for describing the static architecture of software. However, the dynamics of the system pose a challenge within a holistic development process for embedded software. In particular, the dynamic interaction between the hardware, the memory model, the operating system, and the application software can only be inadequately structured and described. Based on a new development process, a UML-compatible description method is presented that takes into account the specific characteristics of the dynamic behavior of embedded software. Special attention is paid to the dynamics of the hardware/software interface.

Introduction

Embedded systems are becoming increasingly important for a wide variety of applications and tasks, and are becoming more interconnected. This also means that the design of embedded systems is characterized by rising demands and new challenges. These include:

• the increasing complexity of the systems to be designed is due to the more complex and diverse tasks
• Increased networking among themselves, with the environment and information technology systems
• Correctness, robustness, availability and security in increasingly autonomous use in "uncontrolled" environments

One solution to overcome such challenges is systems modeling. Due to the wide variety of application areas and their different characteristics, the modeling must take into account the special features, methods and techniques of these application areas, provide specialized views of them and be able to combine/integrate them (see also [4]).

Another established methodology to address the challenges, especially the complexity in the design of such systems, is platform-based design (see [1] and [8]).

These design methods are complemented by the component-based approach. A component is understood as a modular part of a (complex) system that can be replaced by an equivalent component within its environment. A component implements a self-contained sub-function of a system.

The design methodology introduced below is consistently based on platform development and the modeling of embedded systems and their environments. This aims to address the aforementioned challenges and enable the reuse of platform and application models across different products and product lines. We introduced the design methodology in [9], and the platform model was supplemented and detailed in [2]. Modeling platforms of such complex systems is a particularly challenging task, which our design methodology aims to improve. The concept of hierarchical modeling is primarily employed in this process.

Modeling the application and its environment is another essential aspect of our design methodology. In addition to functional requirements, there are numerous non-functional requirements that the platform must fulfill. In the chapter "Requirements Definition," we will present a method for graphically modeling such requirements (generally constraints).

Related works

UML [7] and its extensions SysML [5] and MARTE [6] are well-suited for describing the static architecture of software. UML is further enhanced for modeling embedded systems by the extensions MARTE and SysML. SysML enables the modeling of all types of systems, but is less concrete in its definition of the semantics of SysML elements and diagrams. SysML does not explicitly support the platform-based approach; for this purpose, it can be combined with MARTE.

MARTE was developed for the platform-based approach and, like our methodology, supports the hierarchical modeling of platforms. MARTE also utilizes the concept of resources and services (see chapter "Operating System Address Spaces and Services").

In particular, the dynamic interplay between the hardware, the memory model, the operating system and the application software can only be inadequately structured and described using UML and its extensions SysML and MARTE.

The epicyclic design process

Our design methodology extends object-oriented design methods, as described in [3], to a technology-independent, component-based approach. It is iterative and includes a main process comprised of subprocesses. We visualize our approach using circles to represent the iterations. All subprocesses are represented as epicycles on the main process and are therefore referred to as epicyclic design processes. Figure 1 (see PDFThe -file) provides an overview of the epicyclic design process.

One iteration of the main process produces one version (product) of an embedded system. An iteration consists of five subprocesses, each comprising design steps. Subprocesses generate work products (intermediate products) and are interdependent. The following five subprocesses are defined:

1. System requirements analysis
2. functional system design
3. Platform design
4. Component implementation
5. System integration (implementation)

The main process can be iterated multiple times. The embedded system to be designed is developed in several iterations (variants, versions, prototypes). One iteration of the main process is comparable to a single run of the classic V-model.

Subprocesses can also be iterated multiple times. They produce work products for other subprocesses, as well as internal work products if needed, and require inputs from other subprocesses or from the environment.

The goal of the epicyclic design process is twofold: firstly, to enable the automated, application-centric creation of systems, and secondly, to facilitate the systematic and repeatable development of systems. The specific platform or system emerges from customer requirements or application requirements and available platform model elements. This allows for the development of a system optimally tailored to the application while also efficiently pursuing the platform approach.

System requirements analysis and functional system design

System requirements analysis involves classic requirements engineering with textual requirements supplemented by images/diagrams. In this phase, customer requirements are gathered, evaluated, and agreed upon. Since the requirements captured here and their impact on the system to be designed are needed in all subsequent phases, the non-functional requirements in particular are modeled (formalized, as described in the "Requirements Definition" chapter) at this stage. The result of this phase is a requirements specification.

Functional system design involves modeling a functional system (also called an application) based on its functional requirements. Non-functional requirements are annotated in the model to account for their impact on the application and, later, the platform.

The application model

The metamodel for the application and the surrounding system consists of modules, tasks, ports, and links. Ports serve as connection points between modules and tasks and are connected via links. We distinguish between structural ports and transfer-oriented ports. In the following, only transfer-oriented ports will be considered.

We distinguish between technology-independent modeling and, in the next refinement, technology-dependent modeling. The transition between these two phases is referred to as technology coupling (see [9]). Application modules are elements that can contain other elements such as modules and tasks. They are used to enable a hierarchical design. A module is a structural element that serves to encapsulate functions (principle of secrecy). Modules serve to group tasks or modules with high functional coupling.

Modules are not elements of physical encapsulation, and they do not necessarily correspond to elements of the platform. Modules describe either an environment model or a technical system (the application).

The environmental model is a model of a relevant segment of the real world that is directly related to the technical system being designed. The technical system model interacts with the environmental model to achieve the required actions/reactions, i.e., to fulfill the functional requirements.

Together with its platform, a technical system model realizes an embedded system.

Following the concept of the hierarchical inclusion of modules, the entire application architecture is also a module that contains both the technical system and necessary environment models (see Figure 2, PDF).

Application tasks describe and model the behavior of applications. Tasks encapsulate this behavior and can communicate with each other via ports. A task is a design element that provides basic functionality (behavior) with input and output variables. Tasks can be, for example, models, equations, or functions. Every task has at least one port.

In addition to tasks with basic functionality, there are specialized tasks that interact with other technologies. These are called transformation tasks and enable the exchange between different technologies. Other specialized tasks interact with the platform of a technical system. Here, we distinguish between time tasks, which provide an interface to the platform's time information (time events), and memory tasks, which provide an interface to the platform's memory resources.

Ports serve as communication endpoints for tasks and modules. Ports are interconnected via links. Both ports and links are typed by their interface descriptions. Only compatible ports can be connected via appropriate links. Ports model the inputs and outputs of tasks and modules and describe their interfaces. A distinction is made between input and output ports.

Modules can only have special ports called proxy ports. These serve as an external interface for a module, connecting the module's environment to its internal modules or tasks. These virtual ports ensure the encapsulation and confidentiality of the module and its contained tasks and modules.

A link connects two compatible ports. An output port provides entities (for example, information) depending on its interface description, and an input port receives these entities. The connecting link inherits its interface description from the ports. The type of interface can be visualized using symbols on the link.

In the first design step, the functional requirements are translated into a technology-independent application. The next step refines this application (technical system) by deciding on the technologies to implement it. This step is called technology binding. Here, within the framework of functional system design, the first platform decisions are made, because every decision about the technology necessitates decisions and requirements for the platform. For example, the decision between digital or analog technology is made here. As described above, the connection between different technologies is modeled by so-called transformation tasks.

A module can contain different technologies: a mathematical model, digital technology (computer system or electronic system), an analog electronic system (analog technology), or a physical system (e.g., mechanics, optics, acoustics; often used in environmental models).

Requirements definition

In addition to functional requirements, we distinguish between non-functional (or extra-functional) requirements. Non-functional requirements describe demands regarding, for example, the performance, responsiveness, or scalability of the system. Since they often describe limitations under which a system is to perform its tasks, they will be referred to as constraints in the following.

In system requirements analysis, non-functional requirements are formalized and modeled as constraints. These include both static and dynamic constraints. Currently, the following types of constraints are distinguished:

• Time
• Area or costs
• Power and energy
• Safety and reliability, availability

Due to the extensibility of the metamodel, additional types of constraints can easily be added.

Constraints have a scope, a set of model elements on which they act. They are annotated in the application model by specifying them between anchor points (probes). These anchor points can be bound to any model element of the application. To visualize constraints, their scope, and their effects, symbols for constraints are defined (see Figure 3)., PDFThe scope of a constraint is highlighted in color.

The actual non-functional requirement is modeled by an expression that must be satisfied for the scope of the constraint. Different types of satisfaction exist; for example, a constraint can be satisfied if it is satisfied on all elements of the scope in total, or if it is satisfied for each element of the scope individually.

For example, a time constraint can specify the maximum response time of a signal:

This constraint is annotated to the application's communication links containing this signal (scope) using anchor points. This visualizes the required temporal restriction of the signal in the functional system design. It is subsequently annotated to the system's platform, thus limiting the usable platform elements. These formal annotations ensure compliance with non-functional requirements in early design phases.

Platform design

Based on the functional system design and the non-functional requirements (constraints), a suitable platform can be derived. The modeling of the platform for digital systems is presented below.

Layer model and role separation

Key concepts in system design are encapsulation and layering. A software platform can be divided into different layers. Our platform model enables the formation of layers via a hierarchical structure. Thus, modeling a platform layer corresponds to modeling an application that is bound to the underlying platform. Our platform concept is based on layering, where each layer communicates only with its directly adjacent higher or lower layer.

This concept also simplifies the separation of roles and responsibilities. In our generic layered model, the lowest layer is represented by the hardware platform (layer 0). This layer is modeled using the platform component model (see chapter "Hardware Architecture"). Higher-level platform layers provide services that are used by the layer above them (application). These layers are described using the platform domain model (see chapter "Address Spaces and Services of the Operating System"). Figure 4 (see PDF) shows an overview of the layer model.

This reduces dependencies between different roles in the design process. For example, a hardware developer will describe the hardware platform using the platform component model and coordinate with the platform developer. Direct dependencies between the hardware developer and the application developer are minimized. The latter generally only needs to coordinate with the platform developer, as they only require the top layer of the platform to model their application.

Hardware architecture

The platform component model (introduced in [2]) consists of modules and components and, similar to the application model, supports hierarchical design by having modules made up of modules or components.

Modules are, for example, physical units such as devices, expansion cards, or chips/SoCs (Systems on Chip). Components are the atomic hardware elements; they contain bus control interfaces that serve as interfaces (see Figure 5)., PDFSimilar to the ports in the application model, only compatible bus control interfaces can be connected here as well.

Other elements of the platform component model are time elements, namely timers and clocks. They can be connected to all other elements and are connected to other elements via a timing interface (see Figure 5)., PDF).

The goal of this modeling is to describe the hardware architecture of platforms structurally, or rather, in terms of its building blocks. The hardware architecture can be substituted for the platform domain model described in the following chapter with regard to resources and services. These services subsequently enable the application to be bound to the platform.

Operating system address spaces and services

This chapter describes the platform-domain model. The idea behind this model is to introduce an abstraction that considers all aspects of a platform from the application's perspective. Here, we introduce the concept of domain resources and services for all platforms, regardless of whether they are provided by software or hardware. This aims to improve the interchangeability of the platform and the application. Furthermore, it seeks to be independent of specific industrial applications.

Detailed knowledge of the hardware platform is encapsulated by the platform domain model. The application only needs to know the relevant information from the platform domain model. The platform domain model logically structures platforms and overcomes the physical structure of the platform component model (devices, chips, etc.). This enables a higher degree of independence and interchangeability between the platform and the application.

Platform domains

A platform domain (hereinafter referred to as a domain) is a structural element of the platform domain model. It represents a container that encapsulates logical units such as resources and services. The domain model represents the logical view of the platform. Domains can contain subdomains, thus enabling the hierarchical modeling of platforms.

Domains have an interface in the form of services provided by the resources they contain. A domain binds elements of the application model, such as tasks, if it contains a sequential execution resource. If it does not have such a resource, the domain serves as a container for further subdomains. Domains are logical units that must be implemented in hardware or software for the realization of the embedded system.

The lowest platform layer contains domains, which represent the logical view of the hardware architecture modeled by components. Domains can be implemented here through modules or groups of components (even from different modules). This allows a domain to possess resources that are, for example, contained in different devices or chips (see also the chapter "Design Study").

At higher levels of the platform layer model, domains are implemented by software, for example, by operating systems and their time and memory partitions such as processes and threads. A possible model of an operating system in the domain model looks like this:

1. The operating system itself is described by a domain.
2. Each process is described by a sub-domain.
3. Each thread is described by a sub-domain of the corresponding process sub-domains.

If the application does not require concurrency or memory separation, it generally does not use an operating system. Other services (e.g., drivers for platform hardware) are still typically required by the application and are described via a domain.

Resources and services

Resources are logical elements that provide services to application elements or higher-layer resources. Resources, in turn, require lower-layer services to perform their tasks (see Table 1)., PDF).

The services offered by resources form the resource's interface. Services can also be interpreted as a resource's public methods. Services are the only way to access resources from a higher layer. We distinguish between offered and required services, or services that serve to configure a resource. Outbound services are read services or event handling routines. The classification into input and output services is always made from the perspective of the resource that owns the service.

The binding of platform elements of adjacent layers is achieved by connecting required services of the layer. X with compatible services offered during the shift X – 1. At the lowest platform layer, platform components implement resources that provide services. This implementation is referred to as a binding at this level.

A domain typically does not model all possible resources and services, but only those required by higher layers. We refer to these as relevant resources and services.

Resources and services are identified by their resource type, as shown in Table 1 (see Table 1, PDF), classified. We further distinguish between resource managers. They manage other resources and their services. A typical resource manager is an MMU (Memory Management Unit), which manages other storage resources and acts as a proxy for them and their services.

The core services offered by platforms are computing time or capacity, storage, and communication. If a domain is not merely used as a container for subdomains, it represents at least one computing time partition ("time slice") modeled by a sequential execution resource. This means that all tasks bound to this domain by the application are tied to exactly one execution resource. This resource is bound to a processor resource. Consequently, all tasks within a domain are processed sequentially, not concurrently. Therefore, multiple subdomains of a domain can be supplied with computing time by a single managed processor resource (scheduler).

In contrast, domains can also act as storage partitions, thus separating the entire available storage area using address spaces. In this case, all storage accesses are bound to virtual storage resources (managed resources).

Application and platform integration

This design step combines the application and the platform. Application elements, such as tasks, are bound to the services offered by the platform. Once this step is complete, the modeled system can be analyzed and refined if necessary (by iterating the upstream processes again).

This is followed by the implementation or generation of the modeled system or its components (sub-process component implementation) and the integration and testing of the components into the embedded system (sub-process system integration). Due to the shift of essential analysis and testing steps, such as modeling and analyzing compliance with non-functional requirements (constraints), to early design phases, this sub-process is significantly simplified.

For this design step, a special view for binding the application and platform is provided. It is used by system or application developers to bind application elements to platforms. Here, the application view and the domain view are merged, with the application view overlaid on the domain view. The graphical elements of the domain view are reused in a reduced form. For example, resources are no longer displayed, only the services offered, because the primary function of this view is to represent the platform interface to the application, not the platform structure. Further details on graphical binding will be covered in our future research (see also the "Summary" chapter).

Design study

This chapter describes the modeling of a sonar system for an autonomous underwater vehicle using our methodology. The primary task of the sonar system is the detection of objects in the water. The sonar system emits sound waves and receives the echoes generated by objects in the water. Such a system is a good example of the use of different technologies. It consists of electromechanical components for generating the sound waves, analog electronic components for controlling the sound generators and for receiving the echoes, and digital electronic components with hardware and software for signal processing and object detection.

The design study follows our methodology and is therefore divided into the following sections:

1. System requirements analysis
2. Functional system design
3. Platform design
4. Component implementation and system integration.

Here we focus on the first 3 design processes; component implementation and system integration are not considered further in this design study and are part of our further research (see chapter „Summary“).

System requirements analysis

The aim is to develop a sonar system capable of detecting underwater objects and calculating a vector indicating distance and location relative to the system. The system requirements analysis begins with the analysis and specification of the essential requirements, excerpts of which are shown in Figure 6 below (see...). PDF) are listed.

Functional system design

Based on the requirements (requirements specification), the functional system design begins. This involves identifying the main functional components and defining the technology requirements.

The first step involves defining the functional system context or deriving it from the requirements. A sonar system is designed that can detect underwater objects using sound waves. The sonar system is modeled as the application, and known interfaces are modeled as the module's ports.

The next steps do not need to be performed in strict chronological order. In the next step, the functions of the sonar system are extracted from the functional requirements and modeled as application modules within the sonar module. For example, each function described in a functional requirement can be a module.

The next step involves grouping functions into meaningful units. This creates modules that form functional groups. The sonar system is divided into the functional groups of signal generation, signal processing, and management. To convert generated signals into sound waves, another function is required. To process sound echoes from objects as signals, they must be received. For this purpose, the functional group "Transceiver" is created. This is where the first part of the technology integration takes place, as (electrical) signals must be converted into sound waves (and vice versa).

Technology commitment

In the next refinement stage, technology binding is performed. Elements of different technologies are connected through transformation tasks, and the connections (generally signals or signal flows) are refined depending on the chosen technology and the type of signals.

The system architect or application developer determines which parts of the application should be implemented using which technology. The signal generation, signal processing, and management modules are implemented as digital electronics. To convert digital signals into sound waves and to digitally process received sound echoes, a transformation from digital electronics to analog electronics and electromechanical components is necessary. Therefore, the transceiver or transducer module is implemented as analog electronics. Figure 7 (see PDF) shows the application model according to the technology commitment.

Time constraints

The functional system design is then refined by annotating constraints on the application element (e.g., signals) and can now serve as an input for the platform design.

To reliably capture 200 kHz signals, twice the sampling rate is necessary. In the sonar system, the analog-to-digital conversion sampling rate is set to 1 MHz to compensate for inaccuracies in the low-pass filter and to capture signal components above 200 kHz. Therefore, three time constraints are annotated in this step, resulting from the non-functional requirements:

• the sampling rate of the analog-to-digital conversion
• the maximum time for object recognition
• the entire calculation time of the system

The maximum time for object detection is determined by the fact that, within the detection range of up to 50m, an object echo is received within 71ms. Therefore, the sonar system must wait this time before transmitting a new signal. Within this time, the system must be able to process an echo and perform object detection. Object detection is performed using cross-correlation. This requires a further time constraint, which results from the existing functional system design and the system requirements. The Fourier-transformed transmitted signal must be stored before the first echoes are received. The maximum time until storage is determined by the fact that the detection range starts at 2m. The first echoes can be received within 3ms. Therefore, the maximum time until storage (T_Storage) must also be less than 3ms. Figure 7 (see PDF) shows how this constraint is annotated in the functional system design.

Platform design

In our design study, an existing hardware platform is reused for the platform design. It is represented as a platform component model (see Figure 8, PDF) available and consists of six platform modules: the FPGA motherboard, the FPGA extension board, the A/D converter board, the transducer interface, the transducer itself, and a power supply module.

Here it becomes clear that the processor elements (PWM and NIOS) are physically connected to each other via the Avalon bus. The Avalon bus also serves as a connection to the CAN controller and the SPI controllers "AD-Controller1" and "AD-Controller2", which are located on the FPGA extension board. The processor elements perform different tasks. To logically separate them, three domains are created when building the platform domain model of the hardware platform, encapsulating the processor elements (see Figure 9)., PDFThis also overcomes the physical separation of the platform modules, and relevant resources are made available to the logical domains.

All hardware components are represented by appropriate resources; for example, the memory elements MEM2 and MEM3 are modeled as memory resources. All resources used by multiple domains are modeled as shared resources and visualized in the domain view in the space between the utilizing domains.

The NiosMainSystem domain, which encapsulates the NIOS processor element, represents a memory partition (using the MEM3 resource). In contrast, PwmSubsystem is only a compute time partition.

After the hardware domains are modeled, higher-level domains, such as the operating system in the NiosMainSystem, are modeled. Here, two tasks (sub-domains) are modeled, each offering different services. A scheduler (resource manager) can handle up to 64 tasks (see Figure 9)., PDFThe hardware domain PwmSubsystem does not require an additional software layer; the application elements are directly bound to the services of the hardware domain.

Binding of sonar application and platform

Once both the application and the platform have been modeled, the application elements can be bound to the platform. Figure 10 (see PDFThis example shows how tasks are bound to domains and their execution services. Tasks are bound to domains by placing them in the domain's execution area, the free space. The binding of communication (ports and links) or special tasks such as memory and time is not shown here.

The platform provides a domain FftSubsystem specifically designed for discussing Fast Fourier Transforms. Therefore, the CrossCorrelation module and the IFFT task are bound to the execution service of this domain. The SignalGenerator application task is bound to the PwmSubsystem domain. As shown in Figure 10 (see PDFAs shown in the diagram, the tasks of the TargetDetection module are divided between two different domains. The EnvelopeFilter and ThresholdFilter tasks are executed by the NiosMainsystem domain and its subdomain Task1, respectively. The Task2 domain binds the Management module, thus enabling concurrent execution of Management and TargetDetection on a single processor.

Summary

Our design methodology and associated metamodel demonstrate how the unique characteristics of the dynamic behavior of embedded software can be taken into account. Particular attention is paid to the dynamics of the hardware/software interface.

In our further research, we aim to analyze the relationship between application and platform – particularly their intuitive graphical representation – and focus more on the integration of constraints into application and platform elements. This will be based on an implementation of the design methodology and the metamodel.

Bibliography and list of sources

[1] LP Carloni, F De Bernardinis, C Pinello, AL Sangiovanni-Vincentelli, and M Sgroi. Platform-Based Design for Embedded Systems. In R. Zurawski, editor, Embedded systems handbook, Industrial information technology series, pages 1–26. Taylor & Francis, Boca Raton, 2006.

[2] C. Hausner and F. Slomka. Abstract Modeling of Embedded Systems Hardware. In Proceedings of the 3rd International Conference on Simulation and Modeling Methodologies, Technologies and Applications (SIMULTECH 2013), pages 251–258, 2013.

[3] I. Jacobson. Object-oriented software engineering: A use case driven approach. Addison-Wesley, Harlow, revised printing edition, 1998.

[4] G. Karzai. Modeling Cyber-Physical Systems: Challenges and Recent Advances, September 5, 2014.

[5] Object Management Group. OMG Systems Modeling Language, version 1.2 (OMG SysML). Object Management Group, Needham, 1.2 edition, 2010.

[6] Object Management Group. UML Profile for MARTE: Modeling and Analysis of Real-Time Embedded Systems. Object Management Group, Needham, 1.1 edition, 2011.

[7] Object Management Group. Unified Modeling Language (UML), 2013.

[8] AL Sangiovanni-Vincentelli. Defining platform-based design. 2002.

[9] F. Slomka, S. Kollmann, S. Moser, and K. Kempf. A Multidisciplinary Design Methodology for Cyber-physical Systems. In SV Baelen, S. Gérard, I. Ober, T. Weigert, H. Espinoza, and I. Ober, editors, Proceedings of the 4th International Workshop on Model Based Architecting and Construction of Embedded Systems ACES-MB 2011, CEUR Workshop Proceedings, 2011.