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 form of expression for use in architecture descrip- tions.”
The next two sections will propose some ADLs for hardware engineering and safety engineering. We choose to use a UML- based ADLs. Therefore, each ADL is implemented using a UML profile.
2.2 Hardware engineering ADLs Using concepts of ISO/IEC/IEEE 42010, Fig. 2 shows the stakeholders and concerns (a), ADLs (b), and viewpoints (c) that we propose for hardware engineering.
(b)
(a)
(c) Fig. 2. Stakeholder and concerns, ADLs, viewpoints for hardware engineering 4 The ADLs in Fig. 2 are actually extensions of standards, like SysML, with specific properties necessary for the project. For sake of simplicity, we do not present the extensions in this paper. Let us focus on the viewpoints of hardware engineering. To simplify the description of the viewpoints, we have omitted their long list of model kinds. The model kinds are UML and SysML diagrams and tables, which are listed in their respective standards. The model kinds have been graphically customized for the viewpoints to describe ADL elements associated with the viewpoints.
─ Hardware Requirement Analysis: Concerns the specification and analysis of Hardware Requirement. As ADL, we propose to use an extension of SysML for hardware requirements modeling specific to the project. ─ Hardware System Design: Concerns the design of the Hardware System that can be used for early Hardware Ar- chitecture Exploration. As ADL, we propose to use MARTE, a UML profile for real-time embedded systems with ste- reotypes for hardware modeling. ─ Hardware Architecture Exploration: Concerns the design of evaluators for Hardware Architecture Explo- ration. As ADL, we propose to use the SysML profile’s parametric model for mathematical modeling. The mathematical models serve the purpose of evaluating a criteria for the architecture exploration. ─ Hardware IP Design: Concerns design of a Hardware IP as specification of its interfaces. As ADL, we propose to use UML_IPXACT profile. This profile is reversed from the XSDs of the IEEE 1685-2014 IP-XACT standard. ─ TLM Design: Concerns Transactional Level Modeling (TLM). As ADL, we propose to use the OMG-standard UML profile for SystemC. For readability, this profile is called UML_SystemC in this paper. ─ RTL Design: Concerns Register Transfer Level (RTL). As ADL, we propose to use the UML_VHDL profile we proposed for low level VHDL modeling.
2.3 Safety engineering ADLs
In our methodology, there is only one Safety Engineering concern associated with one stakeholder, the Safety Ana- lyst. The ADLs are UML profiles associated with safety analysis methods. Each has its own viewpoint: ─ Safety Requirement Analysis: This ADL of this viewpoint describes a taxonomy of safety requirements compatible with ISO26262 and proposes an extended list of requirement properties. ─ HARA: The ADL of this viewpoint describes the safety concepts related to Hazard Analysis and Risk Assessment (HARA) from ISO26262. ─ FMEA: The ADL of this viewpoint describes safety concepts related to Failure Mode and Effect Analysis (FMEA), criticality FMEA, and diagnostic FMEA. ─ FTA: The ADL of this viewpoint describes safety concepts related to qualitative and quantitative Fault Tree Analysis (FTA). ─ Formal Safety Property Verification (abbr. FSPV for the rest): The ADL of this viewpoint describes safety concepts related to system dysfunctional behavior (Failure State, Failure Event, Failure Transition, etc.) and property verification expressed in CTL logic. The use of this ADL allows model translation to SMV language for further formal analysis with NuSMV tool. The next section shows how the ADLs for hardware and safety engineering can be integrated into a hardware/safety co- engineering method.
3 Hardware/safety co-engineering method
In this section, we describe our method for compositional hardware development and safety analysis compatible with ISO26262. Then we propose how to use the viewpoints of the ADLs for hardware and safety engineering at each step of the given method.
3.1 Hardware development and safety analysis co-engineering method ISO 26262 proposes a “reference phase model for the product development at the hardware level” in [16]. There may exist work-product dependencies between steps recommended by ISO 26262, which can slow down the hardware development. Therefore an innovative and efficient way to implement the ISO 26262 recommendations is to parallelize steps when possible. The proposed method is shown in Fig. 3. The inputs for this method are system description (requirements, functional and system architecture, etc.) and safety analysis results (from HARA, FTA, FMEA, etc…) obtained at the prior phases of system development life-cycle such as concept definition and product development at the system level. The method shows how to 5 conduct safety analysis from the early steps of hardware development. In Fig. 3 there are two processes running in parallel, the hardware development process highlighted in white, and the safety process highlighted in green. The advantage of such an approach is that safety steps do not block hardware development steps.
Fig. 3. Proposed hardware/safety co-engineering method
In order to harmonize our co-engineering method with ISO26262, we map its main steps to the clauses of the standard. Therefore in Fig. 3, the steps are prefixed with the appropriate clauses from ISO 26262 (e.g. 5.7.4.1 is corresponding to clause 7.4.1 of part 5 of ISO26262). The proposed co-engineering method contains the following steps:
5.5 Initiation of product development at the HW level. In this step, we determine and plan the functional safety activities during the individual steps of hardware development. 5.6 HW requirements & 5.6 HW safety requirements. During these steps, the design and safety requirements of the hardware system are specified and analyzed by hardware engineer and safety engineer respectively. These two steps re- fer to the clause 5.6 of ISO26262. 5.7.4.1 HW architecture design & HW system safety analysis. The hardware system architecture is speci- fied. This architecture is then annotated with safety artifacts defining failure modes, its causes and effects, as well as hard- ware dysfunctional behavior. Once the architecture is extended with safety artifacts, the preliminary hardware system safety analysis is conducted. This analysis includes such semi-automated methods as FMEA, FTA and formal safety property veri- fication with NuSMV tool. 5.7.4.2 HW detailed design & 5.7.4.3 HW safety analysis: During the hardware detailed design, the hard- ware system is refined into a detailed design for implementation. This step corresponds to clause 5.7.4.2 of ISO26262. The preliminary safety analysis made in the previous step is extended during the hardware safety analysis according to the de- tailed specification of the hardware components. This step refers to clause 5.7.4.3 of ISO26262. In addition to the semi- automated FMEA and FTA, the manual analysis of safe, single and multiple-point faults should be conducted. The later identifies the safe, single- and multiple-point faults, provides the evidence of the effectiveness of safety mechanisms to avoid residual and latent faults, and gives their diagnostic coverage. 5.7.4.4 Verification of HW design & 5.7.4.4 Safety Verification of HW design. During these steps we verify that the hardware design for compliance and completeness with respect to the requirements, including the safety requirements. For the latter, verification is supported by safety analyses. These two steps refer to the clause 5.7.4.4 of ISO26262. 5.8 Evaluation of the hardware architectural metrics: See ISO 26262. 5.9 Evaluation of safety goal violations due to random HW failures: See ISO 26262. 5.10 HW integration: See ISO 26262. The proposed co-engineering method allows us to conduct our hardware development in parallel with safety analysis with respect to ISO26262. The next section shows which hardware engineering and safety engineering ADLs, given in Sections 2.2 and 2.3, are to be used at each step of the method proposed in this section. 6 3.2 Mapping between the proposed method and domain-specific ADLs Table 1 gives the mapping between steps defined by our hardware/safety co-engineering method and the viewpoints of our domain-specific ADLs, described in sections 2.2 and 2.3. In this paper, the mapping focuses on viewpoints because they are the main elements in our ADLs that answer the engineering concerns. So far our viewpoints for hardware engineering focus on the left branch of the V development cycle. Therefore only the left branch steps are mapped to viewpoints.
Table 1. Mapping of the proposed method to domain-specific ADLs’ viewpoints Proposed method [Fig. 3] Viewpoint [Fig. 2] HW development Safety analysis HW development Safety analysis 5.6 HW requirements Hardware Requirement Analysis 5.6 HW safety requirements Safety Requirement Analysis 5.7.4.1 HW architecture Hardware System Design, Hardware design Architecture Exploration HW system safety analysis Hardware System Design FMEA, FTA, FSPV 5.7.4.2 HW detailed Hardware IP Design, TLM Design, RTL design Design 5.7.4.3 HW safety analysis FMEA, FTA, FSPV 5.7.4.4 Verification of FMEA, FTA, FSPV HW design
The next section shows how the methodology, i.e. ADLs and co-engineering method, is implemented.
4 Tools of the methodology applied to the development of a motherboard
In this section the hardware development tools of the methodology are shown. Safety analysis tools are not presented be- cause, as a reminder, the project in its current stage lacks safety requirements and properties to conduct the analyses. The tooled methodology has been applied on a case-study: a very early motherboard architecture excerpted from the project. Due to confidentiality issues, we cannot show more detailed architectures of the IPs we develop. The goal of the case-study was to verify the applicability of the approach within the project, considering its challenges aforementioned in Section 1, and obtain early feedbacks from the engineers so methodology and tools can evolve by needs. Each of the following sections will present how some concerns in Fig. 2 are handled by the tooled methodology. In each of the next sections, this paper focuses on (1) an example of usage, (2) traceability and (3) feedbacks by CEA engineers.
4.1 Hardware Requirement
Fig. 4 (a) shows some hardware requirements. It is described with a Requirement Table associated with the Hardware Requirement Analysis viewpoint, itself associated with the SysML ADL. Fig. 4 (b) shows the requirement table exported to Excel. Excel values can also be pasted into the requirement table.
(a) (b) Fig. 4. Hardware requirement table and export to Excel (black boxes censor confidential information) 7 Traceability. SysML offers relationships to relate requirements among them. For example, a requirement can be derived from another re- quirement through the <
Feedback. Most of the feedbacks on the requirement viewpoint are on the tooling. CEA Engineers mostly appreciate the document generation functionalities: documents can be generated from the requirement diagrams and tables produced with the viewpoint. In particular, Excel interoperability is strong with the requirement tables, as the latter can be exported to Excel, while the for- mer can be copy-pasted directly into the requirement tables.
4.2 Hardware System
Fig. 5 shows a motherboard system described with a Component Structure Diagram, associated with the Hardware System Design viewpoint. The viewpoint itself is associated with the MARTE ADL.
Fig. 5. Motherboard hardware system model
For example, in Fig. 5 MARTE stereotypes <
Traceability. To trace hardware system model elements to requirements, stereotype <
Feedback. So far, such abstractions have been described with PowerPoint drawings. With a model, CEA engineers feel the mainte- nance is eased because when they “change some hardware component’s properties, the change is reflected in every diagram”. On the other hand, the lack of guideline in our methodology, that indicates the correct level of abstraction in the hardware system design viewpoint, is a problem for CEA engineers who are new to hardware system level modeling. MARTE has also not been fully exploited as CEA engineers have not filled its stereotype properties. Furthermore, as shown by the next section, exploitation of the model for architecture exploration does not automatically exploit MARTE properties.
4.3 Hardware Architecture Exploration
Fig. 6 shows a model to compute the boot power of the motherboard. The model is described in a Parametric Diagram, associated with the Hardware Architecture Exploration viewpoint, itself associated with the SysML ADL. In Fig. 6 (a), the MotherBoardBootPowerComputation part is typed with a class stereotyped <
(b)
(a) (c) Fig. 6. Motherboard boot power architecture exploration model
The specification of the values of the input parameters is modeled with instance specifications. There can be several in- stance specifications of the input parameters, thus defining several architecture candidates for architecture exploration. Tool- wise, the effective computation of the output parameter, through interpretation of the equation with a set of input parameters with specified values, is done by the Papyrus. Results are stored by creating a computed instance specification but with output parameters having values. The output parameters stored in the computed instance specification can be used as input parameters of other constraint blocks and so on. For example, Fig. 7 shows how instance specifications first let us first specify some input parameters of the CPU and FPGA to compute their output parameters cpuBootPower and fpgaBootPower respectively (the input parameters are summed in this example). These output parameters are stored in computed instance specifications of the CPU and FPGA (1055.0 mW and 1600.0 mW respectively). These computed instance specifications are used in the instance specification of the motherboard to specify its input parameters. We can then compute the output parameter motherboardBootPower (2655.0 mW).
Fig. 7. Motherboard boot power architecture exploration model (numerical values in mW)
Traceability. A set of instance specifications represents a parameterized candidate architecture. Through the SysML <
4.4 RTL Unifying a MARTE model with IP-XACT has been previously explored in [9]. Instead, let us focus on the UML-based RTL design and its relationship with the hardware system model in MARTE. In our methodology, VHDL models are described in Composite Structure Diagrams, associated with the RTL De- sign viewpoint, itself associated with the UML_VHDL ADL. The graphical model is inspired from graphical representations of VHDL code given by tools such as Xilinx Vivado. Fig. 8 (a) shows a VHDL model representing a entity that instantiates a multiplier and some registers. The UML_VHDL profile has stereotypes to model VHDL specificities such as port direction. In addition to the profile, there are UML model libraries representing standard VHDL packages. For example we offer the STD and IEEE model librar- ies. The UML_VHDL profile may also be used to model user VHDL packages. Top level hierarchy VHDL code is generated from the UML_VHDL model for all required entities of some composition. The library and use clauses of VHDL are automatically generated according to data types that are used in the model. For example, our model library IEEE::std_logic_1164 contains the std_logic data type. When this data type is used to specify a signal in the model, then library ieee; and use ieee.std_logic_1164.all are automatically generated in the code. Fig. 8 (b) shows the truncated generated VHDL code from the model in Fig. 8 (a). library IEEE; use std_logic_1164.all
entity pe is generic ( width_data_input: integer := 8); port ( rstn: in std_logic; -- [...] o_output_data: out std_logic_vector); end pe;
architecture rtl of pe is
signal sig_input_opA: std_logic_vector; -- [...]
Begin -- [...] mul: entity work.multiplier generic map( width => width_data_input); port map( o_negate => o_negate_flag, -- [...] o_value => sig_output_data); end rtl; (a) (b) Fig. 8. VHDL model and generated code
In this paper let us focus on the traceability of the generated code.
Traceability. The IP, hosted by the FpgaHostIp of the motherboard, is allocated its VHDL model. The <
Feedback. 10 CEA engineers have expressed that the benefits of VHDL modeling in UML and code generation is limited. Currently Xil- inx Vivado is used for VHDL. Vivado offers a graphical representation of the code, therefore the benefits of the graphical UML-based model is limited. Furthermore Vivado also offers some validations not available in our tool. Traceability benefits are also limited as CEA engineers feel that current Eclipse-based collaborative modeling tools “con- flict handling for stereotype properties [typed by UML data types] are too limited” to effectively apply our synchronization process proposed in [15]. As identified in [15], model-code synchronization, and its tooling, must thus be further explored to help the acceptance of UML-based graphical models for low level development.
5 Conclusion
In this paper we have proposed a hardware/safety co-engineering methodology based on: ─ UML-based ADLs, and their viewpoints, for hardware engineering and safety engineering ─ A hardware/safety co-engineering method, compatible with ISO 26262, which refers to hardware and safety domain specific ADLs and viewpoints ─ An implementation of the methodology as a same development environment, with open-source Papyrus-based MDE tools
By applying the methodology on an early motherboard case-study, we were able to gather early feedbacks from CEA engi- neers. Most feedbacks from CEA engineers concern the tools, rather than the methodology itself. CEA engineers are mostly satisfied with interoperability with existing tools for requirements. Architecture exploration at hardware system level also adds benefits to the modeling at this level of abstraction. On the other hand, there should be guidelines for bounding the hardware system level abstraction. The benefits of using our UML-based tools for RTL design are not evident as existing tools offer similar functionalities, while traceability through consistency is not well supported by current tools. In the future, as the project progresses, more data will be available to evaluate the safety analyses. We are also implement- ing Eclipse cheat sheets, as tooled guidelines, to apply our methodology for the safety analyses. In terms of hardware development, we will propose IP core libraries for some levels of architecture abstraction. By storing and then reusing IP cores, with different properties (e.g. time, area, power, performance), we can optimize our system and decrease time/cost needed for its development.
References 1. Object Management Group, UML profile for Schedulability, Performance and Time (SPT). 2. Object Management Group, MARTE specification. 3. Avionics Architecture Description Language Standards Document (AADL). 4. A. Alvarez, I. Ugarte, P. Martinez, V. Fernandez, HW-SW codesign of a positioning system. From UML to implementation case study, DCIS’16 5. M. Abdurohman, E. Ariyanto, System on Chip Design Methodology as Systematic Steps for Handling System on Chip Design Complexity Based on Hardware/Software Codesign, Advanced Science Letters, vol. 21:1, 2015. 6. Q. Zhu, R. Oishi and T. Hasegawa, T. Nakata, Integrating UML into SoC Design Process, DATE’05. 7. Riccobene, E. Scandurra, P. Rosti, A. Bocchio, A model-driven design environment for embedded systems, DATE’06. 8. T.G. Moreira, M.A. Wehrmeister, C.E. Pereira, J. Pétin, E. Levrat, Automatic code generation for embedded systems: From UML specifications to VHDL code, INDIN’10. 9. S. Révol, S. Taha, F. Terrier, A. Clouard, S. Gérard, A. Radermacher, and J. Dekeyser, Unifying HW Analysis and SoC Design Flows by Bridging Two Key Standards: UML and IP-XACT, IFIP Advances in Information and Communication Technology, vol. 271, 2008 10. T. Schattkowsky, T. Xie, W. Mueller, A UML Frontend for IP-XACT-based IP Management, DATE’09 11. Y. Wang, X.G. Zhou, B. Zhou, L. Liang and C.-L. Peng. A MDA based SoC Modeling Approach using UML and SystemC, CIT’06 12. T. Schattkowsky, J. Hendrik Hausmann, G. Engels. Using UML Activities for System-on-Chip Design and Synthesis, MODELS’06 13. Q. Zhu, R. Oishi and T. Hasegawa, T. Nakata, Integrating UML into SoC Design Process, DATE’05 14. W. Mueller, A. Rosti, S. Bocchio, E. Riccobene, P. Scandurra, W. Dehaene, Y. Vanderperren, UML for ESL design: basic principles, tools, and applica- tions, ICCAD’06 15. V.C. Pham, S. Li, A. Radermacher, S. Gérard, C. Mraidha, Fostering Software Architect and Programmer Collaboration, ICECCS’16 16. https://www.iso.org/standard/43464.html 17. http://www.iso-architecture.org/ieee-1471/cm/ 18. https://www.eclipse.org/papyrus/ 19. https://www.iso.org/standard/70939.html 20. https://www.amass-ecsel.eu/ 21. P. Cuenot, C. Ainhauser, N. Adler, F. Meurville. Applying Model Based Techniques for Early Safety Evaluation of an Automotive Architecture in Com- pliance with the ISO 26262 Standard, ERTS’14