Demonstrator Case Study

Performance Requirements:

Capacity Requirements:

These requirements are first written in a several spreadsheets and then are imported in Modelio, as indicated in Fig. 1.

Fig. 1: Importing System requirements in Modelio

Once these requirements have been imported, then can be graphically represented via SysML requirements diagram, as show in Fig. 2. Here in the figure, an overview of the different requirements is shown, along with the dependencies between the requirements. For example, performance, capacity and collision avoidance requirements all derive from the global requirements of the car architecture.

Fig. 2: An overview of the different system requirements

Designing the initial system structure:

Once the requirements have been specified, we move on to defining the system by means of SysML blocks and internal blocks. Initially, we create an automotive domain block which represents the domain in which we are working in. As seen from Fig. 3, the block is linked to a related diagram Automotive Domain Definition. This feature in Modelio enables us to link diagrams to any modeling element, in order to navigate from the model element in question to its related diagrams. The related diagram in question in an internal block diagram which illustrates the internal composition of the automotive domain block.

Fig. 3: The Automotive Domain block illustrating the global domain

Fig. 4 shows the internal composition of the automotive domain block. It illustrates a Car block being instantiated as a part, and having relationships with other parts, some of which correspond to the different actors in the automotive domain subsequently described in Fig. 5, while a part represents the external environment in relation to the car.

Fig. 4: An internal SysML block diagram illustrating the car and related elements

Here in Fig. 5, we see the organization of the different actors present in the automotive domain. As the names suggest, driver and passenger actors play their roles accordingly, while the external object is further detailed as either being a pedestrian or another vehicle on the road. While it was possible to add more actors to this figure, such as trees, speed breakers/bumps, etc.; these aspects have not been illustrated in the case study.

Fig. 5: The different actors involved in the system specifications

Fig. 6 gives an overview of the different use cases relative to the car. The car is to be driven by the driver, which could include starting/stopping the car, accelerating, braking, steering as well as notifying other cars/pedestrians (by means of car lights, horn, etc.). Additionally the driver has to make sure to avoid any collisions with incoming external objects.

Fig. 6: The different use cases related to the driving of the car

Fig. 7 gives the internal block description of the Environment block. We only chose to specify two aspects of the external environment, namely the weather and the road.

Fig. 7: An internal block diagram showcasing the composition of the external environment

In Fig.8, we describe the block structure of the car by means of a block diagram. As seen in the figure, the main car block is composed of several sub-systems such as: the power system, braking system, the electronic/electrical systems (such as sensors, lights, etc. ), chassis body (doors and windows), interior body (car seats, seat belts, carpet, etc.), misc systems (air conditioning, bearings, windshield vipers, etc.) and the the car collision avoidance system, which is the special focus of our case study. Here, as seen in the figure, the visual display of the different blocks is set to an image based representation, in order to illustrate the blocks as rectangular blocks in the SysML block diagram, possible in Modelio. This is different as compared to a structural representation of the blocks, as shown earlier in Fig. 4 and Fig. 7.

Fig. 8: The Car block diagram depicting the relation with its sub-systems

Once the block descriptions have been carried out, it is possible for us to return back to Fig. 2 and update the diagram by adding aspects that are able to complete the initial system requirements, as seen in Fig. 9. Here as seen in the figure, the global requirement is being satisfied by the car block, while the remaining requirements are being satisfied by the different car sub-systems, such as the car collision avoidance system, interior body, braking system and power system blocks. Finally, the collision avoidance use case defined in Fig. 6 is also illustrated in the figure, which refines the collision avoidance requirements.

Fig. 9: The requirements being satisfied by the sub-systems of the car

Fig. 10 provides an internal block structure view of the car block. While in Fig. 8, we illustrated the composition of the car and its related sub-systems, in this figure, we define the relationships between the different sub-systems themselves. For example, the power sub-system is linked to the chassis, the braking system, the interior body, the car collision avoidance system and the electronic/electrical systems, as it provides power to these sub-systems. While it is also possible to illustrate the flow of power (or electric current) between these sub-systems by means of SysML flow ports, we avoided their usage in this particular case study in order to avoid conflicts, as the notion of flow ports has been depreciated in the latest OMG SysML 1.3 specifications.

