Using Model-based Development for ISO26262 aligned

HSI Definition
Georg Macher, Harald Sporer, Eric Armengaud, Eugen Brenner, Christian
Kreiner

To cite this version:

Georg Macher, Harald Sporer, Eric Armengaud, Eugen Brenner, Christian Kreiner. Using Model-
based Development for ISO26262 aligned HSI Definition. CARS 2015 - Critical Automotive applica-
tions: Robustness & Safety, Sep 2015, Paris, France. �hal-01193034�

HAL Id: hal-01193034

https://hal.archives-ouvertes.fr/hal-01193034
Submitted on 4 Sep 2015

HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est

archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents
entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non,
lished or not. The documents may come from émanant des établissements d’enseignement et de
teaching and research institutions in France or recherche français ou étrangers, des laboratoires
abroad, or from public or private research centers. publics ou privés.
 Using Model-based Development for ISO26262
aligned HSI Definition
Georg Macher∗k ,Harald Sporer∗ , Eric Armengaudk , Eugen Brenner∗ and Christian Kreiner∗
∗ Institute
for Technical Informatics, Graz University of Technology, AUSTRIA
Email: {georg.macher, sporer, brenner, christian.kreiner}@tugraz.at

k AVLList GmbH, Graz, AUSTRIA

Email: {georg.macher, eric.armengaud}@avl.com

Abstract—The ISO 26262 safety standard for road vehicles, with the technical safety concept, which includes hardware
among other engineer standards, was established to provide components that are controlled by software and support the
guidance for the development of safety-critical systems. Providing software execution. ISO 26262 states the importance and es-
evidence of consistent, correct, and complete system specification
covering different work-products is crucial in this context. One of sentiality of the HSI specification by highlighting its definition
these required work-products is the hardware-software interface during the system design phase and its further refinement
(HSI) definition. The HSI definition is especially important since during hardware and software development phase [6]. The
it defines the interfaces between different engineering domains HSI document is the last development artifact of the system
(such as system development, HW development, and SW devel- development and the starting point for parallel development
opment). Model-based development (MBD) is the most promising
approach to support consistent description of the system under of hardware and software. The HSI definition thus requires
development in a structured way. This paper thus presents an mutual domain knowledge of hardware and software and
ISO 26262 aligned hardware-software interface definition tool is usually the result of a collective workshop of hardware,
approach which bidirectionally combines the versatility and in- software, and system experts. The HSI is the linkage between
tuitiveness of spreadsheet tools (such as Excel) and the properties different levels of development and is used to align topics rel-
of MDB tools (e.g. different views, levels of abstraction, central
source of information, and information reuse). The approach evant to both hardware and software development. Insufficient
presented is capable of defining an ISO 26262 compliant HSI definition of the HSI can cause several additional iteration
and enables automatic derivation of basic software configurations cycles and communication issues between development teams.
according to these interface definitions. Model-based development (MBD) supports the description of
Index Terms—model-based development, ISO 26262, the system under development in a more structured way, which
hardware-software interface.
enables different perspectives for different stakeholders, differ-
ent levels of abstraction and a central source of information,
I. I NTRODUCTION
moreover it also appears to be the best approach for handling
Electronic control units (ECU) have steadily increased in these HSI definition issues. Nevertheless, seamless model-
value on the vehicle market over the years. The range of based solutions have not been achieved so far, mainly due to
premium cars software implementations were close to 1 gi- inadequate tool-chain support (e.g. redundancy, inconsistency
gabyte code and were spread over more than 90 electronic and lack of automation), which hampers the MBD approach
control units (ECU) in 2009. By 2018 the cost of vehicle in tapping its full potential. This paper thus presents a tool
electronics is forecast to have risen to 30% of the overall approach for ISO 26262 aligned hardware-software interface
vehicle costs [5]. At the same time the higher degree of inte- definition. The approach presented combines the versatility
gration and the safety-criticality of the control application is and intuitiveness of spreadsheet tools (such as Excel) and
raising new challenges. Evidence of correctness of the different the properties of MDB tools (e.g. different views, levels of
applications and safety concepts must be guaranteed and the abstraction, central source of information, and information
increasing demands for safety and security require additional reuse) bidirectionally.
development efforts. Safety standards such as ISO 26262 [6]
for electrical and electronic systems for road vehicles have
been established to provide guidance during the development The document is organized as follows: The next section
of safety-critical systems. The standards provide a well-defined describes related works and the state of the art of hard-
safety lifecycle based on hazard identification and mitigation, ware/software interface definition. The III section provides a
and define a long list of work-products to be generated. One description of the proposed enhancement for HSI definition.
important work-product among the many that are defined here Section IV evaluates the presented approach with an automo-
is the hardware-software interface (HSI) definition. The HSI tive use case. Finally, the last section concludes this work with
specifies the hardware and software interactions in consistency an overview of what has been achieved.
 II. S TATE - OF - THE -A RT HSI D EFINITION
