Using Generic Software Components for Safety-Critical ...

Using Generic Software Components for Safety-CriticalEmbedded Systems – An Engineering Framework

Felix Braunling∗, Robert Hilbrich†, Simon Wegener‡, Isabella Stilkerich§, and Daniel Kastner‡

AbstractModern software development in the automotive do-main would be unthinkable without leveraging reusablesoftware components. Such generic software compo-nents have to be configured and tailored for each specifictarget application. Nowadays, complexity has reacheda point where developing generic software componentsand manually adapting each component for each variantin the product family is error-prone and no longer eco-nomically feasible. In this article we propose an engi-neering framework for automated adaptation of genericsoftware components which focuses on temporal andspatial integrity. The framework is built around ageneric methodology and leverages specialized softwaretools to determine an allocation of software componentsto the resources of an embedded system and to ensurememory integrity. We use a quadcopter example, ex-ecuted on the Infineon AURIXTM TC277 processor un-der the AUTOSAR operating system to illustrate our ap-proach.

1 IntroductionSafety-critical embedded systems represent a specialclass of computerized control systems. The interplayof their software and hardware parts realizes complexfunctions, such as engine control or vehicular guid-ance. Undetected errors in the implementation of afunction may jeopardize human lives, hence the addi-tional attribute safety-critical. Implementing the nec-essary software correctly, satisfying all safety require-ments and maximizing hardware resource utilization ina cost-sensitive and competitive market poses a sig-nificant challenge for established software engineeringmethods and tools.

A recent example for the increasing capabilities of mi-crocontrollers are embedded multicore processors con-taining multiple and possibly heterogeneous execution

∗Felix Braunling is with Method Park Engineering Gmbh, Ger-many [email protected]†Robert Hilbrich is with Deutsches Zentrum fur Luft- und Raum-

fahrt e.V. (DLR), Germany [email protected]‡Simon Wegener and Daniel Kastner are with Ab-

sInt Angewandte Informatik, Germany {swegener,kaestner}@absint.com§Isabella Stilkerich is with Schaeffler Technologies AG, Germany

[email protected]

units. In order to tap their potential and maximizeresource utilization, software components have to betightly integrated and optimized specifically for eachhardware platform. This optimization step is referredto as adaptation and often conducted manually.

With more software components sharing common re-sources of a microcontroller, ensuring their isolationagainst undesired interferences is essential in order tomaintain the reliability and safety of the system. There-fore, the adaptation needs to ensure isolation betweentightly integrated software components. This can beachieved by controlling access to both memory and CPUtime, thereby supporting error containment.

1.1 Problem StatementSoftware engineering for safety-critical embedded sys-tems is currently conducted in a “per-project” fashion.Depending on the setup of the system architecture indifferent projects, it may be necessary to distribute soft-ware components across a network of microcontrollersor to run them on different microcontroller derivatives.Unfortunately, due to the complexity and the lack ofproper engineering tools, software components are of-ten developed specifically to match the requirements ofa particular project. They are allocated manually tothe resources in the system’s hardware architecture andadapted manually to make best use of the capabilities ofthe microcontrollers. Especially for safety-critical sys-tems, ensuring an isolated execution of software com-ponents requires additional configuration and analysissteps which are specific to the microcontroller and thusoften conducted manually as well.

While the “per-project” approach may be sufficientfor a small number of projects, it still requires a lotof manual effort and reduces the reusability of soft-ware components. With more and more control func-tions in safety-critical devices being implemented insoftware, the need for reusability and adaptability fordifferent hardware platforms increases, which rendersthe “per-project” approach no longer economically sus-tainable. The question arises, how software componentsfor safety-critical embedded systems can be developedin a generic and reusable way, so that they can be used inmultiple projects, but without reducing resource utiliza-tion or jeopardizing their isolation properties and mem-ory safety.

1

1.2 General Approach

The authors argue that the level of reusability can besignificantly improved with a model-based developmentof generic software components in combination with anautomated adaptation toolkit to handle project-specifichardware properties and safety requirements.

In general, software components are concerned withthe implementation of specific features of the system.By using abstraction layers, they can be developed ina platform agnostic manner and organized as a libraryof generic software components for later use in mul-tiple projects. As a result of adopting a formalizedand model-based development approach, these genericfunctions can be automatically tailored and adapted tothe specific requirements of a project. In particular,this approach facilitates automated software deploymentin combination with automated platform-specific codegeneration as well as automated configuration and vali-dation of isolation properties. This “feature-based” soft-ware development is not entirely new [3, 5]. However,the authors believe that the state of practice and the ca-pabilities of available tools for this purpose have notyet reached the level of maturity needed for the devel-opment of multi-platform safety-critical embedded sys-tems.

1.3 Contribution

In this paper, the authors present the results of the de-velopment of an engineering framework aiding systemarchitects and software engineers. Software for embed-ded systems relies on mature development tools in or-der to cope with complexity and to satisfy all (safety)requirements. Therefore, the framework combines andextends the tools ASSIST, Astree and cAMP. By provid-ing interoperability between these tools and enhancingthem with new functionality, the framework is able toautomate the integration and tailoring of applications insafety-critical embedded systems (i.e., automated adap-tation).

In its current state, the framework provides an earlyand significantly less error-prone evaluation of timingand memory-partitioning decisions at the system level,the software level and also the implementation level.Combining these tools as a framework allows to au-tomatically adapt and integrate generic software com-ponents in order to create project-specific applicationsrunning on project-specific microcontrollers. Project-specific topics, such as the properties of a particularmicrocontroller, as well as spatial and/or temporal iso-lation requirements are also taken into account. By tak-ing advantage of code generation, the framework sup-ports an automated development process, thus buildingthe missing link between generic libraries of softwarecomponents and project-specific applications.

