Automated Specification and Verification of Functional Safety in Heavy-Vehicles: the VeriSpec Approach Guillermo Rodriguez-Navas1,2 , Cristina Seceleanu1 , Hans Hansson1 , Mattias Nyberg2 , Oscar Ljungkrantz3 , and Henrik L¨ onn3 1
IDT, Malardalen University, V¨ aster˚ as, Sweden 2
3
Scania SV, S¨ odert¨ alje, Sweden
Advanced Technology & Research, Volvo Group Trucks Technology, Gothenburg, Sweden contact:
[email protected],
[email protected]
ABSTRACT ISO 26262 is the new standard for automotive functional safety. This standard identifies major process steps across a large number of system stages as well as safety-related artifacts required as input and output of these steps. The VeriSpec project intends to identify the main challenges for the adoption of ISO 26262 by the heavy-vehicle industry and to provide useful and industrially relevant “components” (methods, tools etc.) required by the standard. The project work targets two main research goals: (i) requirement formalization support, including a usable front-end for specifying requirements by using patterns, and (ii) formal analysis of realizations in form of architectural models at various levels of abstraction, by model-checking the formal representations of the latter. In this paper, we present the current challenges facing industry and justifying VeriSpec, together with a preliminary roadmap for the research.
1.
INTRODUCTION
The complexity of the electrical/electronic control systems used in vehicles is increasing at a steady pace; including an ever increasing number of software-implemented functions. The importance of guaranteeing that this growing complexity cannot put lives at risk led to the definition of a new standard for functional safety: the ISO 26262 [6]. Many heavy-vehicle manufacturers currently investigate the adoption of ISO 26262, even if it is not yet mandatory for this type of vehicles. Some aspects that have received attention in different research projects are: • Extension of automotive architecture description languages, such as EAST-ADL, to support ISO 26262 [9, Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from
[email protected]. DAC’14 , June 01 - 05 2014, San Francisco, CA, USA Copyright 2014 ACM 978-1-4503-2730-5/14/06 ...$15.00. http://dx.doi.org/10.1145/2593069.2602972.
13]. Projects: MAENAD, Timmo-2-Use. • Development of a new V&V platform, using modelbased testing, to produce safer software for automotive and transport [10]. Project: MBAT. • Definition of new techniques for system analysis and safety analysis, focusing on model and tool interoperability [14, 3]. Projects: ESPRESSO, CRYSTAL. • Development of new methods for composable safety certification according to ISO 26262, based on contract theory and component-based design [2, 12]. Projects: SafeCer, SYNOPSIS. VeriSpec–Structured Specification and Automated Verification for Automotive Functional Safety is a project that addresses two aspects not covered by the existing projects: the formal specification of safety requirements and the connection of such requirements with the formal verifications of the different system realizations. VeriSpec is coordinated by Malardalen University and involves two major Swedish truck manufacturers, Scania and Volvo Group Trucks Technology. The specific goals are: • To define concrete methods for specification and analysis of requirements with safety relevance • To provide automated techniques for exhaustive (formal) verification of the system realizations, at different abstraction levels • To guarantee seamless integration of these techniques and tools with current practices in industry VeriSpec will also investigate the human and organizational factors that affect how systems are documented and, particularly, how the requirements are written. The aim is to be able to provide technological support for new systemspecification and system-verification activities, needed for ISO 26262, but without causing a major break with respect to the current development processes at the companies.
2.
CHALLENGES
The current situation in the automotive industry with respect to requirements specification is similar to other industries.
• Requirements are written by developers with no specific training in system verification or formalization. • Requirements are written in natural language, with diverse language structure, and are often ambiguous. The ambiguity is solved through verbal communication among the engineers. • Backwards compatibility between models and implementations is not guaranteed, and the requirements can be traced in the implementations only by expert review. • There is no automatic support for the decomposition of requirements into subrequirements that can be assigned to architectural elements or components. Furthermore, there is no formal analysis of either the consistency or the completeness of the requirements once they are decomposed. • During development, requirements and system descriptions are defined according to different representation standards depending on e.g. vehicle domain and company, even if systems are tightly integrated in the final product. In summary, the automotive design process is still a very human-intensive activity; much information is informally exchanged among the engineers and due to this, most verification activities cannot be automated and need human intervention. This circumstance by itself does not decrease the quality of the products, but makes the development less efficient and more costly. Moreover it does not provide the traceability required by ISO 26262; there is still a strong need to harmonize specification and verification across the different systems of the vehicle. Another factor that increases the verification cost is the existence of numerous product variants, i.e. products with slightly different features, which have to be tested individually. Model-based design (MBD) technologies promise to reduce the verification time and effort by moving some verification activities into earlier development phases. ISO 26262 also encourages the use of MBD for the traceability it provides. However, in the long run, verification of MBD is only possible once the problems addressed by VeriSpec have been solved. For instance, model-based testing (e.g. [7]) requires i) an accurate formal model of the system and ii) that the requirements to be tested are formally specified. Other types of safety-related analysis recently suggested (e.g [2]) also require formal modeling of the components. From a process perspective, an important question still remains open: who will create these formal entities (models and requirements) needed for verification? and how? The VeriSpec answer is that the same developers will do it, with the appropriate tool support, during design time.
3.
ROADMAP
The development of a vehicular electrical/electronic system starts with specifying the system requirements and assigning them to ECUs/architectural elements. One of the focal points of ISO 26262 is expressing and managing requirements in an effective and unambiguous way, such that both engineers and stakeholders have a common understanding of their content. The most used method of specifying
requirements in industry is still free text. While this is an easy-to-grasp and flexible representation of requirements, it is also prone to inconsistencies and redundancy in specification. Recently, patterns/boilerplates [5, 1] are advocated as being good ways of preventing inconsistencies and ambiguities from being introduced into the specification. Methods for automatic translation of patterns into temporal logics have also been proposed [8]. The next step of linking requirements to architecture should ideally give the designer/engineer the possibility to visualize the hierarchy of requirements, from system level down to the level of architectural elements. Such a link also ensures traceability between requirements and architecture, fundamental for certification purposes, and enables the analysis of completeness and consistency of the requirements vs. subrequirements. Once requirements are unambiguously specified and decomposed, one needs to verify the compliance of the realizations to required behavior, which is another necessary aspect for adhering to the ISO 26262 standard. The realizations could be in the form of a fixed architecture, or modeled in a dedicated language such as EAST-ADL [4], at various levels of abstraction (analysis, design, etc.). The analysis is carried out at both component, as well as integration level, up to the system level. The analysis activities can be done by simulating the architectural model, or by formally verifying a description of the system bearing a formal semantics. An important aspect of verifying the intended behavior of realizations is that components themselves, as well as interconnected components, might need to be verified. In such cases, both the interface behavior as well as the internal structure of a component or a set of inter-connected components has to be accounted for. This means that one needs to formally specify the interface and the internal behavior of the architecture in the same formal notation understood by a model-checker or by other formal verification tool. Last but not least, the verification results (be them a pass/failed verdict or a counter-example to the model) need to be traced-back to the requirements specification, as well as to the architectural models. In case a specific requirement has not been met by the architectural model, it follows that the requirement should be recognized in the initial requirements spec, and the erroneous components should be identified in the architecture, across various levels of abstraction. This is in sync with the ISO 26262 recommendation of ensuring traceability between requirements and realizations.
3.1
VeriSpec Contributions
The VeriSpec project will propose and develop concrete mechanisms, methods and tools that serve the system development steps described above, such that the outcome can be integrated with the development process at Scania and Volvo Group Trucks Technology. Moreover, VeriSpec intends to align with the already existing research results that have emerged from previous as well as current projects (MAENAD, MBAT, ESPRESSO, SafeCer, etc.) in which the companies, as well as MDH are or have been involved. In Figure 1 we show the described roadmap, instantiated with the current methods and tools available at MDH right now, originating from the current MBAT project. The figure basically shows a first representation of the VeriSpec framework. The main contributions of VeriSpec target especially (i)
System Designer
Automatically generate Specify formalized requirements requirements via the VeriSpec front-end tool Requirements Requirements in TCTL Model
Extended ViTAL Create/ import models EAST-ADL System Models (Analysis / Design levels ) Function
Function
Link requirements to architectural elements
Port
UPPAAL PORT Timed Automata Models
Port
Port
Port
Integration Simulation & model-checking EAST-ADL + TA against TCTL requirements
UPPAAL PORT/ UPPAAL generation of model counter-examples
Pass
Trace-back the bug(s) to requirements and models
Fail
Figure 1: Potential instantiation of the VeriSpec framework with ViTAL. the automatic generation of formalized requirements, based on patterns, (ii) linking requirements to architectural elements, (iii) formal verification of realizations in form of architectural models, and (iv) ensuring traceability between verification results and requirements, as well as between the verification results and architectural models at various levels of abstraction. In a first approach, we tackle our goals by employing the framework that MDH has developed in the MBAT project, which integrates the architectural models with componentaware model checking, in the tool called ViTAL [7]. Assuming a design-level EAST-ADL description of the system, the functional and timing behavior of each function block in the EAST-ADL model, as well as the interactions between function blocks are formally captured and expressed as Timed Automata models, which have precise semantics and can be formally verified with ViTAL (by the UPPAAL modelchecker, or UPPAAL PORT, a variant of UPPAAL). Hence, our approach, supported by ViTAL, can be used to formally prove that the EAST-ADL system model fulfills the specified real-time requirements and behavioral constraints. One main point of extending ViTAL, in VeriSpec, will be the development/adaptation of a method and a front-end tool for requirements specification, in an engineer-friendly fashion. This will be complemented by applying a patternbased method to automatically generate formalized requirements from engineer-specified ones, similarly to what has been reported in some recent automotive and avionics experiences[11, 1]. Equivalent methods and their tool support are going to be adapted and included in our ViTAL framework. Our goal is to provide a way of preventing inconsistencies from propagating into the final requirements model, and identifying the redundancy that could be introduced in the requirements. Since our framework uses UPPAAL as the back-end verification engine, the requirements will then be
formalized in a subset of UPPAAL’s property specification language, Timed CTL (TCTL), but integration with other existing verification platforms will also be investigated. Another main contribution to the existing framework is linking the semi-formal as well as formal requirements to architectural elements (functions), and providing a graphical description of the requirement hierarchy. We will verify the functional as well as the timing constraints of the realization models by model-checking the TA description of the system under analysis. The point of extension would be to be able to import architectural models and link their function blocks to behavior specified formally, as well as in an engineerreadable format (e.g. free text). A feature not existing in ViTAL is traceability of verification results to requirements and architecture. This is an aspect that we intend to provide in VeriSpec also, by exploiting the link mechanism between requirements and architecture. This feature will be integrated with other methods investigated in the ESPRESSO project, intended to advance the adoption of MBD technologies by one of the VeriSpec industrial partners [14].
4.
SUMMARY
In this paper, we have presented a selection of the main challenges faced by engineers who develop systems for the automotive industry, in the context of aligning to the ISO 26262 functional safety standard. This standard identifies major process steps and safety-related artifacts required as input and output of the process steps. The issues span a large number of system development stages, from requirements specification, their mapping onto architectural units, until the verification of realizations against (formalized) requirements, and the latter’s traceability across various levels of model abstraction. The VeriSpec project, based on the cooperation of a Swedish
academic partner, Malardalen University, with two Swedish truck manufacturers, Scania and Volvo Group Trucks Technology, intends to provide useful and industrially relevant “components” (methods, tools etc.) required by ISO 26262. Therefore, we have sketched here the preliminary roadmap for VeriSpec, and its main contributions that try to address the presented challenges. The ultimate goal is to advance the state-of-practice in automotive development, by integrating the artifacts provided by VeriSpec into the industrial system development process.
5.
ACKNOWLEDGMENT
This work was funded by the Swedish Governmental Agency for Innovation Systems (VINNOVA) under project 201301299.
6.
REFERENCES
[1] J. Barnat, J. Beran, L. Brim, T. Kratochv´ıla, and P. Roˇckai. Tool chain to support automated formal verification of avionics Simulink designs. In Formal Methods for Industrial Critical Systems, pages 78–92. Springer, 2012. [2] I. Bate and P. Conmy. Assuring safety for component based software engineering. In 15th IEEE International Symposium on High Assurance Systems Engineering, pages 121–128, January 2014. [3] CRYSTAL. Project website. http://www.artemisia.eu/project/index/view?project=46. [4] P. Cuenot, P. Frey, R. Johansson, H. L¨ onn, Y. Papadopoulos, M.-O. Reiser, A. Sandberg, D. Servat, R. T. Kolagari, M. T¨ orngren, et al. The EAST-ADL Architecture Description Language for Automotive Embedded Software. In Model-Based Engineering of Embedded Real-Time Systems, pages 297–307. Springer, 2011. [5] S. Farfeleder, T. Moser, A. Krall, T. Stalhane, H. Zojer, and C. Panis. Dodt: Increasing requirements formalism using domain ontologies for improved embedded systems development. In Design and Diagnostics of Electronic Circuits & Systems (DDECS), 2011 IEEE 14th International Symposium on, pages 271–274. IEEE, 2011. [6] ISO. ISO26262. Road vehicles - Functional safety. International Standard, 2011. [7] E.-Y. Kang, E. P. Enoiu, R. Marinescu, C. Seceleanu, P.-Y. Schobbens, and P. Pettersson. A methodology for formal analysis and verification of EAST-ADL models. Reliability Engineering & System Safety, 120:127–138, 2013. [8] S. Konrad and B. H. Cheng. Real-time specification patterns. In Proceedings of the 27th international conference on Software engineering, pages 372–381. ACM, 2005. [9] MAENAD. Project website. http://www.maenad.eu. [10] MBAT. Project website. https://www.mbat-artemis.eu. [11] A. Post, I. Menzel, J. Hoenicke, and A. Podelski. Automotive behavioral requirements expressed in a specification pattern system: a case study at BOSCH. Requirements Engineering, 17(1):19–33, 2012. [12] SafeCer. Project website. http://www.safecer.eu.
[13] TIMMO-2-USE. Project website. http://www.timmo-2-use.org. [14] J. Westman, M. Nyberg, et al. A reference example on the specification of safety requirements using ISO 26262. In Proceedings of Workshop DECS (ERCIM/EWICS Workshop on Dependable Embedded and Cyber-physical Systems) of the 32nd International Conference on Computer Safety, Reliability and Security, 2013.