Although the topic of defining hardware/software interface
definitions is of great importance for the automotive domain,
only few recent publications exist. King et. al [7] postulate
the problematic of defining HW/SW interfaces in early de-
velopment steps for of System on Chip (SoC)development.
First, a detailed interface is difficult to specify without detailed
knowledge of software and hardware. Second, these detailed
interfaces prevent a later migration of interface functionality
and addition of features.
In the automotive domain hardware and software develop-
ment cycle times differ significantly in length and software
development is typically separated into several abstraction lay-
ers (such as application software, microcontroller abstraction
layers, basic functionality drivers). This approach conceals
hardware specific details and enables the establishment of
focused software development teams (e.g., basic software de-
veloper, application software engineers, software integrators),
but on the other hand it sometimes obfuscates the importance
HSI development.
The AUTOSAR architectural approach [1] explicitly forces
an approach of this kind to support hardware independent
development of application software modules until a very late
Fig. 1. Conceptual Overview of the HSI Definition Approach
development phase. The AUTOSAR specifications intention
is to support exchange and reuse of software, by defining
software architectures, interfaces, and exchange formats and representation in a MDB tool(such as Enterprise Architect).
enable parallel working of application software developers, The spreadsheet tool and the MBD tool can be bidirectionally
basic software developers, and hardware developers. aligned via program-specific APIs, which supports the tool-
A comprehensive overview of hardware/software co-design independence of the approach presented.
methods and tools can be found in [9]. Teich’s work exploits An overview of the main parts of the contribution is shown
the synergies of hardware and software with focus on cost in Figure 1, the following sections describe each part in more
and performance constraints and highlights major research detail.
directions and achievements.
A. Application SW Modeling Framework
Contract-based design paradigms are an emerging domain-
independent paradigm for interface definition. The contracts The first part of the approach is a specific UML modeling
specify the input and output behavior of a component and framework developed to enable an AUTOSAR-like repre-
provide a guaranteed behavior [3]. Such an approach can sentation of software architecture designs within the system
be used for software component safety contracts [8] as well development tool (Enterprise Architect). The UML profile
as contract-based embedded system development [4]. These takes advantage of the AUTOSAR virtual function bus (VFB)
contract-based approaches foster model-based development abstraction layer and enables an explicit definition of AU-
and traceability of development decisions. Nevertheless, this TOSAR components, component interfaces, and connections
approach is not simple and easy enough to be used of HSI between interfaces. The AUTOSAR-aligned representation can
definition workshops. Because of its simplicity and easy to be linked to system development artifacts and requirement
use nature many hardware/software interface definitions are representations, which eases the traceability between these
still done within spreadsheet tools or in textual form within a different types of development artifacts. These explicit links
requirement management tool. Although Chen et. al [2] claim can further be used for automated constraints checking and
that social and text-based communication does not scale for ease the confirmability of development decisions (e.g. for
the handling of future embedded automotive systems and their safety case generation). This provides the possibility to define
advanced interface definition constraints. software architecture and ensures a proper definition of the
communication between the architecture artifacts, including
III. T HE HSI D EFINITION A PPROACH interface specifications (e.g. upper limits, initial values, for-
The HSI definition tool presented in this work allows the mulas).
definition of ISO 26262 aligned hardware-software interfaces Figure 2 shows the EA model profile for the modeling of
in a practicable and intuitive way in a spreadsheet tool (such the software module (AUTOSAR composition) and its signal
as Excel). The tool presented enables the transformation of interface definitions. As can be seen in the figure, software
these HSI definitions in a reusable and version-able model modules contain a declaration of their related ASIL and a
 Fig. 2. EA Model for Modeling of Software Architectures