2 Conceptual OverviewFigure 1 depicts the simplified workflow of our frame-work. It is based on the idea of a strictly top-down en-gineering approach combined with the correctness byconstruction methodology [8] and supports the engineerby automating the synthesis and validation of crucial en-gineering artifacts.

Based on a model of the functional architecture, thesystems engineer creates a model of the envisionedsystem architecture. This model contains a selectionof generic software components from a library and aproject-specific hardware platform. The feasibility ofthe chosen hardware platform with respect to the tech-nical and safety-related requirements of the particularproject can be automatically validated by constructing adeployment for the selected software components (seeSection 6). If a valid deployment cannot be found, ei-ther the hardware platform or the selection of softwarecomponents need to be modified. Then, sound seman-tic code analysis is applied to all software code to en-sure sufficient isolation and memory protection, both ofwhich are essential to ensure the correctness of the sys-tem (see Section 7). Finally, data and code of softwarecomponents are automatically mapped to the isolationpartitions of their microcontroller (see Section 8).

The essential parts of the framework are described inmore detail in the next sections. However, this paper isnot intended to provide a thorough and detailed descrip-tion for each of the tools used in the framework. Insteadit focuses on their contribution for an automated devel-opment process based on generic software components.

3 I4CopterTo illustrate our approach, we will use the I4Copterflight controller as an overarching example. TheI4Copter is a research project developing a quadcopteras an example for hard real-time systems and controlsystems [37, 36]. While the quadcopter software wasoriginally meant to be deployed to a single-core In-fineon TriCore TC1796, we used the AURIX TC277for this paper, which is a three-core automotive micro-controller. The control software of the I4Copter con-sists of six modules: a digital signal processor (DSP) forreading sensor and remote inputs, a two-stage controller,and three observers. All these modules are responsiblefor controlling the positioning of the quadcopter dur-ing take-off, flight and landing. Further details of theI4Copter and the targeted hardware will be given in thefollowing sections to describe their relevance to the pre-sented framework. The example system resembles con-trol systems similar to those used in automotive chassissystems in complexity and size. The AURIX TC277was selected because it is a widely used microcontrollerin the automotive domain. It also provides heteroge-neous memories and computation units which allow fora flexible and adaptive deployment of software based on

Alle Rechte vorbehalten für Schaeffler Technologies AG & Co. KG, insbesonderefür den Fall einer Schutzrechtserteilung.

Presentation title 103/15/2019

Project-agnosticconstruction kit

Hardware Platform

Basic Software Libraries

Model Based ApplicationPlatform

Project-specificrequirements

Functional Architecture

System Specification

Temporal and SpatialIsolation

ASSIST:Designing the System

Deployment

Scheduling

Astrée:Analyzing the System

Type- and Memory Safety

Concurrency Defects

Data Flow and Access Behavior

cAMP:Integrating the System

Data Partitioning

Memory Protection

Memory Mapping

Project-specificApplication

Figure 1: Simplified Workflow

the product’s requirements, which makes it a suitabletarget platform for a software platform driven develop-ment approach.

4 Platform DevelopmentIn order to develop application software components ina reusable and structured way, the state of practice insystems engineering [20] recommends to start with afunctional architecture. It is constructed as a result ofa rigorous requirements engineering process and its re-lationship to other system views [27].

The functional architecture is tightly bound to the log-ical intentions and dependencies of the software appli-cations. It is a special kind of abstraction and usually, itdoes not include details of the technical architecture.

The separation into a functional and a technical archi-tecture allows for a separation of concerns between theproblem domain and the variations of possible technicalsolutions. This approach allows to construct applica-tions and infrastructure software independently, becauseimplementations on both ends can be developed sepa-rately as long as they comply with the “contract” of thecommon interface.

In our case, this can be described by using the bridgepattern, which is depicted in Figure 2. The bridge pat-tern is intended to decouple the abstraction from its im-plementation [12]. A functional element describes anabstract function. A technical implementation on theother hand is a tangible implementation providing thefunctionality described by the functional element. Thefunctional element does not need to know about the tan-gible implementation, thus the technical implementa-tion can be replaced by other solutions as long as allproject-specific requirements are met. Still, the func-tional and technical view are not fully independent ofeach other, because changes in either view may havesignificant effects on the other.

One example for a functional element in the I4Coptersoftware is the filter used to reduce noise from sensorinputs. A technical implementation to provide the func-tionality could be an alpha-beta-filter, a running averagefilter or a Kalman filter. Their software modules mustprovide a common interface to make the filter imple-mentations exchangeable. The choice of the filtering al-

gorithm can be controlled by changing which module islinked during compile time into the application code.

In each project, it is the task of the systems engineer toselect the suitable building blocks for each functional el-ement, i.e., generic software components from a libraryas well as hardware components (microcontrollers), inorder to create the system architecture model. Of course,the model needs to fulfill the requirements set forth inthe functional architecture.

5 System ArchitectureAt the core of our approach is a system architecturemodel. There are several notations available to modela system architecture, for example SysML, UML, orAMALTHEA [15], which allows to express safety- andtiming-related requirements as well-defined first-classmodel elements.

Generally speaking, the system architecture modelcomprises of a description of the software componentswith their distinct resource requirements, a descriptionof the available hardware resources, such as microcon-trollers or memory, and also constraints, in particularsafety requirements, that restrict the resource usage andallocation of software components.

