EN 
DE Executable software functions even before series development
Authors: Andreas Lachenschmidt and Andreas Biberger, iNTENCE automotive electronics GmbH
Contribution – Embedded Software Engineering Congress 2015
With its "Executable Specification," iNTENCE presents a method that enables those responsible for functionalities to control the scope and characteristics of customer-facing functions early in the project. This is achieved through the early experience of the function via modeling. The "Executable Specification" and the traditional prose specification are created together in iterative and incremental steps, thereby increasing the quality of the specification in areas such as functional design, completeness, implementability, and testability.
The following section explains the methodology of "Executable Specification" in more detail and illustrates the successful application of the developed models in testing. The findings, necessary prerequisites, opportunities, and limitations of the methodology are summarized in conclusion.
Idea and application examples – model and specification hand in hand
Developing new vehicle functions involves a multitude of tasks that present developers with challenges. For example, the scope of the function must be defined, and the system boundaries and interfaces must be established. Throughout this process, decisions must be made regarding which concepts and implementation options will be developed. These decisions must be made, or at least coordinated, with project stakeholders.
These steps can be supported by creating an "executable specification." Alongside the written specification, models of the function are developed that already implement the functional requirements. Unlike the subsequent series development, the development of these models can be carried out in an agile process. Requirements are specified and implemented in the model iteratively and incrementally in collaboration with the customer. The model will complement the written specification but will not replace it. Only the written specification is legally binding.
To test our ideas, we implemented them in projects involving vehicle HMI and user interface development. Given the complexity of modern systems, representing designs, animations, and interactions in executable models rather than prose specifications was a logical approach. This allowed us to use usable simulations as a tangible template for series development.
Secondly, we were able to determine the added value of the ideas for data- and communication-oriented functions. Here, we created target models that corresponded to the prose specification and were able to improve the quality of the specification through feedback loops from the model development.
Classification within the development cycle
Depending on which role is assigned to create the executable specification, several deployment scenarios are possible.
In the first variant (see Fig. 1, PDFThe models are either developed directly at the customer's site or an external company, not responsible for series production, is commissioned. The specifications document (SPD) can be handed over to the series developer as requirements along with the models.
In the second variant (see Fig. 2, PDFThe series developer creates the executable specification himself during the requirements analysis and while creating his specifications document (PH). The models serve as a means of communication between the customer and supplier. The quality of the customer's requirements can be reviewed and supplemented in an agile process.
Variant three (see Fig. 3, PDFThis approach envisions dividing the requirements specification and model creation into integration stages. An expansion of the functional scope is planned for each release. This approach can quickly lead to demonstrable results in series development for newly developed functions.
Objectives of model building
Using an executable specification improves the quality of the prose specification. The following describes properties that can potentially be improved through modeling.
a) Experientiality:
The executable specification allows us to experience the functionality early in the project. This can be achieved by running the model on a PC, using it in demonstrators, integrating it into vehicle models in driving simulators, or integrating it into prototype vehicles. Conceptual and implementation decisions are easier to make by experiencing the functionality firsthand than by relying solely on a textual description.
b) Functional design:
Models help us to concretize the idea of the function to be created. Through the parallel development of the specification and the models, developers gain an understanding of the function at an initial implementation level. It is easier to assess the scope required to serve the user or neighboring systems.
c) Completeness:
During the development of the executable specification, undescribed aspects that are nevertheless necessary for implementation can be identified. It can then be assessed whether these represent specification gaps or implementation details that the software vendor is intentionally meant to address. Contradictions between requirements can be uncovered during model creation. Continuous verification of the specification during parallel model development ensures its correctness.
d) Feasibility:
The early experience of the function provides the opportunity to verify which aspects are both relevant and technically feasible and should be implemented in the series software.
e) Testability:
The models can also be used directly in the test environment. The possible applications will be described below.
Use in testing – application of the model in the test environment
A significant portion of the tests for system and acceptance testing are typically derived from the functional specifications. Since the models of the executable specification represent a functional representation of the specification, it seemed logical that these models could add value to both test phases. We examined three variations of how to use these models in testing and investigated their implementation in projects.
The first proven method for using the executable specification in testing is to use the models as test objects in a test environment. Instead of testing against the later production software component, test cases and the test environment are defined as shown in Figure 1 (see PDF) shown against the models implemented. Thus, development of the test environment can begin without the actual test object. Verification of the test environment is possible early in the project (see Fig. 4, PDF).
In the second variant, test cases and test data (test harness) were generated from the model using a tool. This enabled the rapid derivation of test cases. The test set could be expanded with minimal effort (see Fig. 5)., PDF).
In a third variant, the created models were used as test oracles. In a target-actual comparison between the software component and the model, both were stimulated with the same input data. Subsequently, the outputs of the software component and the model were compared to identify deviations. To enable a comparison, abstraction or concretization functions are generally necessary. Inputs and outputs must be prepared in these functions so that they can be processed by the software component and the model. Because the test oracle provides the expected outputs, these do not need to be implemented in the test cases. The model was used in a model-in-the-loop environment to test a model of a series software component running on an ECU integrated at the communication bus level (see Fig. 6)., PDF).
Insights – Advantages and Limitations
The application of the executable specification concept in several projects has shown that the added value of this methodology is greatest for newly developed functions without a predecessor generation. Nevertheless, reviewing and supplementing existing specifications can be useful if their quality is questioned or if the specification is intended to serve as the basis for a new generation of the function.
When translating specifications into models, finding the appropriate level of abstraction or the right level of detail has always been a challenge. Experience shows that a relatively abstract model can suffice for understanding functionality and verifying the completeness and feasibility of the requirements. However, if the model is to be used in testing in one of the ways shown, more effort will be required to incorporate the necessary details into the model for testing purposes.
It was found that an agile approach to specification and model development leads to better results. Multiple iterations and feedback loops between specification and model creation should be planned, and close collaboration with the OEM functional owners should be established. Regular coordination and joint baselining of the models, along with the specification, every 1-2 weeks are essential.
The limitations of the methodology became apparent when it came to mapping aspects beyond the perceptible function. The required temporal behavior on the embedded target platform could not be accurately modeled for the most part. While the behavior of hardware, basic software, and low-level software components can be simulated with some effort, it should be decided on a case-by-case basis whether this is truly necessary or whether a higher level of abstraction suffices.
The method presented may encounter resistance from customers, as they often perceive it as simply an additional effort due to the modeling and the need to reconcile the written specification with the executable specification. An objective assessment of whether the method delivers added value in the specific case should be made jointly with the customer to ensure transparency and acceptance. The advantages must be clearly communicated to the customer.
We were able to gain the following insights regarding the presented properties of a specification:
a) Experientiality:
Early hands-on experience leads to a better understanding of the function. Concepts can be developed to a level of maturity that would be difficult to achieve without modeling. The models support communication among stakeholders, and especially between the customer and the future production software supplier. Decisions can be made more informed because solution options are presented tangibly and can be quickly compared.
b) Functional design:
By translating the specification into a model, the necessary level of detail for the requirements could be better assessed before handover to series development. The "idea" of the function could be developed more concretely, thereby reducing ambiguities in the solution space. The likelihood of considering aspects often outside the focus of function developers, such as robustness measures at interfaces, increased, as these topics typically had to be addressed during model creation.
c) Completeness:
The application of this methodology revealed numerous discussions regarding inconsistencies and possible interpretations. This is naturally also the case without using the executable specification; however, with this approach, these discussions took place early in the project, before series development. Furthermore, aspects were uncovered that appeared "perfectly obvious" to the function developers and were therefore not explicitly specified. For the series developers of the function, however, specifying these aspects was essential and not "perfectly obvious." After consultation, these points were also incorporated into the written specification.
d) Feasibility:
Verifying feasibility based on the executable specification leads to more stable requirements. Challenges that often only become apparent during series development can be identified. Changes to the function, decided upon during series development, can then be tested on the models to assess feasibility and their impact on the function. This change loop proved to be shorter and more cost-effective than implementing the change directly into series development.
e) Testability:
The use of models in system and acceptance testing allowed development of the test environment to begin early in the project. Using the models as test oracles or as a basis for generating test cases resulted in savings in the creation of the test environment.
The concept of executable specifications provides a valuable method for ensuring the quality of requirements early in a project. Experiencing the requirements helps function developers better understand their software components. This creates a stable requirements foundation before series development begins. Using the created models in testing helps reduce the effort and costs associated with test development.
Sources
Dr. Grimm, Christoph, „Modeling, Simulation, Design of Heterogeneous Systems“,
https://www.ti.informatik.uni-frankfurt.de/lehre/ws0405/modellierung_simulation/v11.pdf
(As of December 3, 2014)
Biberger, Andreas, „Model-based development and testing of an AUTOSAR software component“
Requirements – 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 requirements/embedded and real-time software development.
Training & coaching on the other topics in our portfolio can be found here. here.
Requirements – Expertise
Valuable expertise in the field of requirements/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.
