Keywords

1 Introduction

As complexity of real-time systems and embedded applications increase, there is the continuous need of more abstract representation of such systems. Modeling systems architecture is a challenging task, since these systems are not only of great magnitude, but are also significantly different [5]. Moreover, challenges and difficulties happen when developing these systems, due to specific characteristics, including mobility and security or real-time restrictions [6, 7]. One of the main challenges to be faced in the development of solutions is to connect domain specific requirements, expressed by business analysts, with specific technological solutions designed by software architects [1, 3].

Since UML is a popular language in the software industry, and UML-based modeling tools are fully available [12], the UML community has been working with the purpose of presenting a way of modeling real-time system’s properties. One of these efforts related to embedded systems is the SysML (Systems Modeling Language) profile. SysML offers additional resources to UML, including requirements modeling [7, 9, 11], and specification of several structural, behavioral and temporal aspects of real-time systems [5, 10].

Characteristics of SysML have been recognized for requirements engineering [2, 7] and for real-time systems requirements modeling [5]. These advantages were evidenced and have been analyzed for modeling systems’ architecture [4, 12]. In this paper we present a case on an automatic headlight modeling in an automotive system in two languages, SysML and ADDL. The objectives of developing architectural representation with two different languages are: (1) to analyze the weak and strong points of each language, (2) to offer a comparative example and (3) to propose SysML as an architectural description language.

Authors of paper [12] describe a survey among 60 possible ADLs for development of automotive systems. After analysis, 3 languages for architectural description were chosen: AADL, MARTE and SysML. MARTE (UML profile) was used in a complementary way to SysML in order to model the systems execution time. However, the author considers AADL as a better alternative for architectural representation, based in criteria of code generation, formal verification, error modeling and variability modeling.

A survey of modeling languages of real-time software systems is presented in [4]. For the authors, each language has its advantages and disadvantages and, in order to properly describe the architecture of the real-time software system, is almost certain the need of complementary use of two or more languages. In the referred work, AADL, UML, SysML and MARTE are explored in the context of comprehending the contribution that each language brings to software engineering and to determine if it is viable to combine aspects of the four modeling languages in order to obtain a wider coverage in architectural descriptions.

2 Headlight Control System Details

The software requirements presented in this Section were primarily collected through reading and research in automobile manuals, web-site and the book [13]. After this stage the requirements were identified and organized for the automatic headlight control system.

In the headlight control system, the headlights are activated through a photoelectric sensor. The sensor is activated or deactivated by lightning conditions, and may be dark or light. Thus, the automatic control of headlights switches on the lights whenever the sensor feels the dark environment. For instance, the system will activate the headlights when a car enters in a tunnel or when an environment presents heavy clouds.

In this example, according to the characteristics previously listed, and to the results of the detailed domain analysis, the functional and non-functional system requirements are described in Table 1:

Table 1. Description of the system requirements
Full size table

3 Headlight System Modeled with SysML

SysML Requirements diagram allows each requirement to have an identification (ID) and a textual information using natural language in order to describe the requirement.

Fig. 1.
figure 1

SysML requirements diagram of the headlight system.

Full size image

The Headlight control Requirements diagram is depicted in Fig. 1. The diagram includes an incomplete description because, due to space limitation, the description was omitted. In Sect. 2 there is a complete textual description of the requirements. Functional requirements 13, 14, 15, 16, and 17 were not shown in Fig. 1 because these are manual requirements, and the concern in this paper is automatic requirements.

Relationship “DeriveRqt” relates a derivative requirement with its origin requirement. “Containment” relationship, (represented by the symbol \(\oplus \)—— in diagram in Fig. 1) specifies the hierarchy between requirements, its use prevent the reuse of requirements in different contexts, once a specific element of the model can only exist in a “Containment”. “Trace” relationship is of general purpose between a requirement and any other element of the model and its use occurs only for traceability reasons [8].

SysML also allows the representation of requirements, their properties and relationships in a tabular format which can be seen in Table 2.

Table 2. Requirements table (SysML) of the headlight system.
Full size table

3.1 Block Definition Model

SysML provides two diagrams which are useful for system architecture modeling: Block Definition Diagram (BDD) and Internal Block Diagram (IBD).

In the case study, BDD was developed for modeling components which are involved in the headlight system. The specified functions are implemented for secure communication with other components and with local sensors/actuators. SysML BDD is represented in Fig. 2.

Fig. 2.
figure 2

BDD headlight system.

Full size image
Fig. 3.
figure 3

IBD headlight system.

Full size image

A SysML BDD can describe general structural elements, varying from small to very large. SysML Blocks can be used to represent the hardware architecture, the data and procedures of a system [8]. In the example of the headlight system, 10 related blocks are defined. The relationship between blocks was represented by composition associations. The composition instance is synchronous, that is, if an instance is destroyed, finishing the execution, the other executions are also going to be finished. “Clock” Block controls time synchronicity. “Light system” block communicates with other blocks which are not directly part of the headlight system through the “Communication control” block, this communication is essential for the necessary information to the execution of the headlight system to be conducted.

3.2 Internal Block Model