Examples for safety requirements can be the need todetect sporadic hardware defects in the computation of asoftware component, heterogeneous hardware executionenvironments or the use of additional hardware for errorcorrecting/detecting codes. These requirements trans-late to constraints on the system architecture and thusare limiting the solution space of the architecture.

<<Functional Element>>Noise Filter

Technical Implementation

filter()

<<Technical Implementation>>Filter Construction Kit

filterNoise()

Running Average

filterNoise()

Alpha-Beta Filter

filterNoise()

Kalman Filter

filterNoise()

Figure 2: The relation between the functional elementsand the technical implementation exhibits the bridgepattern.

6 DeploymentWith the system architecture model being available, themapping between software components and hardwareresources is constructed in the next step. The construc-tion needs to consider the capacities of all available re-sources, e.g., the size of flash memory. It must also en-sure that the additional constraints (temporal and spatialisolation) are satisfied. This is achieved by construct-ing a feasible mapping and a static periodic schedulefor all software components. Due to the complexity ofthe solution space and the importance of the correctnessof the solution, this process is conducted in an auto-mated fashion with the tool ASSIST [13]. The chal-lenge of finding a correct mapping and a feasible staticschedule is addressed by transformation of this prob-lem into an equivalent constraint-satisfaction problemand the subsequent application of constraint program-ming [10, 4, 31]. Similar approaches for safety-criticalsystems have been published [14, 32].

Constraint programming refers to a set of techniquesin operations research, discrete optimization, and ar-tificial intelligence. These techniques assist in find-ing solutions for problems based on variables, whichare affected by constraints (constraint-satisfaction prob-lems). Each variable has a finite integer domain andevery constraint defines valid or invalid solutions fora subset of these variables. Solutions for this prob-lem class can be obtained by applying a combination ofsearch techniques—including backtracking—and con-straint propagation techniques for value elimination.ASSIST automates this process and hides the intrica-cies of a formal specification from the user by offeringa user-friendly domain specific language to describe themapping and scheduling problem.

Hardware {/* ... */Processor Processor1 {Manufacturer = "Infineon";Type = "TC277";Provides 32768 of exclusive feature "LMU RAM";Provides 4194304 of exclusive feature "PMU Program Flash";Core Core0 {

Capacity = 100;Architecture = "TriCore 1.6 P";Provides shared feature "Performance";Provides shared feature "FPU";Provides 16384 of exclusive feature "I-Cache";Provides 8192 of exclusive feature "D-Cache";

}Core Core1 {

/* identical to Core0 */}Core Core2 {

Capacity = 60;Architecture = "TriCore 1.6 E";Provides shared feature "Efficiency";Provides shared feature "FPU";Provides shared feature "Lockstep";Provides 8192 of exclusive feature "I-Cache";Provides 128 of exclusive feature "DMI Readbuffer";

}}

}

Figure 3: Hardware Specification in ASSIST

In contrast to other approaches [29, 30], which arebased on the composition of components with rich in-terfaces, ASSIST works on a higher abstraction leveland treats mapping and scheduling as separate steps inorder to reduce the size of the problem in each step. Forthis purpose, the modeling of component properties in

Software {Application OS_Application_0 {Task T1_Controllers { CoreUtilization = 2; }

}Application OS_Application_1 {

Task T3_AttitudeObserver { CoreUtilization = 20; }}Application OS_Application_2 {

Task T2_EngineController {CoreUtilization = 2;Requires shared Core feature "Lockstep";

}}Application OS_Application_3 {

Task T4_HeightObserver { CoreUtilization = 20; }}Application OS_Application_4 {

Task T6_DSP { CoreUtilization = 3; }}Application OS_Application_5 {

Task T5_AltitudeObserver { CoreUtilization = 20; }}

}

Figure 4: Applications and Tasks in ASSIST

ASSIST is less detailed. Software tasks are consideredto be “black boxes” with annotated resource require-ments. ASSIST also aims to simplify the complexityof the scheduling problem, by constructing a schedul-ing for a single hyperperiod containing periodic execu-tions of all tasks. Internally, ASSIST uses the CHOCOSOLVER [28], which has been successfully applied in awide variety of scheduling problems.

Figure 3 contains the specification of the hard-ware properties of the Infineon AURIX TC277 micro-controller. ASSIST allows to specify features, such asan FPU, as well as capacities, for example flash mem-ory, to constrain the deployment process.

The specification of the software architecture is pre-sented in Figure 4. It consists of six applicationstogether with their tasks. For the sake of simplic-ity and readability of the example, each task only re-quires a certain amount of the processor time (calledCoreUtilization in the specification). The core uti-lization is determined by the task’s worst-case executiontime (WCET) divided by the task’s period. Safe upperbounds on the WCET can be calculated, e.g., by aiTWCET Analyzer [18] for timing-predictable processorssuch as the AURIX TC277. On non-timing-predictablemulti-core processors, WCET estimates can be providedby hybrid WCET analyzers such as TimeWeaver [19].The task T2 EngineController shows how particu-lar features of a processing core can be required by atask.

Figure 5 shows the dependencies between the dif-ferent tasks which are present for a single period ofthe cyclic tasks of the I4Copter system. The tasksT4 HeightObserver and T5 AltitudeObserver

could be run in parallel to exploit the resources of theTC277 multicore processor.

Figure 5: Task Dependency Graph

In order to allow a parallel execution of these twotasks, they should be deployed to separate cores. How-

TaskGraph {T6_DSP -> T3_AttitudeObserver;T3_AttitudeObserver -> T4_HeightObserver, T5_AltitudeObserver;T4_HeightObserver -> T1_Controllers;T5_AltitudeObserver -> T1_Controllers;T1_Controllers -> T2_EngineController;

}