Fig. 10: The Car internal block diagram expressing the relationships between the different sub-systems

Once we finish with the block based description of our car and its underlying sub-systems, we now turn our focus towards the car collision avoidance system. We now make use of the UML MARTE profile to differentiate between the hardware and software aspects of this sub-system and annotate its underlying components accordingly with appropriate MARTE stereotypes to illustrate functional aspects such as related to system frequency, software scheduling policies, transmission capacity, as well as non functional characteristics, such as related to system performance.

In Fig. 11, we showcase the Car Collision Avoidance System which is further composed of two parts: a CCAS software instance and a CCAS execution platform instance which correspond to the software and hardware aspects of the CCAS. The car collision avoidance system is itself stereotyped as a ProcessingResource stereotype from the MARTE Generic Resource Modeling package, illustrating that the CCAS possesses processing capabilities. The CCAS software class and its instance are both appropriately stereotyped as ConcurrencyResource to denote concurrent logical resources, while the CCAS execution platform and related instance are annotated with the ComputingResource stereotype. For detailed description of these and other MARTE stereotypes used in the case study, we refer the reader to OMG's MARTE 1.1 specifications.

Detailing the hardware and software co-design aspects:

Fig. 11: The Car collision avoidance system and its hardware/software aspects

In Fig. 12, we describe the global behavior of the Car collision avoidance system by means of a state machine. The CCAS state machine consists of two main states: a no Action simple state and an Action composite state, which itself contains two simple states: warning and critical action states. The car collision avoidance system remains in the initial no action state until the distance of the car from incoming objects is greater than 3 meters. If the distance between the car and incoming objects decreases to less than 3 meters, than the CCAS enters into the action state. If the distance is still less than 3 meters but greater than 2 meters, the CCAS remains in the warning state and informs the drivers of possible collision warnings by means of information on the HUD and via alarms. This is in fact carried out by the CCAS sending commands to the Engine Control Unit in the power sub-system of the car, which interacts with the electronic/electric subsystem to perform the necessary actions. As we only focus on the CCAS in our case study, these aspects have been omitted from our example.

If the distance decreases to less than 2 meters, than a collision is imminent with an incoming object. The CCAS then switches to the critical action state, in which the CCAS takes necessary action in case of a collision, such as decreasing speed, applying seat belts, launching emergency brakes and raising the air bags.

Fig. 12: The global state based behavior of the Car collision avoidance system

Fig. 13 illustrates the internal composition of the CCAS execution platform initially described in Fig. 11. The execution platform is in fact a multi-processor systems-on-chip (SoC) which contains two microblaze softcore processors, appropriately stereotyped as HwProcessor from MARTE Hardware Resource Modeling package. Each of the two microblaze has a local memory (block RAM or BRAM annotated with HwRAM stereotype) connected via a local memory bus typed as a HwMedia. The up1 instance acts as the primary controller while the up2 instance acts as the secondary controller.

The two processors communicate with the different Intellectual Property (IP) peripherals such as the camera and obstacle detection modules (both typed as HwDevice) by means of the processor local bus or PLB. The PLB is part of the IBM Coreconnect bus architecture and is annotated in the model as a HwMedia accordingly. The system clock represents the physical clock of the execution platform and is appropriately doubly stereotyped as a HwClock and a Clock from MARTE Hardware Resource Modeling and Time Packages respectively. The two stereotypes are used as each stereotyped represents different aspects of time. The Hwclock stereotype enables to specify aspects such as operational frequency, while the clock stereotype enables to link this part with a clock type (defined subsequently in Fig. 14) of different natures (discrete or dense for example) and to express timing standards (such as UTC or Coordinated Universal Time) and units (such as seconds or milliseconds for example).

Finally, the execution platform contains an external port with which the execution platform communicates with the rest of the car sub-systems.

Fig. 13: The execution platform of the CCAS

Fig. 14 describes the different clock types defined for our case study. We first specify the ideal clock of the system and stereotype as a ClockType using MARTE time concepts. This clock is discrete in nature and has its units defined in seconds. The system clock present in the previous figure is specified here as well. The system clock is related to the ideal clock by means of a ClockConstraint that can determine the relationship between different clock types. Here, the clock constraint specifies that the system clock runs 10 times faster than the ideal clock. So for example, if the ideal clock runs at 10 MHz, then the system clock runs at 100 MHz respectively.

