Unifying safe hardware system design and implementation through UML-based architecture description languages Shuai Li, Yupanqui Munoz Julho, Nataliya Yakymets, Asma Charfi, Sébastien Gérard, Morayo Adedjouma, Chokri Mraidha, and Ansgar Radermacher CEA LIST, Paris-Saclay, France {first-name}.{last-name}@cea.fr Keywords: Hardware safety co-engineering, architecture description, ISO 26262, UML, SysML 1 Introduction The multiplication of stakeholders, with different non-orthogonal concerns, has increased the complexity of system develop- ment, and hardware engineering is no exception to the rule. In transport domains such as avionics, railway or automotive, with the advent of automated driving, systems are safety-critical as failures or hazardous decisions about the environment may lead to accidents that cause human lives. Because of the safety-criticality of such systems, hardware engineers are prone to follow safety standards and guidelines (e.g. ISO 26262 [16] and the future ISO 21448 [19] for road vehicles). The increased com- plexity of systems, and their new constraints, imposes to R&D teams, of different industries, to adopt new methodologies and their associated tools. Today there are many methodologies, languages, models, and mature tools for different low level concerns of hardware en- gineering. For example, electronic and SoC specification is well supported by IP-XACT tools, TLM level design is enabled by SystemC simulation, and RTL implementation can be done with HDL-based development and simulation tools. On the other hand, to our knowledge, the methodological and tool support for high level hardware system design is rather poor at the early stages of the development cycle. Such tasks are either omitted or done manually and heterogeneously. Con- sistency and traceability, between the hardware system model and implementations, are not supported. A tool like Matlab Sim- ulink offers a graphical mathematical modeling/simulation environment and transformations to IP-XACT and VHDL but it is usually used at the later stages of development. Several trends have explored using UML for hardware design. This generic but highly extensible language can be the ena- bler to provide methodologies for hardware system design and to bridge its gap with implementation models. Indeed, through its profile mechanism, UML can be extended for domain-specific needs. A UML profile has stereotypes, with attributes, that extend UML metamodel elements. Once a profile is applied on a UML model, its stereotypes can be applied on UML elements to give them new semantics. Standard UML profiles such as SPT [1], MARTE [2], and the one for AADL [3], provide some constructs to describe a functional hardware system. Such descriptions can be used for hardware/software co-design, for which UML-based methodologies have been proposed [4, 5]. For hardware domain-specific concerns, numerous UML profiles and modeling methods have been proposed for SoC design [6], SystemC [7], VHDL [8], and IP-XACT [9, 10]. Works in [11, 12, 13, 14] make use of UML techniques to describe electronic circuits. The mentioned works do propose methodologies and tools for designing safe hardware systems and ensuring the hardware system model’s consistency with implementations. Most works [6, 7, 8, 9, 11, 12, 13, 14] only use UML as a frontend for do- main-specific hardware languages like IP-XACT, VHDL, and SystemC. In this case they are not different from industrial ma- ture tools which already support the languages. Other works [1, 2, 3] only propose to model the hardware system as a high level functional model but do not consider exploiting it for implementation and maintaining consistency. Only [9] considers somewhat this issue, by unifying functional hardware system design (UML) and electronic system design (IP-XACT), but other lower level implementation models and code are not considered. Finally no aforementioned works propose a same framework that combines hardware engineering with requirements and safety engineering to help development follow safety standards such as ISO 26262. Even if there are some ongoing initiatives and projects working on safety certification platforms (e.g. the European AMASS initiative [20]), today there is a lack of tooled aid that covers a complete conformance to safety standards. Matlab Simulink supports ISO 26262 but, as mentioned, it is usually used at later stages of development. In the context of AUTOSAR and EAST-ADL, [21] proposes a methodology for early safety analysis to comply with ISO 26262. In terms of ISO 26262, in this 2 paper we focus less on the safety analysis aspects than the methodological issues, in order to ease integration of hardware and safety co-engineering into an initial framework we propose. Context of the work. The work presented in this paper is motivated by collaboration between CEA research institute and one of its automotive industrial partners. The goal of the project is to develop the electronic platform of the future for vehicles. The current distribut- ed architecture, with several Electronic Control Units (ECU), will be replaced with a more centralized architecture based on a motherboard and specialized devices (e.g. GPU) that may be connected according to the functionalities that are embedded. Within this project, most of the hardware, software, and network engineering work is done by engineers at CEA (we focus on hardware in this paper). Safety requirements are provided by experts from the industrial partner. Several challenges are faced by the engineers at CEA: (1) the (high level) architecture modeling and architecture exploration of hardware systems, (2) the traceability of requirements, design, and implementation, which is required by ISO 26262, (3) the lack of expertise on ISO 26262, and safety analysis aspects, from the development teams. To face such challenges, CEA propose to use previous experience and expertise in system and software design by Model- Driven Engineering (MDE) methods and tools. The idea is to propose a tooled methodology that, in theory, helps hardware engineers face their development challenges, and provide a safe-by-design development environment. The next paragraph lists the contributions of this paper to help with the abovementioned challenges, within the scope of the project. Contributions. In this paper we propose a methodology for the design of safety-critical automotive hardware systems. The methodology is implemented in a modeling platform offering a graphical development environment for hardware system design and imple- mentation. Our methodology is defined through the following contributions: ─ Architecture description languages (ADL) for safe hardware engineering, defining the stakeholders, concerns, viewpoints, and model kinds. Our ADLs follows loosely the conceptual model for architecture description as defined in the ISO/IEC/IEEE 42010 standard [17]. The standard defines the elements involved in architecture description and the require- ments to propose new ADLs and architecture frameworks. The advantage of the proposed architecture description is that it helps stakeholders focus on their concerns. ─ A generic hardware/safety co-engineering compositional development method compatible with ISO 26262 “product devel- opment at hardware level” clauses (part 5). This allows obtaining safe-by-design automotive systems by coupling develop- ment and safety processes. At the current stage of the project, safety requirements and properties are lacking. Thus we focus on the methodological issues and describe a method and a framework for further safety engineering works to be conducted as the project progresses. In our further works, we plan to validate the proposed method and its tool using the same case study of the project. ─ An implementation of our methodology with tools related to Papyrus [18], an open-source UML modeler. Feedbacks on the methodology and tools will be given by engineers working on the project. The rest of the paper is structured as follows. Section 2 describes the ADLs. Section 3 presents the hardware/safety co- engineering process. Section 4 shows the tools and a case-study. We conclude in Section 5 with future works. 2 ADLs for hardware and safety engineering In this section, first the concept of architecture description is explained. Afterwards we propose ADLs for hardware engineer- ing and for safety engineering. 2.1 Architecture description by ISO/IEC/IEEE 42010 An architecture description, as defined by the ISO/IEC/IEEE 42010 standard, is a “work product used to express an architec- ture”. Its goal is to standardize architecture description by defining standard terms and providing a conceptual foundation for expressing and exploiting architecture descriptions. In this paper, we propose ADLs for safety and hardware engineering, through the concepts of the ISO/IEC/IEEE 42010 standard. Such concepts are shown in Fig. 1 provided by the standard. 3 Fig. 1. ADL conceptual model from ISO/IEC/IEEE 42010 In Fig. 1, the conceptual model is done in UML and the concepts are defined as follows: ─ Stakeholder: “Stakeholders are individuals, groups or organizations holding Concerns for the System of Interest.” ─ Concern: “A Concern is any interest in the system.” ─ Architecture Viewpoint: “An architecture viewpoint is a set of conventions for constructing, interpreting, using and analyzing one type of architecture view.” ─ Model Kind: “A model kind defines the conventions for one type of architecture model.” ─ Architecture Description Language (ADL): “An ADL is any