Figure 6: Task Graph Specification in ASSIST

Restrictions {T6_DSP, T3_AttitudeObserver dislocal up to Core;T6_DSP, T4_HeightObserver dislocal up to Core;

}

Figure 7: Mapping Constraint Specification in ASSIST

ever, this does not constitute a hard constraint for the de-ployment synthesis, because a deployment of these tasksto the same core may still be feasible, but less desir-able. Therefore, ASSIST needs to treat the informationabout the parallel execution of T4 HeightObserver

and T5 AltitudeObserver as a hint for achieving anoptimized solution. For this purpose, a task graph canbe specified in ASSIST, which allows the tool to auto-matically determine which tasks could be run in parallelin order to derive the optimization hints for the deploy-ment. The specification of the task graph for the exam-ple of this paper is contained in Figure 6.

In contrast to the “soft” optimization hints, thereare also “hard” deployment constraints, such as safety-related constraints, which affect the feasibility and va-lidity of the results. These constraints must be satisfiedin order to obtain a valid deployment. For the exam-ple use case, two additional safety requirements are as-sumed to ensure reliability despite potentially harsh en-vironmental conditions.

1. The tasks T6 DSP and T3 AttitudeObserver

must not share the same core.

2. The tasks T6 DSP and T4 HeightOberserver

must not share the same core.

Figure 7 shows how these requirements can be ex-pressed as “hard” mapping constraints in ASSIST.

Based on the deployment specification described inthe listings above, ASSIST was able to determine allvalid deployment solutions. There are 208 different so-lutions, which were computed in about 250 ms on a reg-ular desktop computer. In order to find the “best” so-lutions among the set of valid solutions, ASSIST al-lows to apply a set of metrics to each deployment.Those metrics allow to compute a score for each solu-tion, which reflects the fulfillment of the optimizationgoals reflected in the metrics. Solutions with the highestscores are therefore assumed to be the “best” solutions.

Figure 8: Evaluation of Solutions

For the example use case, two optimization goals forthe deployment of the application tasks where pursued.

Most important is the achievement of parallel execu-tion of tasks by the deployment. Therefore, solutionsshould be ranked higher, if parallel tasks in the taskgraph are indeed mapped to different cores. Further-more, mapping solutions with a uniform core load arepreferred over solutions with a heterogeneous load. Fig-ure 8 shows the selection of these metrics in ASSIST.Setting the Weight of the Max parallelism metric to thevalue of two allows to express the importance of thefirst goal in comparison to the second optimization goal.The automated evaluation with the aforementioned met-rics identified two solutions with the highest score, fromwhich we selected one (see Figure 10).

As a last step, an AUTOSAR-OS configuration file isgenerated by ASSIST, which constitutes a central engi-neering artifact for the following steps in our engineer-ing framework.

7 Static Analysis of OS Configura-tion and Source Code

This section addresses the prerequisites for an auto-mated low-level deployment of code and data in order toprovide the memory handling and memory protection.

7.1 AUTOSAR-OS System ModelAUTOSAR is a partnership between different automo-tive manufacturers to design a standard for an embed-ded automotive operating system. Currently there aretwo versions of the standard, the AUTOSAR Classicfor static systems and AUTOSAR Adaptive for dynamicsystems. In this paper we only refer to the AUTOSARClassic family of operating systems. The AUTOSARsystem model is depicted in Figure 9.

The system is structured around OS-Applications thatare executed on one specific computing unit of the un-derlying hardware. OS-Applications manages instruc-tions and data in memory as an execution environ-ment for one or more tasks. The tasks themselvesare schedulable execution units, each with its own dataand stack segment. By using hardware-based mem-ory access protection, such as a memory protectionunit (MPU), the kernel memory can be spatially iso-lated from OS-Applications. The same mechanismsalso allows for spatial isolation of OS-Applications fromother OS-Applications, as well as of tasks inside of OS-Applications. This is indicated by the thick black linesin Figure 9

The static structure of an AUTOSAR system, con-sisting of the mapping of cores, OS-Applications, tasksand memory protection regions as well as schedules andtimer events, is described in a configuration file. Theso called ARXML files are written in an AUTOSAR-standardized XML format. Based on this file operat-ing systems implementing the AUTOSAR standard cangenerate operating system code reflecting the configu-ration described in the ARXML file. Such an ARXML

trustedapplication

Data

non-trustedapplication

kernel

non-trustedapplication

Task A

DataDataData

CodeCodeCode

Code

Task B Task C Task D

Data DataData

Data

Stack

Stack Stack Stack

kernel protection

control-flow isolation

application isolation

TCB

Figure 9: AUTOSAR Isolation Schemes

file is the output of ASSIST, which in turn can then beused by Astree for a semantic analysis of the operatingsystem and the application code.

7.2 Ensuring Memory and Type SafetyDespite the successful deployment of all software com-ponents, memory and type safety need to be addressedin order to ensure spatial isolation between all tightlyintegrated software components. Memory safety in thescope of the C programming language is defined as theabsence of memory accesses that trigger undefined be-havior, as well as the absence of data races where sharedvariables are accessed by concurrent threads withoutproper synchronization. Although the C programminglanguage itself does not ensure memory safety, a soundstatic analysis of the C source code is able to guaranteememory safety at the programming language level.

Table 1: Mapping of Requirements of Type- and Mem-ory Safety [2] to Astree Alarm Types [1].

Requirement Alarm TypeOperations only applied for Invalid pointer comparisoninstances of correct type Subtraction of invalid pointers

Attempt to write to a constantDereference of mis-aligned pointerOverflow of Integers or FloatInvalid shift argumentUse of uninitialized variablesDivision or modulo by zeroUndefined integer moduloInvalid function callsUnsynchronized access to shared data