Fig. 14: Clock and clock types for the CCAS execution platform

Fig. 15 depicts the internal behavior of the Car module present inside the execution platform by means of a Camera state machine. The camera remains in an initial idle state inside the composite Not capturing state until the primary control sends a command to it to start taking images for image tracking. It then switches to a configuring state where the camera is configured to take the images. If the configuration is not completed in case of an error (such as a fault with the camera lens), then this results in the state machine to terminate and report back the information to the primary controller. In case a configuration is completed without the presence of an error, then the camera enters the capturing image state where it takes the images for the eventual image tracking process.

Fig. 15: The state machine behavior of the camera module in the CCAS

Fig. 16 depicts the activity based behavior of the obstacle detection module. The module receives incoming samples from the radar present in the car which are in turn processed (For example, noise filtration and execution of a correlation algorithm), and afterwards sent to the primary controller, that determine the probability of a collision.

Fig. 16: The activity based behavior of the obstacle detection module in the CCAS

Fig. 17 showcases the software part of the CCAS. Here as seen in the figure, the software consists of several tasks such as braking, radar and obstacle detection tasks which communicate between themselves via a communication task (annotated as a CommunicationMedia). These tasks can be scheduled, as indicated by the MARTE SchedulableResource stereotype annotated on the tasks. The scheduling policy of these tasks is determined by a scheduler, the control task in this particular case, which is appropriately stereotyped as a Scheduler.

It should be noted that the parameter types of the different task functions (such as receiveSignals operation of the obstacle detection task) such as Image and Results are not defined in the system specifications themselves, but are initially defined externally and subsequently imported in the design project, promoting IP re-use capabilities in Modelio. Details about this aspect are described later on in the article.

Fig. 17: The software tasks of the CCAS and their inter relations

Fig. 18 describes the internal composition of the CCAS software, containing instances of the different tasks previously defined in Fig. 17. We now focus on the image tracking task and describes its internal functioning subsequently.

Fig. 18: The software tasks instantiated in the CCAS software class

Fig. 19 describes the functional structure of the image tracking task. The task contains several threads annotated with appropriate stereotypes from the MARTE Software Resource Modeling package. Several of the tasks are annotated with the SwSchedulableResource stereotype that correspond to the logical processing context. The SwMutualExclusionResource on the output thread indicates a mutually exclusive resource.

Additionally, the image tracking task is also annotated with the MemoryPartition stereotype which indicates a virtual address space for the different threads.

The read thread reads an image and in turns sends it to the dct thread which performs discrete cosine transformation (DCT), and sends the result to the quantization thread. The quantization thread after executing a quantization process sends the result to the entropy coding thread that performs a entropy coding algorithm (such as a Huffman coding algorithm). Finally, the result is sent to the output thread which subsequently sends the final image to be displayed in the HUD.

Fig. 19: The different threads of the Image tracking task

Fig. 20 illustrates the allocation between the hardware and software parts of the CCAS. As seen in the figure, the software tasks are allocated to either the primary and secondary controller of the execution platform, by means of the allocation concepts defined in the MARTE Allocation Package. Also as seen in the figure, the allocations of the different threads of the image tracking task are deemed to be split (a thread is to be allocated to the primary controller while the rest are to be allocated to the secondary controller). For this reason, in this diagram, the different allocations from the image tracking task to the two controllers are linked via the relation diagram dependency in Modelio, to illustrate this underlying allocation. This allocation is subsequently detailed in Fig. 21.

While it was possible to create a three level hierarchy in the same allocation diagram illustrated in Fig. 20 (i.e., illustrate the underlying composition of the image tracking task in the same figure, and define the allocations from the different threads to the two controllers in the same figure, it is a design choice to implement the allocation in two steps.)

Fig. 20: Allocation between the different software tasks and hardware components of the CCAS

Fig. 21 depicts the secondary allocation initially summarized in Fig. 20. As seen in the figure, the different threads of the image tracking task are allocated to the two controllers present inside the execution platform. The read thread is allocated to the primary controller, while the remaining threads: dct, quantization, entropy encoding and output threads are sequentially allocated to the secondary controller, where they will be executed in a sequential manner, due to the kind and nature attributes of the allocate stereotype on the different allocation dependencies being set to structural and spatial distribution as according to the MARTE Allocation package (not shown in the figure).