characteristic declaration. This characteristic determines the

module either as a hierarchical composition or an atomic
software module, which comprises additional benefits for SW
allocation and analysis. The ASIL assignment supports the
work of safety engineers by adding values and visual labels
for safety-relevant software modules. The port configuration
artifact (lower part of figure 2) implies the definition of the
interface specification and enables the automatic generation
of interfaces to BSW modules. The model representation of
Fig. 3. EA Model for Modeling of Information of BSW and HW Represen-
SW architectures and module interfaces in the MBD tool tation
enables constraint checking features and supports traces to HSI
definition and requirements.
means for reuse by multiple programs and ensures MDB-
B. Basic SW and HW Module Modeling Framework tool independence of the exporter respectively of the specific
spreadsheet tool.
To also model basic software (BSW) and hardware module The HSI spreadsheet importer is the HSI exporter’s coun-
representations additional model artifacts are defined. These terpart. Also implemented as a dll class library using the
representations are assigned to establish links from ASW spreadsheet tools API it enables the import of information and
modules to the underlying basic software and hardware layers. selective update of HW/SW interface model artifacts, which
Thereby the hardware profile enables an intuitive graphical enables round-trip engineering between spreadsheet and MDB
way of establishing hardware-software interfaces (HSI) and tool HSI representations. Common spreadsheet file extensions
linking of SW signals of BSW modules to HW port pins (such as .csv or .xls) are importable, which correspond to the
via dedicated mappings. Figure 3 depicts the HW and BSW generic structure of the spreadsheet template.
artifacts required to complete HSI model representation. The
BSW module representation is shown in the upper part of the D. Spreadsheet Template
picture, this enables the modeling of interfaces between ASW
The spreadsheet template defines the structure of the data
and BSW layer (runtime environment). The second artifact
representation in a generic, project-specific and customizable
is a representation of HW pins with a listing of the possible
way. This ensures the practicable and intuitive method of en-
pin configurations. HSI configurations of the HW pin can be
gineering HSI definitions with spreadsheet tools. Additionally,
modeled using the third artifact.
the machine- and human-readable notation of spreadsheets
enables the transformation of this information to a reusable and
C. HSI Definition Exporter and Importer
version-able representation in the MDB tool. This approach
The HSI exporter MBD-tool extension establishes a links thus unifies the project-dependent process of HSI definitions
to the spreadsheet tool via API calls and enables the export of across the variety of different projects and contributing part-
modeled HW/SW interfaces to spreadsheet documents (.csv ners without requiring exactly the same development tools or
or .xls files). The MBD-tool extension is developed in form processes to be in place which ensures a cost- and time-saving
of a dll class library and via API links, which provides alternative to what are usually complex special-purpose tools.
 TABLE I V. C ONCLUSION