Access only existing objects Dereference of null or invalid pointerPointer to invalid or null functionUse of dangling pointerArithmetics on invalid pointersPossible overflow upon dereference

Access only inside object Incorrect field dereferenceboundaries Out-of-bound array access

Dereference of mis-aligned pointerPossible overflow upon dereference

In our framework we use the Astree analyzer [17,24]. Its main purpose is to report program defectscaused by unspecified and undefined behaviors accord-ing to the C99 standard. The reported code defectsinclude integer/floating-point division by zero, out-of-

bounds array indexing, erroneous pointer manipulationand dereferencing (buffer overflows, null pointer deref-erencing, dangling pointers, etc.), data races, lock/un-lock problems, and deadlocks. To deal with concurrencydefects, Astree implements a low-level concurrent se-mantics [23] which provides a scalable sound abstrac-tion covering all possible thread interleavings. The an-alyzer takes task priorities into account and, for multi-core systems, the mapping of tasks to applications andcores. Table 1 shows the relation between memory andtype safety and the defects found by Astree. Astree iswidely used in safety-critical systems, and provides thenecessary tool qualification support, including Qualifi-cation Support Kits and Qualification Software Life Cy-cle Data reports.

The AUTOSAR-OS configuration file produced byASSIST during the high-level deployment is parsed byAstree to automatically generate a matching analysisconfiguration that models the asynchronous executionof the various tasks and ISRs. Astree returns a list ofpotential code defects. An analysis resulting in zeroalarms guarantees the absence of memory safety vio-lations in the C source code. Since the C semanticsassumes unlimited stack space, the source-level analy-sis needs to be complemented by a sound static stack-usage analysis at the binary level to prove the absence ofstack overflows [16]. Moreover, using a formally veri-fied compiler ensures that no memory safety defects areintroduced by miscompilation [21]. Together, these ap-proaches are able to prevent software-induced memorycorruption, hence establishing memory safety.

Besides reporting runtime errors and concurrency de-fects, Astree also produces detailed data and controlflow reports. Soundness provides a guarantee that nei-ther control flow paths nor read or write accesses aremissed, even in case of data or function pointer accesses,or task interference. Global data and control flow anal-ysis gives a summary of variable accesses and functioninvocations throughout program execution.

Figure 10: Deployment solution found by ASSIST

Table 2: Excerpt from Astree Data Flow ReportVariable Function Access Process Data Races Shared ClassIn_altCtr_AccZ_g_altObs_noiseVariance TASK_T1_Controllers write T1 Controllers no no process localIn_altCtr_AccZ_g_altObs_processVariance TASK_T1_Controllers write T1 Controllers no no process localOut_accX_g_dsp_noiseVariance TASK_T3_AttitudeObserver read T3 AttitudeObserver yes yes globalOut_accX_g_dsp_noiseVariance TASK_T6_DSP write T6 DSP yes yes globalOut_accX_g_dsp_processVariance TASK_T3_AttitudeObserver read T3 AttitudeObserver yes yes globalOut_accX_g_dsp_processVariance TASK_T6_DSP write T6 DSP yes yes globalOut_torqueX_NM_attCtr TASK_T2_EngineController read T2 EngineController yes yes core localOut_torqueX_NM_attCtr STEP_AttitudeController write T1 Controllers yes yes core localOut_torqueX_NM_engCtr TASK_T3_AttitudeObserver read T3 AttitudeObserver yes yes core local. . . . . . . . . . . . . . . . . . . . .

The reports also contain each effectively shared vari-able, the list of tasks accessing it, the application andthe core to which the task has been assigned, and thetypes of the accesses (read, write, read/write). Indirectvariable accesses via pointers as well as function pointercall targets are fully taken into account. Filtering allowsdetermining the control and data flow per software com-ponent, thus supporting the analysis of data and controlcoupling as required by DO-178C. An excerpt from thedata flow report for the example system is shown in Ta-ble 2. Note that Astree detects data races for each ofthe shared variables in our example system, which isexpected, because the code does not contain any syn-chronization mechanisms.

8 Memory MappingAfter the definition of the system, the deployment ofall software components, and the analysis for memorysafety, the next step constitutes the low-level mappingof all instructions and their data to the physical mem-ories of the specific microcontroller. This step is alsocalled binding.

8.1 Heterogeneous MemoryThis task is especially important for multicore proces-sors with heterogeneous memories, such as the AURIXTC277, in order to achieve good runtime behavioras well as spatial isolation for freedom from inter-ference. The AURIX TC277 offers six core-coupledSRAMs for data (DSPR) and instructions (PSPR), anon-volatile flash memory (PMU) and a bus-accessedSRAM (LMU). It is possible to access any of the mem-ories from any of the cores using the microcontroller’sbus. However, read and write operations to the core-coupled SRAM take only one CPU cycle if they origi-

nate from the coupled core, whereas memory accessesvia the bus take more time. Moreover, accesses via thebus have less deterministic access times because of in-terference due to concurrent bus accesses. The flashmemory is also equipped with error correction capabili-ties to ensure data integrity.

8.2 Data and Function ClassesAt the same time, data and functions exhibit traits suchas origin of access, type of access, frequency of ac-cess, and logical traits such as being constant or used forin-system calibration. The combination of these proper-ties favors the binding of each data item or function toa different memory of the microcontroller. Data itemsand functions that exhibit similar traits can be groupedto variable and function classes, each with a set of pre-ferred memories dictated by a binding policy. In theI4Copter example two orthogonal types of classifica-tion exists: task-wise and core-wise. Task-local dataand functions are only accessed by a single task whereastask-global data is accessed by two or more tasks. Anal-ogous to this, core-local data and functions are onlyaccessed from a single core, while core-global dataand functions are shared between different cores. Con-stant data items are grouped into different classes, astheir read-only property makes them suitable for bindingthem to the flash memory and relying on core-coupledcache memories to reduce access times.