Fig. 21: Allocation of the different threads of the Image tracking task to the primary/secondary controllers of the execution platform

Schedulability analysis:

Fig. 22: An interaction overview diagram of the CCAS

Fig. 23 describes the obstacle detection sequence via an interaction diagram. It indicates the communication flows between the different tasks of the execution platform.

Using the MARTE Schedulability Analysis Modeling package, it is possible to determine the average and worst case execution times for these flows. For example, the SaStep stereotype include worst and best case execution times, while SaCommStep can additionally express the size of the message transmitted or received. Additionally, the ODM Sequence interaction is itself stereotyped as a GaScenario, indicating it is one of the possible scenarios related to the system (not shown in the figure).

Here, the radar task sends data to the obstacle detection task by means of the communication task. The obstacle detection task performs the detection calculation and sends the computation results to the control task by means of the communication task. The control task after receiving the results, determines the probability of a collision and takes necessary actions.

Fig. 23: Interaction illustrating the Obstacle detection sequence

Fig. 24 depicts the camera sequence by means of an interaction as well. The camera task after capturing an image, sends it to the image tracking task (for eventual image tracking process) by means of the communication task. The image tracking process is depicted in the interaction occurrence (also called an interaction use) entitled the image tracking sequence. The internal behavior of this related interaction has not been detailed in the case study. Finally the image tracking task sends the computation result to the control task.

Fig. 24: Interaction illustrating the Camera sequence

Fig. 25 expresses another scenario related to application of brakes in which the control task, after computing a decision, carries out a brake operation for this particular scenario, and sends the braking command to brake task by means of the intermediate communication task. Once the command is received, brakes are applied (either normal or emergency brakes, depending upon the condition whether the collision is imminent or not). This Braking sequence is also stereotyped as a GaScenario.

Fig. 25: Interaction illustrating the Braking sequence

Re-use of Intellectual Property:

We now describe how we can carry out concurrent engineering with Modelio. Modelio provides the notion of model components which are defined as either user defined or third party independent and identifiable components that can form parts of a larger model, and are packaged into a single file. Sometimes referred also as Reusable Autonomous Model (RAM) components, these components can be used in a collaborative teamwork context, to allow different system designers, developers or development teams working on the same project to work only on a limited part of the complete project model. They also allow components developed by a third party to be integrated in a system model, or to provide a new implementation of an existing system component to be successfully become part of the modeled specifications. Thus RAM components can be viewed as promoting IP re-use, one of the most significant aspects of systems engineering.

In the particular case of our example, some of parameter types of the different task functions were defined in another instance of Modelio and then integrated as a RAM component entitled external types, in the Modelio project containing the solution model as seen in Figure 26.

The RAM component after a successful integration in the original project was instrumental in the design specification of the CCAS, as seen in Fig. 17. In the same manner, different components of the system can be defined by different system designers and then incorporated in the global system, promoting parallel design execution.

Fig. 26: A Modelio RAMC deployed in the project with external data types

Modelio added features for increasing design productivity

Impact Analysis

We now describe the novel features in Modelio, which can be used to increase design productivity of system designers, such as automatic Impact Analysis of modeling elements, generation of diagrams and documentation among others.

We first describe the Impact Analysis feature of Modelio. This feature enables identifying of consequences of a change to a requirement, goal, business rule or dictionary. For example, in the particular case of our example, we selected the image tracking task for impact analysis, in order to see possible consequences if that particular software task is modified or removed.

As shown in Fig. 27, the Impact Analysis results illustrate that that different system concepts depend on the image tracking task, such as the control task and we can check the dependency details as well. This summary can help designers to deduce any possible

consequences/effects that could arise by changing either a sub-system or the system itself.

Fig. 27: Impact Analysis of the Image Tracking Task

Automatic Dependency Diagram creation

Automatic diagram generation is an extremely useful function of Modelio, notably if massive code reverse operations are run, during which existing code can be transformed into a model in order to analyze its design or documentation production. Modelio proposes a pragmatic approach to automatic diagram creation, as normally designers may find themselves asking the question of what modeling aspect of the system to show and how to show it effectively.

