Executable Specs: What Makes One, and How are They Used?

Model-based systems development relies upon the concept of an executable specification. A survey of published literature shows a wide range of definitions for executable specifications [1-10]. In this paper, we attempt to codify the essential starting elements for a complete executable specification-based design flow. A complete executable specification that includes a functional model as well as test cases, in addition to a traditional prose document, is needed to transfer requirements from a customer to a supplier, or from a systems engineer to electrical hardware and software engineers. In the complete form demonstrated here, sub-components of a functionally-decomposed system manifest as modular reuse blocks suitable for publication in functional libraries. The overarching definition provided by product architecture and by software architecture must also be harmoniously integrated with design and implementation. Using seven specific automotive examples, we illustrate effective ways in which executable specifications have been used in production-ready applications. Benefits of model-based development are captured, including earlier and more thorough testing, automatic document generation, and autocode generation

From Temporal Models to Property-Based Testing

This paper presents a framework to apply property-based testing (PBT) on top of temporal formal models. The aim of this work is to help software engineers to understand temporal models that are presented formally and to make use of the advantages of formal methods: the core time-based constructs of a formal method are schematically translated to the BeSpaceD extension of the Scala programming language. This allows us to have an executable Scala code that corresponds to the formal model, as well as to perform PBT of the models functionality. To model temporal properties of the systems, in the current work we focus on two formal languages, TLA+ and FocusST.Comment: Preprint. Accepted to the 12th International Conference on Evaluation of Novel Approaches to Software Engineering (ENASE 2017). Final version published by SCITEPRESS, http://www.scitepress.or

Automated Generation and Integration of AUTOSAR ECU Configurations

Automotive Open System Architecture (AUTOSAR) is a system-level standard that is formed by the worldwide partnership of the automotive manufacturers and suppliers who are working together to develop a standardized Electrical and Electronic(E/E) framework and architecture for automobiles. The AUTOSAR methodology has two main activities: system configuration and the Electronic Control Unit (ECU) configuration. The system configuration is the mapping of the software components to the ECUs based on the system requirements. The ECU configuration process is an important part of the ECU software integration and generation. ECU specific information is extracted from the system configuration description and all the necessary information for the implementation such as tasks, scheduling, assignments of the runnables to tasks and configuration of the Basic Software (BSW) modules, are performed. This activity allows the ECU to modify the configuration parameters based on the vendor-specific requirements. Due to the high complexity and redundancy of this process, it has to be supported by different tool-related editors that can automatically generate source files like *.c and *.h for the configuration. In this thesis, we propose a method to automate the ECU configuration process for AUTOSAR. We use configuration templates written in xtend programming language along with a BSW generator tool developed at APAG Elektronik. This tool can extract the configuration parameters and automatically generate the required ECU module configuration. The Watchdog module will be used as an example to generate and integrate the ECU configuration. This enables the seamless generation of the software configurations from the system level requirements to the software implementation and therefore ensures consistency, correctness, cost efficiency and reduces the work done by the developer to generate the configuration

A Lightweight Multilevel Markup Language for Connecting Software Requirements and Simulations

[Context] Simulation is a powerful tool to validate specified requirements especially for complex systems that constantly monitor and react to characteristics of their environment. The simulators for such systems are complex themselves as they simulate multiple actors with multiple interacting functions in a number of different scenarios. To validate requirements in such simulations, the requirements must be related to the simulation runs. [Problem] In practice, engineers are reluctant to state their requirements in terms of structured languages or models that would allow for a straightforward relation of requirements to simulation runs. Instead, the requirements are expressed as unstructured natural language text that is hard to assess in a set of complex simulation runs. Therefore, the feedback loop between requirements and simulation is very long or non-existent at all. [Principal idea] We aim to close the gap between requirements specifications and simulation by proposing a lightweight markup language for requirements. Our markup language provides a set of annotations on different levels that can be applied to natural language requirements. The annotations are mapped to simulation events. As a result, meaningful information from a set of simulation runs is shown directly in the requirements specification. [Contribution] Instead of forcing the engineer to write requirements in a specific way just for the purpose of relating them to a simulator, the markup language allows annotating the already specified requirements up to a level that is interesting for the engineer. We evaluate our approach by analyzing 8 original requirements of an automotive system in a set of 100 simulation runs

Verified System Development with the AutoFocus Tool Chain

This work presents a model-based development methodology for verified software systems as well as a tool support for it: an applied AutoFocus tool chain and its basic principles emphasizing the verification of the system under development as well as the check mechanisms we used to raise the level of confidence in the correctness of the implementation of the automatic generators.Comment: In Proceedings WS-FMDS 2012, arXiv:1207.184