8.3 Binding PolicyBinding policies describe to which memory a particulardata item or functions should be mapped, depending onboth the properties exhibited by the available memoriesas well as the variable and function classes.

An example for such a policy is the mapping oftask-local, core-local data to the core-coupled SRAM

to achieve the fastest access time. Another policy isthat task-global, core-global data is mapped to the core-coupled memory of the core from which most accessesare originating. As the capacity of these memories isfinite, it needs to be decided which data and functionsare bound first. This can be done by optimizing policies,ranging from a very simple one based on the total accessfrequency, using different weights for read and write op-erations, to complex optimization algorithms using ei-ther constraint solving problems or integer linear pro-gramming.

In the I4Copter example presented in this paper, dataitems are sorted by the total amount of reads and writesto these data items. The access frequencies are deter-mined by taking the amount of read and writes reportedby Astree multiplied by the amount of task activationsduring one hyperperiod (9 ms) of the system. Data itemswith a higher count of total accesses are mapped first.

8.4 Automated Memory MappingGathering the information about data and function traits,combining it into classes and then creating a mappingto hardware memories is not feasible if done manuallyin systems of arbitrary complexity. The cAMP tool ad-dresses this problem by automatically generating a map-ping of instructions and data to memories. For this,all available information from the previous developmentsteps is used: deployment information from ASSIST bytaking into account the deployment solution describedin the generated ARXML file. Information about dataand functions traits can be extracted from Astree by tak-ing into account the data flow report (see Table 2). Fi-nally, also the requirements from the system specifica-tion such as task times, safety requirements and con-straints are taken into account.

The information is aggregated within cAMP and usedto generate a binding of data and functions to memories,as well as assigning MPU-enforced memory protectionregions to each used section of memory. The bindingis performed by following the binding policies for theselected hardware. The result of this process is a linkerscript that describes the memory mapping and exposesthe sections needed to configure the system’s MPU.

To reduce the amount of effort necessary to use thelinker script, i.e., the assignment of individual variablesand functions to the various memory sections, cAMP isable to interface with code generation tools to automati-cally include the necessary annotations in the generatedcode. In its current form, cAMP is able to interface withTargetLink, a widely used C code generator for Mat-Lab/Simulink.

The use of cAMP allows the automatic tailoring ofapplications to specific hardware and memory layoutsby creating a reproducible binding process. Usingcode generation and platform-based development addsfurther benefits, such as automatic code adaption andreusable binding policies. The automatic binding of

data and code results in a significant reduction of soft-ware development time, while being less error-pronethan manual binding.

9 Related WorkThe basic idea for our framework is inspired by KESOand program families presented by Parnas [26]. Parnaswas one of the first to give thought to program fami-lies and software-product lines (SPL). He described theproblem in the context of operating systems. Buildingon his ideas, later approaches examined the variabilitychallenge in large software systems. For instance, Sin-cero et al. [34] investigated the Linux kernel and treatedit as an SPL through configuration analyses. Liebig etal. [22] looked at configurable software composed inC and explored ways to deal with the complexity in-duced through preprocessor directives. There are alsosolutions (e.g., [11, 33]), which use generative program-ming [9] to create program variants from configurabil-ity models. Another project that leverages the idea ofprogram families is an operating-system constructionkit called PURE [6]. The authors define a base setof reusable OS-infrastructure components (e.g., threads,scheduling, concurrency, interruptions or memory ser-vice) needed to build infrastructure services. For in-stance, light-weight threads that can be used to com-pose address spaces and processes. The authors em-ploy a configuration- and code-generation-based frame-work to create operating-system variants. Differentfrom these prior works, we allow to manipulate spa-tial and temporal isolation properties in an early designphase based on architecture- and code-analyzing tech-niques of reusable application parts that can also be de-veloped using model-based techniques.

The KESO Java Virtual Machine [35] provides anisolation concept that is similar to the process conceptfound in general-purpose operating systems. KESO fea-tures a compiler, which is able to produce a virtual ma-chine environment specialized for a particular applica-tion. Therefore, KESO adopts ideas from Parnas’ ap-proach. In the following, we describe the characteristicsof KESO that are relevant for our work. Spatial iso-lation ensures that control flows are only able to accessmemory of data regions belonging to the protection zone(called domain) in the context of which the control flowis being executed. Therefore, each piece of data can belogically assigned to exactly one domain. In Java, typesafety ensures that programs can only access memoryregions to which they were given an explicit reference;the type of the reference also determines in which waya program can access the memory region pointed to bythe reference. To achieve spatial isolation, the KESOcompiler enforces that a reference value is never presentin more than a single domain. Different from KESO,our applications are not developed in Java but using amodel-based technique in which the generated C codeis analyzed using abstract interpretation in order to cre-

ate memory-safe C code. We extended Astree to use in-formation on the AUTOSAR OS threading model to—amongst other things— be able to perform a flow- andcontext-sensitive analysis based on OS-Applications tobuild logical isolation zones that are enforced by mem-ory protection hardware.

The article [25] addresses problems similar to thoseaddressed by our work, but assumes a different commu-nication model. In contrast to AUTOSAR, which usesshared memory for communication between task, theircommunication model is based on Kahn Process Net-works, and the used operating system is based on a non-shared memory model. For spatial isolation, they relysolely on the use of the MPU to ensure dynamic faultcontainment. We, in contrast, use sound static analysisof the integrated source code to foster safety by con-struction and utilize the MPU as a safety net. Moreover,the high-level deployment is not part of their workflowbut assumed as an input.

