Antonopoulos, Christos P.

Becker, Jürgen

Dörr, Tobias

Kelefouras, Vasilios

Keramidas, Georgios

Masing, Leonard

Mavropoulos, Michail

Schade, Florian

Voros, Nikolaos

English

KITopen

This work has been submitted to the IEEE for possible publication. Copyright may be transferred without notice, after which this version may no longer be accessible.Safety by Construction: Pattern-Based Applicationof Safety Mechanisms in XANDARTobias Dörr∗, Florian Schade∗, Leonard Masing∗, Jürgen Becker∗, Georgios Keramidas†,Christos P. Antonopoulos†, Michail Mavropoulos†, Vasilios Kelefouras†, Nikolaos Voros†∗Karlsruhe Institute of Technology (KIT), GermanyEmail: {tobias.doerr, juergen.becker}@kit.edu†University of Peloponnese, GreeceAbstract—Considering the design of safety-critical embeddedsystems for future mobility solutions, the XANDAR project em-ploys the X-by-Construction paradigm to meet non-functionalrequirements in an automated manner. This paper introducesthe pattern library concept developed as part of the projectand analyzes three state-of-the-art safety mechanisms for theircompatibility with the approach.Index Terms—X-by-Construction, model-based design, multi-processor system-on-chip, embedded software, safety.I. INTRODUCTIONEmbedded systems for technologies such as self-driving carsneed to combine a high computational performance with thefulfillment of safety, security, and real-time requirements [1].This turns the design of such systems into a complex taskand creates the need for systematic approaches to tackle theassociated challenges in a cost-efficient manner.In the XANDAR project, a holistic toolchain providingsuch approaches is developed [2]. The strategy employedto achieve this is based on the X-by-Construction (XbC)paradigm, i.e., a “step-wise refinement process from speci-fication to code” [3] that results in systems with guaranteednon-functional properties. The developed toolchain employs amodel-based methodology to cover functional correctness aswell as real-time, safety, and security requirements.Focusing on multiprocessor system-on-chip (MPSoC) de-vices, this work presents first results and future directionsof the XbC safety pattern concept in XANDAR. As part ofthis work, we introduce three selected safety patterns that weconsider particularly interesting for the MPSoC-based designof safety-critical systems.II. PROCESS AND PATTERN LIBRARYAs shown in Fig. 1, the XANDAR development processcan be divided into two overall portions: the model-basedfrontend and the XbC backend. In the frontend, users createa high-level description of the envisaged embedded system.During early development stages, the frontend is concernedonly with platform-independent aspects at the software level.In this case, it allows the user to describe the intended softwarearchitecture as a network of Software Components (SWCs)interacting according to the Logical Execution Time (LET)paradigm [4]. Provided with a software architecture modeland platform-independent code for each SWC, the toolchainó XbC pattern library Î SWC code¦ Architecture modeling Ò Generation framework MiLModel-based frontendXbC backendImplementation artifactsHW description, platform config-uration, executable binaries, ...AnnotationsmXbC guaranteescannot be givenToolchain provider input Toolchain user input Process stepRefinementand analysisFig. 1. High-level overview of the XANDAR development processis able to perform a deterministic model-in-the-loop simu-lation (MiL) of the specified behavior. In later developmentstages, platform-specific aspects can be incorporated into thearchitecture model. Triggering the XbC backend initiates arefinement procedure that attempts to generate implementationartifacts with guaranteed runtime properties. If the backend isunable to provide the expected guarantees, it requests the userto revise the architecture model or the SWC code.For the treatment of safety and security requirements, thetoolchain employs a pattern-based approach. As visualizedin Fig. 1, predefined XbC patterns are provided to the toolchainuser in the form of an extensible library. Each pattern capturesa specific safety or security mechanism, either known from thestate of the art or specifically developed by XANDAR. In anycase, a pattern consists of a verified design-time procedure and,optionally, trusted building blocks to be deployed to the targetruntime. Note that some patterns (such as a pattern enforcingthat two SWCs are mapped to distinct hardware units) do notgenerate active runtime entities. Such patterns do not triggerartifact generation, but their design-time steps still contributeto a safe and secure system architecture.The toolchain user has the opportunity to annotate librarypatterns to the created software architecture model. As shownin Fig. 2, a software architecture contains an arbitrary numberof SWCs, each with its LET parameters and an arbitrarynumber of input or output ports. Ports exhibit either samplingSoftwareArchitecture ChannelInstance<<interface>>PatternApplicationinitialize()<<sealed>>SwcPortdirection: PortDirectiondataType: DataTypescope: PortScopeSamplingPortQueuingPortcapacity: UIntSoftwareComponentruntime: Durationactivation: ActivationPatterncomponents [0..*]channels [0..*]patterns [0..*]ports [0..*]0..*source [1]0..1sink [1]Fig. 2. Excerpt of the software architecture metamodelor queuing behavior and can be connected to ports of oppositedirection via channel instances. From the perspective of thetoolchain itself, every pattern is provided as a class imple-menting the PatternApplication interface. The applicationof a pattern is therefore realized by the instantiation of therespective class. Using its initialize() method, a patternhas the opportunity to hook into the execution of both thegeneration framework and the XbC backend.III. SAFETY PATTERNS FOR MPSOCSHaving described the pattern library concept of XANDAR,we now present ideas on how to integrate three selected safetymechanisms from an MPSoC context into it.a) Hypervisor-based on-chip redundancy: An importanttarget runtime of XANDAR are type-1 hypervisors. In suchscenarios, SWCs mapped to a hypervisor partition can bereplicated to implement fault masking based on spatial redun-dancy. A pattern realizing this idea is a specific Triple Modu-lar Redundancy (TMR) scheme in which SWC copies as wellas a voter are automatically generated and deployed to dedi-cated partitions. The resulting implementation is comparableto the “arbiter sandbox” approach presented in [5]. From amodeling point of view, an application of this pattern needs toreference only the SWC to protect. Since fault masking doesnot affect the nominal functionality of the system, the patternhas no impact on the simulation. Therefore, the XbC backendalone is able to generate the required runtime artifacts.b) Cost-efficient fault tolerance: In cases where on-chipredundancy is not sufficient to obtain the necessary degree ofreliability, but a full replication of an MPSoC is prohibitivelyexpensive, the System-Level Simplex Architecture [6] is apromising concept to achieve fault tolerance. It is based ondynamic hardware redundancy and reacts to failures of oneplatform with the transition to a degraded functionality onanother, more reliable platform. Due to the dynamic natureof this mechanism, provisioning it as a safety pattern is morechallenging compared to the first case. An application of thispattern must reference two SWCs: one delivering the nominaland one delivering the degraded functionality. In addition,the fault detection procedure needs to be implemented bythe user (as part of a SWC) and its result must be madeavailable to the component orchestrating the pattern duringruntime (via a SWC port). The behavioral aspect of thispattern has to be handled by the generation framework tomake it visible in the simulation. The aforementioned runtimecomponent to orchestrate the dynamic behavior must be highlydependable and generated by the XbC backend.c) Hardware-enforced information flow control: To per-form a logical isolation of physically connected on-chip com-ponents, modern MPSoCs are often equipped with Access Pro-tection Units (APUs) attached to their internal interconnects.The work in [7] presents a model-based approach that usessuch APUs to enforce an end-to-end information flow policy ina network of MPSoCs. This methodology is highly compatiblewith the XANDAR process and can be packaged as a safetypattern in a straightforward manner: A pattern applicationmust contain a specification of all accepted information flowsat SWC level, i.e., a list of ordered pairs where each pairdeclares a flow from a source SWC to a sink SWC asaccepted. In the XbC backend, the pattern has to derive APUconfigurations from specified channel instances and, giventhese configurations, must ensure that all potentially feasibleinformation flows are in line with the list of accepted flows,i.e., the desired information flow policy.IV. CONCLUSIONIn this work, we have given an overview of the XANDARdesign methodology and its XbC pattern library. We were ableto show that representative safety mechanisms from the stateof the art are compatible with the library concept. While thesoftware architecture metamodel is final, the pattern libraryis currently under development and will be populated withimplementations of safety patterns such as the ones describedabove over the remaining course of the project.ACKNOWLEDGMENTThis work is part of a project that has received funding fromthe European Union’s Horizon 2020 research and innovationprogramme under grant agreement No 957210.REFERENCES[1] R. Ernst, “Automated Driving: The Cyber-Physical Perspective,” Com-puter, vol. 51, no. 9, pp. 76–79, Sep. 2018.[2] L. Masing, T. Dörr, F. Schade, J. Becker et al., “XANDAR: Ex-ploiting the X-by-Construction Paradigm in Model-based Developmentof Safety-critical Systems,” in Design, Automation & Test in EuropeConference & Exhibition (DATE ’22), Mar. 2022.[3] M. H. ter Beek, L. Cleophas, I. Schaefer, and B. W. Watson,“X-by-Construction,” in Leveraging Applications of Formal Methods,Verification and Validation: Modeling, T. Margaria and B. Steffen, Eds.Springer International Publishing, 2018, vol. 11244, pp. 359–364.[4] T. A. Henzinger, B. Horowitz, and C. M. Kirsch, “Embedded ControlSystems Development with Giotto,” SIGPLAN Not., vol. 36, no. 8, pp.64–72, Aug. 2001.[5] E. Missimer and R. West, “Distributed Real-Time Fault Tolerance ona Virtualized Multi-Core System,” in Operating Systems Platforms forEmbedded Real-Time applications (OSPERT ’14), Jul. 2014.[6] S. Bak, D. K. Chivukula, O. Adekunle, M. Sun, M. Caccamo, andL. Sha, “The System-Level Simplex Architecture for Improved Real-TimeEmbedded System Safety,” in 15th IEEE Real-Time and EmbeddedTechnology and Applications Symposium (RTAS ’09), Apr. 2009.[7] T. Dörr, T. Sandmann, and J. Becker, “Model-based configuration ofaccess protection units for multicore processors in embedded systems,”Microprocessors and Microsystems, vol. 87, Nov. 2021.

Safety by Construction: Pattern-Based Application of Safety Mechanisms in XANDAR

https://publikationen.bibliothek.kit.edu/1000153442/149759157

Safety by Construction: Pattern-Based Application of Safety Mechanisms in XANDAR

Abstract

Similar works

Full text

Available Versions

KITopen