Modelio thus enables a limited number of generated diagram types, whose contents and presentation are precisely defined, and whose usefulness and use can be predicted. The needs of users on this type of element can be split into two categories:

1. The need to analyze the structure of the element, in other words, what is it made up of and what does it contain;

2. The need to analyze the position of the element and its role within the system. In this case, it is a Dependency/Impact Analysis.

Modelio enables automatic generation of several diagram types, which are as follows:

• Dependency diagram;

• Inheritance diagram;

• Class structure diagram;

• Package structure diagram;

• Sub-package diagram;

We now describe the functionality of a Dependency diagram, as seen in Fig. 28. The Dependency diagram can be seen as an inverse of the Impact Analysis diagram, as it indicates how a modeling aspect (such as a system block) is dependent on other parts of the system in question. It shows the outgoing and incoming dependencies of a modeling element.

In the figure, the communication task depends on several other software tasks and system components for its composition. It should be noted here that modeling aspects (sub-systems/interfaces, types, etc.) defined by the designer are visualized differently, for example here, they are colored in pink, while those defined by a third party are colored in yellow. This enables to create a clear distinction between the internally/externally defined system concepts. For example, if we check the impact analysis of the relationship between communication task and the results user defined data type, we would get the results as described in the second part of Fig. 28.

Fig. 28: Dependency diagram of the Communication Task

Automatic Sub-Package Diagram Creation:

Similarly, we illustrate the automatic generation of a sub-package diagram, as seen in Fig. 29. The aim of this automatic diagram is to show the internal structure of a package, in other words the contents of the package, along with the links that exist between its sub-packages. It is often these links which establish the package’s encapsulation function.

Here, in the figure, we generate the sub-package structure of the root package of our modeled project, which contains a hierarchical organization formed by the different underlying sub-packages.

Fig. 29: Sub-package diagram

Traceability Management features in Modelio:

We now illustrate the traceability management features in Modelio, as seen in Fig. 30 and Fig. 31. This feature enables creation of traceability links between different modeling elements (for example, between requirements and system blocks).

The orientation of the created link (whether it is from the central node’s element to the dropped element or vice versa) is defined by the point at which a designer drops the element, with relation to the central node. The links editor tries to determine the type of the created link based on the types of link visible at the time of the drop (such as (generalizations, associations, dependencies, etc), If several types among those visible are valid, a dialog will open, asking the designer to choose the exact type to use for the creation.

Additionally, different upstream/downstream levels can be displayed, as indicated by a one-level upstream level in Fig. 30, and two up-stream levels in Fig. 31, with PERCC as the central node. Finally, usage guidelines about the traceability management features are can be found on the Modelio wiki.

Document generation capabilities:

Static document generation:

Modelio Document Publisher makes it easy to write and produce quality documentation, simply by making the most of the models built by a systems designer. By providing assistance in what he should write, this module ensures that a designer needs only write what is truly necessary, before automatically producing documents of a quality far superior to those created manually.

For example, a designer can generate detailed documentation that includes a glossary, requirements, a section dedicated to use cases, a section dedicated to class diagrams and a traceability matrix, with hypertext links systematically included, as seen in Fig. 32. Modelio also permits designers to define their own document types with ease, by means of a document template editor. The template editor uses a dedicated graphical editor and is utilized for the creation of document templates: A document template can be viewed as a detailed table of contents that describes the form of the document, which the designer wishes to generate from the modeled specifications.

Fig. 32: Document generation features in Modelio

Web Model generation:

The Web Model Publisher is an interesting feature of Modelio, as it enables designer to review their complete project (present with the different hierarchical levels, modeling elements, description, etc.) without the need of a Modelio installation. This can be useful for collaborative reviewing purposes, as a designer can send his design to a senior systems architect who in turn can review the whole project and send his reviews to the original designer for eventual design modifications.

The Web Model Publisher module browses a modeled specification and produces a complete and comprehensive documentation in HTML. Any description notes provided by the designer are displayed within the diagrams. Additionally, hyperlinks are generated from the model, within diagrams, chapters and texts, as seen in Fig. 33.

Fig. 33: Web Model creation in Modelio