10 ConclusionThe authors present the results of a joint research anddevelopment project towards an engineering frameworkfor using generic software components in safety-criticalembedded systems. The framework combines sev-eral tools, so that generic software components can beadapted to a particular microcontroller and analyzed formemory integrity. Common starting point is a model ofthe system architecture comprising of a system specifi-cation and a functional architecture. Additional infor-mation about the target hardware (microcontroller fam-ily) and a library of generic software components is con-sidered to be available as well. These specifications arepassed through different engineering tools and code an-alyzers via common exchange formats.

In particular, the tool suite ASSIST allows to generatesoftware allocations for the targeted hardware. By in-cluding timing constraints, it also allows to construct astatic schedule, thus ensuring the feasibility of the sys-tem design. This results in an operating system config-uration describing the spatial and temporal behavior ofall software components.

In combination with the generated application soft-ware, the C sources are examined with Astree. By re-moving memory and type defects found during the anal-ysis, memory integrity can be ensured at the C codelevel. Furthermore, information about data and functionaccess behavior is collected during the analysis step. Ina final step, this information is used by cAMP to per-form the low-level mapping of data and functions tophysical memories and protection regions.

The final result comprises of annotated applicationcode and a linker script describing the memory map-ping, which is guaranteed to satisfy all project-specificsafety requirements and to utilize the capabilities of themicrocontroller. The final results as well as the interme-diate work products can be found on GitHub [7]. Us-

ing this framework allows to adapt generic applicationsoftware for safety-critical systems in an efficient andautomated manner, so that software reusability can beachieved without reducing resource utilization or jeop-ardizing system safety.

ACKNOWLEDGMENTThis work was funded within the project ARAMiS IIby the German Federal Ministry for Education andResearch with the funding ID 01IS16025 and by theDeutsche Forschungsgemeinschaft (DFG) within theAORTA project with funding ID SCHR 603/9-1. Theresponsibility for the content remains with the authors.

References[1] AbsInt Angewandte Informatik GmbH. Safety Manual

for aiT, Astree, RuleChecker, StackAnalyzer, May 2018.

[2] M. Aiken, M. Fahndrich, C. Hawblitzel, G. Hunt, andJ. Larus. Deconstructing process isolation. In MSPC’06: 2006 W’shop on Memory System Performance andCorrectness, pages 1–10, New York, NY, USA, 2006.ACM.

[3] S. Apel and C. Kastner. An overview of feature-orientedsoftware development. Journal of Object Technology,8(5):49–84, 2009.

[4] K. R. Apt. Principles of constraint programming. Cam-bridge University Press, 2003.

[5] T. Berger, S. She, R. Lotufo, A. Wasowski, and K. Czar-necki. A study of variability models and languages inthe systems software domain. IEEE TOSE, 39(12):1611–1640, Dec 2013.

[6] D. Beuche, A. Guerrouat, H. Papajewski, W. Schroder-Preikschat, O. Spinczyk, and U. Spinczyk. The PUREfamily of object-oriented operating systems for deeplyembedded systems. In 2nd IEEE Int. Symp. on OO Real-Time Distributed Computing (ISORC ’99), pages 45–53,Washington, DC, USA, May 1999. IEEE.

[7] F. Braunling, R. Hilbrich, S. Wegener, I. Stilk-erich, and D. Kastner. Generic Software Tailor-ing Example. https://github.com/Gronner/GenericSoftwareTailoringExample.

[8] R. Chapman. Correctness by construction: a manifestofor high integrity software. In Proceedings of the 10thAustralian workshop on Safety critical systems and soft-ware - Volume 55, SCS ’05, pages 43–46, Darlinghurst,Australia, Australia, 2006. Australian Computer Society,Inc.

[9] K. Czarnecki, U. Eisenecker, R. Gluck, D. Vandevoorde,and T. Veldhuizen. Generative programming and ac-tive libraries. In M. Jazayeri, R. Loos, and D. Musser,editors, Generic Programming, volume 1766 of LNCS,pages 25–39. Springer, 2000.

[10] R. Dechter. Constraint Processing. Elsevier Science &Technology, 2003.

[11] C. Elsner, G. Botterweck, D. Lohmann, andW. Schroder-Preikschat. Variability in time – productline variability and evolution revisited. In 4th Int.

W’shop on Variability Modelling of Software-intensiveSystems (VAMOS ’10), number 37 in ICB ResearchReports, pages 131–138, Jan. 2010.

[12] E. Gamma. Design patterns: elements of reusableobject-oriented software. Pearson Education India,1995.

[13] R. Hilbrich and M. Behrisch. Experiences gained frommodeling and solving large mapping problems duringsystem design. In IEEE Systems Conference 2017, pages620–627, Februar 2017.

[14] R. Hilbrich and H.-J. Goltz. Model-based generation ofstatic schedules for safety critical multi-core systems inthe avionics domain. In Proceedings of the 4th Inter-national Workshop on Multicore Software Engineering,IWMSE ’11, pages 9–16, New York, NY, USA, 2011.ACM.

[15] R. Hottger, H. Mackamul, A. Sailer, J.-P. Steghofer, andJ. Tessmer. APP4MC: Application platform project formulti- and many-core systems. it - Information Technol-ogy, 59(5), jan 2017.