SysML IBD (Fig. 3) models the internal operations of the “Light System” block. The doors connect to external entities and interact with a block through connectors. A flow door specifies the entrance and exit items which can flow between a block and its environment. The doors specify the flow path, data communication, operations, receptions and hardware resources (BUS). For modeling a flow path, “FlowPort” was used, specifying entrance and exit items which can flow between a block and its environment. Flow doors relay entrance and exit items for a connector which connects blocks to the internal parts. The connectors are labeled by messages which represent operations between two parts.

Fig. 4.
figure 4

Activity diagram of the headlight system.

Full size image

3.3 Activity Model

The main headlight activity is depicted in Fig. 4. Initial and final activities were modeled, decision node which represents the action of switching the headlights on and off, interactive loop with \(\langle \langle \)loop node\(\rangle \rangle \) and restrictions with OCL for repetition of the loop and to switch the headlights off in exact 3 min after the car is switched off.

4 Headlight System Modeled with AADL - External Specification

AADL descriptions consist in basic elements named components. The modeling of the interface (External specification) of components is given by the AADL type definition. A component type declaration defines the interface elements of a component and externally observable attributes, such as devices which are part of the interaction with other components and connections (see Fig. 5).

Fig. 5.
figure 5

External specification of the headlight control system in AADL.

Full size image
Fig. 6.
figure 6

Process code in AADL.

Full size image

The headlight control system, as shown in Fig. 5, is described in the AADL language. The system consists in a system unity, which contains a processor, a process and two devices. The system unity receives entrance signals coming from a sensor device named as “light\(\_\)sensor”. When the absence or presence of light is detected, the “light\(\_\)sensor” sends a signal through a door to the process named “controller”. The process receives a signal and the system starts to be executed with the information which was transmitted by the sensor. With the goal of executing a software, it was used a memory processor. The memory is a subcomponent of the processor, in memory the code is stored while the processor is in execution. The “this\(\_\)bus” is required for loading data, controlling signals and establishing data and events interchange between hardware and software components, such as in the communication between the process and the sensor.

Fig. 7.
figure 7

Internal specification of the headlight control system in AADL.

Full size image

4.1 Internal Specification of AADL Headlight System

Internal specification is specialized by an external implementation. A components implementation declaration defines an internal structure of a component in terms of subcomponents, subcomponents connections, subprogram calls sequencies, modes, flow implementations and properties. Usually, external and internal specifications are performed by alternately repeating two stages. Source code of Fig. 6 presents an internal definition and the implementation of an AADL process. The process, named “comm\(\_\)controler”, and the implementation of the process contains and controls the threads.

In the headlight control system, threads are subcomponents of the process, that is, they are an internal specification of the process and are presented in Fig. 7. These threads must be able to receive as entrance the light intensity value coming from the (“thread\(\_\)readSignal”) sensor, to process the signal and transmit to the actuator the response regarding the automatic ignition of the headlights (“thread\(\_\)controlLight”). These threads are connected with event doors, because this kind of door allows the rowing of the event associated data. The last thread must receive, as response from actuators, the current state of the headlights (“thread\(\_\)sendSignal”).

A highlight of the AADL language is that, besides allowing both textual and graphical description of the system, it relates both.

5 A Comparative Analysis: SysML x AADL

In practical terms, it was observed that abstract features such as decision making, repetition of a functionality (loop), start and end representation of an activity, characteristics that are related to reality, and consequently, to the system, are not described in AADL. The lack of these characteristics was observed while the headlights were being modeled in AADL.

Currently, AADL does not provide a specific diagram/representation to show requirements or behavior by means of actions, such as the SysML Activity diagram. In addition, it is not possible to show the relationship of requirements with the systems design in AADL, and also relationships between system design and software design.

Connectors in AADL are not differentiated, when two types of systems are related, one can only relate them as “extension”, in other words, one system only extends another. There is no other classification for connections like there is in SysML, for example, “Trace, Derive, ou Containment”.

In AADL, component is identified only by name, there is no Identifier (ID). ID is essential to identify and track easily a requirement, as shown in the SysML example in Table 2.

Developing models in the AADL graphical language is a complex activity, it is necessary to manipulate the internal diagram so that the connections are changed in the external diagram, sometimes this manipulation of the internal diagram to the external or from the external to the internal becomes confused because of the ports and connections, connections are difficult to implement in the graphical model.

SysML provides diagrams for behavior modeling, such as the Sequence diagram, Activity diagram (Figure 4) and State Machine diagram. SysML obviously has strong ability to model system behavior. On the other hand, AADL provides a limited vocabulary for behavior modeling [12].

6 Conclusion

In this paper, the main focus is to show that the SysML language can be used to systems architecture modeling. The comparison between the SysML and AADL languages is performed to understand the limitations that SysML presents and to propose improvements in the architectural aspect.

It was observed that SysML can be used extensively for modeling abstract features. SysML accurately captures the requirements, management of system complexity is developed from the initial stages of production of a system with the expressiveness of the Requirements diagram.

Block diagram and Internal Block diagram capture the systems and subsystems, provide communication between them and the necessary resources. The Activity diagram can represent the steps required for a given activity to be completed successfully, or may display a predicted deviation. This diagram also captures the main strategic decisions of a system, and serves for communication between stakeholders.

We can conclude that the Requirements, Activities, Blocks and Internal Blocks diagrams are suitable for software architecture modeling. However, SysML needs to be expanded for classification of components, implementation of the model through textual syntax and description of time properties to have features necessary for modeling the architecture of real-time systems.