A DDITIONAL FEATURES PROVIDED BY THE APPROACH AND NUMBER OF
EMERGES FOR THE BMS USE - CASE This paper presented a tool approach for ISO 26262 aligned
hardware/software interface definition. The approach combines
the versatility and intuitiveness of spreadsheet tools (such
Provided features Number of emerges for BMS as Excel) and the properties of MDB tools (e.g. different
use-case views, levels of abstraction, central source of information, and
information reuse) and does so in a bidirectional manner. This,
extracted settings to Excel 437
enables a practicable, tool-independent, and intuitive method
consistency checks of ASW 54
signal mappings of engineering HSI definitions with spreadsheet tools and
transformation of the generated information into a reusable and
modeled ASW artifacts 10 modules + 86 signal ports
version able model representation. The machine- and human-
modeled BSW artifacts 7 modules + 38 signal ports
readable notation of spreadsheets ensures a cost- and time-
modeled HW/SW interface ar- 19 HW pins + 19 pin configu-
saving alternative to what are usually complex special-purpose
tifacts rations
tools (such as AUTOSAR tools). Furthermore, the capability
generated LoC for ASW/BSW 33
mapping of the approach for defining an ISO 26262 compliant HSI
and automatic derivation of basic software configurations
according to these interface definitions has been evaluated with
a brief BMS use-case.
E. SW/SW Interface Generator
The SW/SW interface generator generates .c and .h files ACKNOWLEDGMENT
defining SW/SW interfaces between application software sig- The authors would like to acknowledge the financial support
nals and basic software signals from the modeled HSI arti- of the ”COMET K2 - Competence Centers for Excellent
facts. This eliminates the need of manual SW/SW interface Technologies Programme” of the Austrian Federal Ministry for
generation without adequate syntax and semantic support and Transport, Innovation and Technology (BMVIT), the Austrian
ensures reproducibility and traceability of these configurations. Federal Ministry of Economy, Family and Youth (BMWFJ),
This generator is another dll class library based MBD tool ex- the Austrian Research Promotion Agency (FFG), the Province
tension, which can also be implemented by other frameworks of Styria, and the Styrian Business Promotion Agency (SFG).
or reused by other tools. We are grateful for the contribution of the SOQRATES Safety
AK experts and the expertise gained in SafEUr professional
IV. E VALUATION OF THE HSI D EFINITION A PPROACH trainings. Furthermore, we would like to express our thanks
For evaluation of the approach an automotive use-case of to our supporting project partners, AVL List GmbH, Virtual
a central control unit (CCU) in a battery management system Vehicle Research Center, and Graz University of Technology.
(BMS) prototype for (hybrid) electric vehicle has been chosen.
R EFERENCES
Project-specific details have been abstracted for reasons of
commercial sensitivity. The CCU SW architecture of the use- [1] AUTOSAR development cooperation. AUTOSAR AUTomotive Open
System ARchitecture, 2009.
case consists of 10 SW modules on ASW layer and 7 SW [2] DeJiu Chen, Rolf Johansson, Henrik Loenn, Yiannis Papadopoulos,
modules on BSW layer. The ASW modules count 54 inputs Anders Sandberg, Fredrik Toerner, and Martin Toerngren. Modelling
and 32 outputs, which define 48 SW/SW interfaces on ASW Support for Design of Safety-Critical Automotive Embedded Systems.
In SAFECOMP 2008, pages 72 – 85, 2008.
layer and 19 interfaces to BSW and HW connections. [3] A. Cimatti and S. Tonetta. A Property-Based Proof System for Contract-
This adds up to more than 30 lines of code (LoC) for Based Design. In Software Engineering and Advanced Applications
HW/SW interface definition, which can be generated automat- (SEAA), 2012 38th EUROMICRO Conference on, pages 21–28, Sept
2012.
ically into interface.c and interface.h files with the approach [4] W. Damm, H. Hungar, B. Josko, T. Peikenkamp, and I. Stierand. Using
presented. Consistency checks for the 32 output interfaces and contract-based component specifications for virtual integration testing and
54 input interfaces on the ASW layer can ensure point-to- architecture design. In Design, Automation Test in Europe Conference
Exhibition (DATE), 2011, pages 1–6, March 2011.
point consistency of these signal routings. This adds up to [5] Christof Ebert and Capers Jones. Embedded Software: Facts, Figures,
774 definitions, for 9 definable features per signal, which are and Future. IEEE Computer Society, 0018-9162/09:42–52, 2009.
automatically checked for consistency with this approach. [6] ISO - International Organization for Standardization. ISO 26262 Road
vehicles Functional Safety Part 1-10, 2011.
The HW/SW interface mapping consists of 19 interfaces [7] Myron King, Nirav Dave, and Arvind. Automatic Generation of Hard-
for this specific SW architecture. The mappings include 23 ware/Software Interfaces. In Proceedings of the Seventeenth International
settings per pin, which can be automatically exported into a Conference on Architectural Support for Programming Languages and
Operating Systems, ASPLOS XVII, pages 325–336, New York, NY, USA,
spreadsheet and kept consistent with the model-representation 2012. ACM.
via the importer functionality. This ensures actuality of depen- [8] A. Soderberg and R. Johansson. Safety contract based design of software
dent development artifacts and simplifies tracing of develop- components. In Software Reliability Engineering Workshops (ISSREW),
2013 IEEE International Symposium on, pages 365–370, Nov 2013.
ment decisions. [9] Juergen Teich. Hardware/Software Codesign: The Past, the Present, and
Table I sums up the additional features provided by the Predicting the Future. Proceedings of the IEEE, 100(Special Centennial
presented approach for the BMS use-case. Issue):1411–1430, May 2012.