[16] D. Kastner and C. Ferdinand. Proving the Absence ofStack Overflows. In SAFECOMP ’14: Proceedings ofthe 33th International Conference on Computer Safety,Reliability and Security, volume 8666 of LNCS, pages202–213. Springer, September 2014.

[17] D. Kastner, A. Mine, L. Mauborgne, X. Rival, J. Feret,P. Cousot, A. Schmidt, H. Hille, S. Wilhelm, and C. Fer-dinand. Finding All Potential Runtime Errors and DataRaces in Automotive Software. In SAE World Congress2017. SAE International, 2017.

[18] D. Kastner, M. Pister, G. Gebhard, and C. Ferdinand. Re-liability of WCET Analysis. Embedded Real Time Soft-ware and Systems Congress ERTS 2, 2014.

[19] D. Kastner, M. Pister, S. Wegener, and C. Ferdinand.TimeWeaver: A Tool for Hybrid Worst-Case ExecutionTime Analysis. In S. Altmeyer, editor, 19th Interna-tional Workshop on Worst-Case Execution Time Analy-sis (WCET 2019), volume 72 of OpenAccess Series inInformatics (OASIcs), pages 1:1–1:11, Dagstuhl, Ger-many, 2019. Schloss Dagstuhl–Leibniz-Zentrum fuer In-formatik.

[20] A. Kossiakoff, W. Sweet, S. Seymour, and S. Biemer.Systems Engineering Principles and Practice. Wiley Se-ries in Systems Engineering and Management. Wiley,2011.

[21] X. Leroy, S. Blazy, D. Kastner, B. Schommer, M. Pis-ter, and C. Ferdinand. CompCert - A Formally VerifiedOptimizing Compiler. In ERTS 2016: Embedded RealTime Software and Systems, 8th European Congress,Toulouse, France, Jan. 2016. SEE.

[22] J. Liebig, S. Apel, C. Lengauer, C. Kastner, andM. Schulze. An analysis of the variability in fortypreprocessor-based software product lines. In 32nd Int.Conf. on Software Engineering (ICSE ’10), New York,NY, USA, 2010. ACM.

[23] A. Mine. Static analysis of run-time errors in embed-ded real-time parallel C programs. Logical Methods inComputer Science (LMCS), 8(26):63, Mar. 2012.

[24] A. Mine, L. Mauborgne, X. Rival, J. Feret, P. Cousot,D. Kastner, S. Wilhelm, and C. Ferdinand. Taking StaticAnalysis to the Next Level: Proving the Absence of Run-Time Errors and Data Races with Astree. EmbeddedReal Time Software and Systems Congress ERTS2, 2016.

[25] B. Pagano, C. Pasteur, and G. Siegel. A Model BasedSafety Critical Flow for the AURIX Multi-core Plat-form. In ERTS 2018, 9th European Congress on Em-bedded Real Time Software and Systems (ERTS 2018),Toulouse, France, Jan. 2018.

[26] D. L. Parnas. On the design and development of programfamilies. IEEE TOSE, SE-2(1):1–9, Mar. 1976.

[27] K. Pohl, H. Honninger, R. Achatz, and M. Broy, edi-tors. Model-Based Engineering of Embedded Systems:The SPES 2020 Methodology. Springer, 2012.

[28] C. Prud’homme, J.-G. Fages, and X. Lorca. Choco Doc-umentation. TASC, INRIA Rennes, LINA CNRS UMR6241, COSLING S.A.S., 2016.

[29] O. Rogovchenko and J. Malenfant. Composition andcompositionality in a component model for autonomousrobots. In Software Composition, pages 34–49. SpringerBerlin Heidelberg, 2010.

[30] O. Rogovchenko and J. Malenfant. Handling hardwareheterogeneity through rich interfaces in a componentmodel for autonomous robotics. In Simulation, Mod-eling, and Programming for Autonomous Robots, pages312–323. Springer Berlin Heidelberg, 2010.

[31] F. Rossi, P. van Beek, and T. Walsh, editors. Handbookof Constraint Programming. ELSEVIER SCIENCE &TECHNOLOGY, 2006.

[32] W. Schwitzer, R. Schneider, D. Reinhardt, and G. Hof-stetter. Tackling the Complexity of Timing-Relevant De-ployment Decisions in Multicore-Based Embedded Au-tomotive Software Systems. SAE Int. J. Passeng. Cars -Electron. Electr. Syst., 6(2):478–488, Apr. 2013.

[33] N. Siegmund, M. Rosenmuller, M. Kuhlemann,C. Kastner, S. Apel, and G. Saake. SPL Conqueror: To-ward optimization of non-functional properties in soft-ware product lines. Software Quality Journal, 20(3-4):487–517, 2012.

[34] J. Sincero, H. Schirmeier, W. Schroder-Preikschat, andO. Spinczyk. Is the Linux kernel a software product line?In F. van der Linden and B. Lundell, editors, Interna-tional Workshop on Open Source Software and ProductLines (SPLC-OSSPL 2007), 2007.

[35] M. Stilkerich, I. Thomm, C. Wawersich, andW. Schroder-Preikschat. Tailor-made JVMs forstatically configured embedded systems. Concur-rency and Computation: Practice and Experience,24(8):789–812, 2012.

[36] P. Ulbrich. The I4Copter project — Research plat-form for embedded and safety-critical system soft-ware. https://www4.cs.fau.de/Research/I4Copter/, visited 2012-07-20.

[37] P. Ulbrich, R. Kapitza, C. Harkort, R. Schmid, andW. Schroder-Preikschat. I4Copter: An adaptable andmodular quadrotor platform. In 26th ACM Symp. on Ap-plied Computing (SAC ’11), pages 380–396, New York,NY, USA, 2011. ACM.