EN 
DE From specification to validation
Authors: Arne Noyer, Padma Iyenghar, Elke Pulvermüller, Osnabrück University; Joachim Engelhardt, Jürgen Kreyßig, Ostfalia University of Applied Sciences; Jonas Diemer, Symtavision; Michael Uelschen, Osnabrück University of Applied Sciences
Contribution – Embedded Software Engineering Congress 2015
In embedded software engineering, timing requirements are among the most important non-functional requirements. Therefore, specialized tools are needed to analyze and validate the timing behavior of a realized embedded software system. Regardless, model-based software development continues to gain importance in order to manage the increasing complexity of embedded software. The Unified Modeling Language (UML) and Matlab/Simulink, among others, have become established as modeling languages. It is also possible to define timing behavior for model elements. Furthermore, it remains advantageous to manage requirements in specialized requirements management tools. A workflow for integrating timing requirements from specification to validation is presented. This workflow bridges the gaps between the different design domains.
Introduction
Embedded systems are increasingly used for a variety of purposes. As a result, they must perform more and more functions, which are often interdependent. This leads to increasing complexity in the software development of such systems. A commonly used approach to manage this complexity is the use of model-based software development. Among other languages, the Unified Modeling Language (UML) [1] has become established as a standard. However, specifying requirements remains essential.
For requirements management, specialized tools such as DOORS [2] and Polarion [3] are typically used. Requirements relating to timing behavior can also be captured textually and/or through user-defined attributes. To ensure that requirements are considered throughout the entire software development process, requirements traceability is essential. This is the only way to guarantee that all requirements are implemented and that any changes to the requirements are analyzed to determine which corresponding model elements need to be adjusted (impact analysis).
Beyond simply capturing time requirements textually, these can also be further specified in models, for example, by directly defining the maximum execution time for a modeled operation. Furthermore, models can be used to model other aspects such as tasks with their period, priority, and execution times, as well as to assign operations to tasks. Specialized tools like SymTA/S [4] are used to model such properties, enabling the analysis and validation of software's timing behavior. However, timing properties can also be captured in other modeling languages such as UML. To ensure that such models are consistent with those in analysis tools, the traceability of elements is crucial. Data synchronization also plays an important role here.
The following example illustrates how requirements for timing behavior are synchronized with UML models and how timing properties are further described in UML and subsequently validated with an analysis tool.
Tracking time requirements
In Figure 1 (see PDFThe requirements for a subsystem of a cordless screwdriver are presented in a requirements management tool. Time requirements were not only recorded textually, but also in the additionally defined attribute. Boundary Specific values for time limits are described.
The software implementing the requirements was developed using a model-based approach with a UML tool. To link requirements in requirements management tools with UML elements for traceability, various approaches exist, such as the Gateway for Rational Rhapsody [5]. Since existing solutions are often proprietary to specific tools, the requirements in this project were synchronized between the requirements management tool and the UML tool using the standardized Requirements Interchange Format (ReqIF) [6]. The process for exchanging requirements is shown in Figure 2 (see PDF) visualized.
In the requirements management tool, both a functional specification and a requirements specification were created. The requirements specification was then exported to ReqIF and subsequently converted to UML format and imported using a specially developed mechanism. During the import into UML, a UML package is created for each requirements document from ReqIF, containing the requirements contained in the document. The different types of these requirements are represented by UML stereotypes, which capture content/properties via tagged values (see Figure 3)., PDF). This representation Converting requirements from ReqIF to UML now allows relationships to be created between UML elements and requirements. UML dependencies are used in the UML tool to create these relationships.
Figure 4 (see PDFThis diagram illustrates the relationships between UML elements and requirements. Furthermore, time properties have been further specified here, as evidenced by various stereotypes and TaggedValues.
To make these relationships visible in requirements management tools, a method was developed that analyzes these relationships in the UML model and transfers the UML elements related to a requirement back into the ReqIF file. The ReqIF file can then be imported back into the requirements management tool. Figure 5 (see PDFThis shows how representations for UML elements and their relationships are displayed in the requirements management tool. This process enables complete traceability between requirements and UML elements in both directions.
Model-based specification of time behavior
In Figure 4 (see PDFIt is already evident that the time behavior in UML has been specified in more detail. For this purpose, the UML profile for Modeling and Analysis of Realtime and Embedded Systems (MARTE) [7] used through the stereotype SaStep The profile includes, among other things, execution times for operations. Furthermore, details for the target platform were modeled, as shown in Figure 6 (see PDFThe target platform contains three tasks (stereotype: SchedulableResource) that are executed with different frequencies and execution times. The operations are assigned to these tasks, and the tasks, in turn, are assigned to a CPU core (stereotype: SaExecHost), which is also modeled and for which a scheduling mechanism has been defined.
In addition to the platform, execution paths were also modeled using UML/MARTE, as shown in Figure 7 (see PDFThe execution path indicates which operations (runnables) are executed in which order in a scenario for which timing behavior will later be tested. The execution times for the operations are also shown here. (About the stereotype) SaEndToEndFlow The maximum allowed execution time for the entire path was defined.
Validation of time requirements
To analyze the modeled temporal behavior, model transformations were performed between the UML format and the analysis tool SymTA/S [4]. The procedure for this is shown in Figure 8 (see PDFIt is advantageous if analysis results are also transferred back into the UML model, so that a UML developer can directly check the relevant elements to see if the timing behavior is valid.
In addition to other analysis methods, SymTA/S supports the execution of scheduling analyses. The result of such an analysis can be summarized as shown in Figure 9 (see PDF) can be visualized.
A pie chart shows the CPU utilization (see Figure 10, PDFIn this example, the total CPU utilization is 84%, ensuring that the timing properties of the modeled tasks are adhered to. The analysis results can be visualized again in UML using stereotypes and tagged values. The modeled core in the UML model uses a stereotype specifically suited for this purpose. SaExecHost used.
Synchronization of time properties between different modeling domains
Besides UML, there are other modeling languages used for system description. Matlab/Simulink [8] is particularly widespread in the field of embedded systems. However, timing requirements cannot be directly input here. For a feasibility study to address this problem, a simple timing analysis of a Matlab/Simulink model using the timing analysis tool SymTA/S was initially pursued. For this purpose, Runnables and Tasks can be specified in Simulink as well as period and Core Execution Time (CET) A runnable was used as the time requirement for an analysis. A custom form with the values was used to input this data into the Simulink model. Period and CET(min, max) created, which can be applied to Matlab subsystem blocks.
Figure 11 (see PDFThe diagram shows the controls of a cordless screwdriver. Operations are grouped into subsystem blocks, referred to here as... runnable 1 and runnable 2 These blocks are visible for time analysis. Runnable interpreted, the operations contained therein as Tasks. The input form allows you to Period and CET be specified for the respective runnable.
Time properties can therefore be stored in ReqIF, UML, and Matlab Simulink. In real-world projects, this information is often found in multiple models. To ensure traceability in each domain, the mechanisms presented so far require redundant information. While automatic model transformations facilitate the transfer of information between domains, the problem arises that changes to this information must be propagated to other domains.
A research project is currently developing a method for synchronizing, refining, and validating time properties across different domains, even at the model level. This involves utilizing and extending the presented traceability mechanisms to ensure accurate data reconciliation across different tools. As demonstrated by Simulink, not every domain can directly capture traceability relationships. Therefore, a central repository will store the dependencies between the various time properties. Tool-specific extensions will then be able to retrieve this information, along with other data such as analysis results, from this repository via defined interfaces.
Summary
Using an example project, it was demonstrated how (time) requirements can be synchronized between requirements management tools and UML via the standardized Requirements Interchange Format (ReqIF). Subsequently, the timing behavior was described in more detail using the MARTE profile in UML. Information from the UML model was then transferred to an analysis tool via model transformation, enabling analyses of the timing behavior. This process allows timing properties to be described and validated early in the development process. Iterative application of this procedure is recommended.
It has been shown that integrating additional tools is sometimes more complex. A current research project aims for even closer collaboration between different domains to manage complex time constraints.
Bibliography
[1] Object Management Group, „UML Specification 2.5“ 2015 [On-line]
[2] IBM, „IBM Rational DOORS“ 2014 [On-line]
[3] Polarion Software, „Polarion“ 2014 [On-line]
[4] Symtavision GmbH, „SymTA/S and Traceanalyzer“ [On-line]
[5] IBM, „Managing requirements with Rhapsody Gateway and DOORS“ [On-line]
[6] Object Management Group, „Requirements Interchange Format (ReqIF)“ 2013 [Online]
[7] Object Management Group, „UML Profile For MARTE: Modeling And Analysis Of Real-Time Embedded Systems“ 2011 [On-line]
[8] MathWorks, „Matlab/Simulink“ 2015 [On-line]
Download the article as a PDF file
Real-time – MicroConsult Training & Coaching
Do you want to bring yourself up to date with the latest technology?
Then find out more here MircoConsult offers training courses/seminars/workshops and individual coaching on the topic of embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Real-time expertise
Valuable expertise in architecture/embedded and real-time software development is available. here Available for you to download free of charge.
You can find expertise on other topics in our portfolio here. here.
