safety critical rtos - high integrity systems...an rtos is a software component that rapidly...

HighIntegritySystems

Email: [email protected]: www.highintegritysystems.com

WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600

v

Safety Critical RTOSAdapting Across ApplicationsIssue 1.1 - February 26, 2019

This document was prepared by WITTENSTEIN aerospace & simulation ltd for the Embedded World Conference 2019, date as document, all rights reserved.




Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.

Contents...........................................................................................................................................2List Of Figures.................................................................................................................................3List Of Notation...............................................................................................................................3

CHAPTER 1 Introduction...................................................................................................4-51.1 Introduction..............................................................................................................................41.2 The RTOS................................................................................................................................51.3 AdaptingtheRTOSfordifferentprocessor/compilers................................................................5

CHAPTER 2 Functional Safety.........................................................................................6-92.1 Safety Design Standards.........................................................................................................62.2 Adapting the RTOS for Functional Safety.................................................................................72.3 AdaptingtheRTOStodifferentSafetyDesignStandards.........................................................72.4 SupportingDifferentCompilers................................................................................................82.4 Creating a new Functional Safety RTOS port...........................................................................9

CHAPTER3 FunctionalSafetyComponents..................................................................103.1 ScopeofaFunctionalSafetyComponent..............................................................................103.2 CreatingasafetycriticalembeddedplatformfromFunctionalSafetyComponents.................10

CHAPTER 4 Functional Safety RTOS Architecture Considerations.........................11-134.1 Creating a Mixed SIL Software Architecture........................................................................11 4.2 Controlling Access to the Processor’s Resources...................................................................124.3 Multicore Support...................................................................................................................13

CHAPTER 5 Conclusion & References...........................................................................14 5.1 Conclusion........................................................................................................................14 5.2 Reference List........................................................................................................................14

ContactInformation.....................................................................................................................15

Contents





List of Figures

Figure 1 Typical internal structure of an RTOS.................................................................................5Figure 2 Industry Design Standards.................................................................................................6Figure3AnexampleofanembeddedsoftwareSafetyCriticalDevelopmentLifecycle.....................8Figure 4 Building Mixed SIL Software Applications..........................................................................11Figure 5 Architecture of a Gate Keeper Task...................................................................................12

List of Notation

BSP Board Support PackageCOTSCommercialoff-the-shelfDAP Design Assurance PackDHF Design History FileMCU Microcontroller UnitMPU MemoryProtectionUnitMMU MemoryManagementUnitRTOSRealTimeOperatingSystemSIL Safety Integrity LevelSOUP Software of Unknown Provenance




1.1 IntroductionWithevery newupdate,microprocessors increase inpower and features.Anunfortunate sideeffect is the increase incomplexity,requiringthedevelopertoreadandunderstandlargeramountsofinformation.Insafetycriticalapplicationsthiscomplexityposesasignificantrisk.Howdoesthedesignerknowwhethertheyhavecoveredalleventualities?

Oneapproachistosplitthedesignbetweentheembeddedplatformandtheapplication.Theembeddedplatformtypicallyincludesthemicroprocessor,aRealTimeOperatingSystemcommonlyreferredtoasanRTOS,thedrivers,middleware,andlowlevelverificationroutines.Theembeddedplatformencapsulatesandabstractsthedeeplyembeddedengineeringaspectsawayfromtheapplication.Theapplicationthenonlyneedstofocusonthefunctionalandsafetyrequirementsoftheoverallsystem.

It is becoming increasingly popular to tackle complexity by constructing the embedded platform from FunctionalSafetyComponents -acommonsolutionbeing tomakeuseofaFunctionalSafetymicroprocessor.Often this typeofmicroprocessor issupportedbyFunctionalSafetysoftware libraries implementingbuilt-in test functionality.AFunctionalSafetyRTOScanbeusedtoscheduletheindividualtestsrequiredbythemicroprocessor,andallowtheapplicationaccessto themicroprocessor’s resources.TheRTOSnormallyprovides the isolationbetweensafetyandnon-safety functions,allowingamixofdifferentsafetyintegritylevelsoftwarewithinasinglebuild.

Oncethedeveloperissatisfiedwiththesafetyofthedesign,theymustdemonstratethecompletenessofthedesigntoaCertificationBody,andshowthattheembeddedplatformmeetstherigorousdemandsofawiderangeofinternationalsafety design standards.

TheFunctionalSafetyRTOS isakeycomponentofmosthigh integritysoftwarearchitectures,withmanycorporationschoosingtoselectasinglesafeRTOSacrosstheirentireorganization.ThiswhitepaperexamineshowaFunctionalSafetyRTOScanbeadaptedtomeettherequirementsofapplicationsindifferentverticalmarketsectors,withdifferenttechnologyrequirements. It also investigates the challenges embedded developers face when building safety critical embeddedplatformsfromFunctionalSafetyComponents.Issuesdiscussedwithinthiswhitepaperinclude:

• AdaptingtheRTOSforusewithdifferenttechnology;• AdaptingtheRTOStosatisfydifferentsafetydesignstandards;• BuildingasoftwarearchitecturefromFunctionalSafetyComponents;• Functional Safety RTOS architecture considerations.

ThiswhitepaperfocusesonthedevelopmentanduseofaFunctionalSafetyRTOS,howeverthetopicsdiscussedcanequallybeappliedtoanyembeddedsoftwarecomponentthatrequiresfunctionalsafetycertification.

CHAPTER 1 Introduction & RTOS Basics




1.2 The RTOS AnRTOSisasoftwarecomponentthatrapidlyswitchesbetweenTasks,givingtheimpressionthatmultipleprogramsarebeingexecutedatthesametimeonasingleprocessingcore.ThedifferencebetweenanOperatingSystem(OS)suchasWindowsorLinuxandanRTOS,istheresponsetimetoexternalevents.OSstypicallyprovideanon-deterministic,softrealtimeresponse,wheretherearenoguaranteesastowheneachTaskwillcomplete,buttheywilltrytostayresponsivetotheuser.AnRTOSdiffersinthatittypicallyprovidesaharderrealtimeresponse,providingquickerreactiontoexternalevents.

When switching between Tasks, the RTOS has to choose themost appropriate Task to load next. There are severalschedulingalgorithmsavailable,includingroundrobin,cooperativeandhybridscheduling.However,toprovidearesponsivesystemmostRTOSsuseapre-emptiveschedulingalgorithm.

Inapre-emptivesystemeachTask isgivenan individualpriorityvalue.Thefastertherequiredresponse,thehigherthepriority levelassigned.Whenworking inpre-emptivemode,theTaskchosentoexecute isthehighestpriorityTaskthatisabletoexecute.Thisresultsinahighlyresponsivesystem.TheRTOSwillsupportawell-definedAPI,whichallowsthecreationofTasks,andprovidesaccesstofeaturesthatenablecommunicationandsynchronizationbetweenTasks,andTasksandISRs,suchasQueues,Messages,Semaphores,andMutexesetc.

1.3 AdaptingtheRTOSfordifferentprocessor/compilers

RTOSportsarecreatedforspecificprocessor/compilerconfigurations.Typically,theRTOSdesign,Fig.1,willconsistoftwodistinctlayers,aCoreLayerthatcontainsthemajorityoftheRTOSfunctionalityandimplementstheRTOSAPI,andaPortableLayer.ThePortableLayercontainsthecodethatintegrateswiththemicroprocessor’sinfrastructure,includingthesavingandrestoringoftheprocessor’sinternalregisters,thereprogrammingoftheprocessor’sMemoryProtectionUnit(MPU)/MemoryManagementUnit(MMU)registers,andtheoperationoftheRTOSTick.Thereisalsoself-testfunctionalityandperformancemonitoring.

ThePortableLayerabstractsandencapsulatesthespecificmicroprocessorandcompilerdetailsandimplementationfromtheRTOSCoreLayer.Generally,thePortableLayerwillbekeptsmallandconcise.TofacilitateportingtheRTOStonewprocessorandcomplierconfigurations,ideallytheonlychangesrequiredshouldbecontainedwithinthePortableLayer,allowingtheCoreLayertoremaincommonacrossallRTOSports.

ThisapproachofpartitioningtheCoreandPortableLayersallowsthesameRTOSfunctionalityandAPItobeportedacrossmanydifferentprocessorandcompilercombinations.Therefore,thedesignerisfreetochoosetheoptimumprocessorandcompilerfortheirnewproject,andstillhavetheabilitytousetheirpreferredRTOS.

Figure 1. Typical internal structure of an RTOS




2.1 Safety Design StandardsTheSafetydesignstandards,illustratedinFigure2,existtoensureaconsistent,highlevelofconfidenceinsystemsthatimplementsafetycriticalfunctionalityacrossdifferentverticalmarkets.Thesedesignstandardstypicallycoverallaspectsofsystem,hardware,software,designandverification,andalsoincludeintegrationandusageissues.Differentmarketsectorshavecreatedtheirownsectorspecificstandards.Formanymarketsectorstheunderlyingprinciplesofsoftwaredesignandverificationaresimilar;howeverthedomainspecificstandardsincludeprocessesandproceduresformanagingtheuniquesystemlevelriskspresentwithineachsector.

CHAPTER 2 Functional Safety

Figure 2. Industry Design Standards

Certainstandardsallowforthecertificationofindividualsoftwareonlycomponents,forexampleanRTOS.HeretheindividualcomponentwillbecertifiedasaSafetyElementoutofContext(SEooC),asthefinalapplicationinwhichthecomponentwillbeusedisunknown.Whendesigningsuchsoftware,assumptionswillbemadeaboutitssafetygoalsandtheSafetyIntegrityLevel (SIL) required.Thesesafetygoalsmustbedescribedwithin theSafetyManualalongwith the installationand integration instructions.Developersusingthesoftwarewillneedtoconfirmthat thesafetygoalsdefinedduringthesoftware’sdevelopmentmeettherequirementsoftheirprojects.

Otherstandards take intoaccount thespecificproduct risks,andhencecertificationcanonlyoccurataproduct level.Individual software components designed for use in systemswhere certification is only possible at a system level arenormallyreferredtoas“certifiableto”.BothIEC61508(industrial)andISO26262(automotive)supportthecertificationofsoftwareonlycomponents;whereasIEC62304(medical)andDO178(aerospace)onlysupportthecertificationofthefinalproduct.

Tohighlightsomeofthedifferencesbetweenthestandards,IEC61508has4SILlevels,whereSIL4isthehighest.ButasoftwareonlycomponentcanonlybecertifiedtoSIL3,asSIL4systemsneedtotakeintoaccounttheriskpresentedbythehardwareplatform.InISO26262softwareonlycomponentscanbecertifiedtoASIL4,whichisthehighestlevel.HoweverISO26262 requires that all software implementing highASIL safety functions also have their own software verificationmonitortoconfirmthecorrectnessofoperation.IndependentCertificationBodiesareavailabletocertifyorvalidateindividualcomponentsandproductsagainstarangeofinternationalsafetystandards.

Industry Standard

Industrial IEC61508[1]

Automotive ISO26262[2]

Medical IEC62304[3]/FDA510(k)

Rail EN50128[4]

Aerospace DO178C[5]




2.3 AdaptingtheRTOStodifferentSafetyDesignStandardsWhencreatingaFunctionalSafetyRTOSportforanewprocessor/compilercombination,designerscouldimplementtheworktomeettherequirementsofonespecificsafetydesignstandard,forexampleIEC61508SIL2.Ononelevelthiswouldbeveryefficient,astheworkundertakenwouldonlybethatrequiredtomeettherequirementsofthespecificstandardinquestion.Howeverthiswouldseverelyaffectcodereuse,asthesameRTOSportwouldneedtobere-workedforusewithdifferentstandards,anddifferentSIL.Italsomeansthedevelopmentteamwouldhavetobetrainedinmanydifferentdevelopmentlifecycles,andtheengineerswouldneedtounderstandwhichprocessesandprocedurestouseforeachnew work package.

Alternatively,theFunctionalSafetyRTOScouldbedesignedtomeetthehighestrequirementsneededtocomplywithallrelevantstandards.Eachtimeanewsafetydesignstandardisidentified,thesafetycriticaldevelopmentlifecycleusedtocreatetheRTOSwouldbeupdatedtocomplywith thehighestSILrequirements for thatstandard.ThismaximizestheamountofworkandcostwhencreatinganewFunctionalSafetyRTOSport,butmeansasignificantincreaseinthequalityoftheRTOSduetothemostrigorouselementsfromeachrelevantsafetydesignstandardbeingadopted.Codereuseisfacilitated,asthesameRTOSportcannowbeusedtosupportallrelevantstandards,atallSILs.Theengineersnowonlyhavetolearnonesafetycriticaldevelopmentlifecycle,thereforetheworkingpracticestocreatetheRTOScanbewellandtruly institutionalized.

Theresultingdocumentsandreportsgeneratedfromthesafetycriticaldevelopmentlifecycle,alongwiththeplansandprocessesusedtomanagethedevelopmentlifecycle,formtheDesignAssurancePack(DAP).ItistheDAPthatistailoredtomeet the requirementsandexpectationsof thespecificsafetydesignstandard.Thisallows the relevant informationtobepresentedinaformunderstoodbyanindustryspecificCertificationBody.Forexample,theDAPusedinindustrialapplicationswillbere-formattedasaDesignHistoryFile(DHF)formedicaldevicemanufacturers,howevertheunderlyingdevelopmentlifecycleusedtodeveloptheRTOSwillbethesame.EachDAP/DHFwillcontainacompliancematrixthatprovidescrossreferencesbetweentherelevantstandardandtheDAPcontents.

2.2 Adapting the RTOS for Functional SafetyRiskmanagementhasafundamentaleffectonthedesign,implementationanddeploymentofaFunctionalSafetyRTOS.All risks relating to theRTOSneed tobe identified,andeithermitigatedwithin thedesignorpassedup to thesystemintegratorfortheirconsideration.Therearemanyformalmethodstoidentifyriskswithinasoftwaredesign,rememberingtherequirementthatsafetysoftwaredeliversaveryhighlevelofrobustnessanddeterminismwhencomparedtocommercialgrade software.

OnewaytoidentifyriskswithintheRTOSistouseastructuredtoolsuchasahazardandoperabilitystudy(HAZOP).TheHAZOPcanbeusedtoidentifyallareasofweaknesswithinthefunctionalRTOSmodelandAPI.Theresultsofthisprocessgenerateasetofsafetyrequirements,whichhaveafundamentaleffectonthedesignandimplementationoftheRTOS.Theresultingfunctionalandsafetyrequirementsarepassedthroughasafetycriticaldevelopmentlifecycle, illustratedinFig.2,thatsupportsthesafetydesignstandardagainstwhichthefinalproductwillbecertified.Theresultingdocumentsandreportsgeneratedfromthesafetycriticaldevelopmentlifecycle,alongwiththeplansandprocessesusedtomanagethedevelopmentlifecycle,formtheevidencerequiredtoachievecertification.ThesedocumentsandreportsareusuallypackagedasaDesignAssurancePack(DAP)orCertificationPack(CP).RisksandhazardsthatcannotbemitigatedwithintheimplementationoftheRTOSarepassedontothesystemintegratorviatheSafetyManual.ThispassestheresponsibilityfortheresidualrisksfromtheRTOSsuppliertothesystemintegrators.

TheinclusionofthesafetyrequirementscreatesasignificantdifferencebetweenacommercialgradeRTOSandanRTOSdesignedforFunctionalSafetyuse.Asthefunctionalrequirementsarethesame,usuallytheoperationandAPIaresimilar,butunderneaththeAPIthedesignandcodewillhavebeencompletelyredesignedforsafety.




Page8

FunctionalSafetycompilersareavailable,andprovidethenecessarylevelofperformanceanddocumentationforusewithinasafetycriticaldevelopmentproject.HowevernotalldeveloperswillselectaFunctionalSafetycompiler,insteadtheywilladoptastandardcompileranddevelopa‘proveninuse’argument.This‘proveninuse’argumentdoeshaveitschallenges,itmaybepossiblefortheproductdeveloper,butit’sunlikelythatanRTOSdeveloperwouldbeabletoindependentlycollectenoughdatatomakea‘proveninuse’claim.

Analternativeapproachistoeliminatethecompilerfromthesafetycase.TheFunctionalSafetyRTOSdeveloperwillhaveacomprehensiveanddetailedspecificationfortheRTOS,fromwhichthesourcecodeisdeveloped.Thissourcecodeformstheinputtothecompiler.TheRTOSdeveloperutilizesanextensivetestingstrategy,whichteststheoutputofthecompiler.Iftheoutputofthecompilerisfullyverifiedfromtestsderivedfromtherequirements,thetranslationmadebythecompilercanberemovedfromconsideration.

Toconfirmthattheextensivetestingundertakenisextensiveenough,aModifiedDecision/ConditionCoverage(MC/DC)measurementneedstobetaken.MC/DCisameasurementofstructurecoverage.Itrequiresthattestcasesexerciseeachconditionofeachdecisionwithintheprogram,andthatwhendoingsoeachconditionwithinadecisioncanindependentlyaffecttheoutcomeofthedecision.Achieving100%MC/DCdemonstratesthateachcomponentofeachdecisionhasbeentestedinisolation,thattheobjectcodegeneratedforboththepassandfailcasesofeachcomponenthasbeenexecuted,andthatresultingbehaviorhasbeendocumentedandjustified.

Figure 3. An example of an embedded software Safety Critical Development Lifecycle

2.4 SupportingDifferentCompilersSafetydesignstandardstypicallyrequireanytoolsthathaveadirecteffectonthecodetobeofthesameSafetyIntegrityLevelas thesoftwareunderdesign.This includes thecompiler,whichposesapotential issue for theRTOSdeveloper.Typicallythecompilerisselectedbythecustomer,buttoachievecertificationoftheirRTOSproduct,theRTOSdevelopermustdemonstratetotheCertificationBodythatthecompilerusedcomplieswiththerelevantsafetydesignstandard.ItwouldbeexpectedthatanRTOSsuppliercouldsupporttheuseofmanycompilers.

Software Requirements

Capture

Software Architectural

Design

Software Detailed Design

Software Coding

Software Code Verification

Software Integration Verification

Software System

Verification

Software Release

Procedure

System Requirements

Software Requirements Specifications

Software Design Document (High Level Design)

Software Design Document (Low Level Design) Raw Code

Verified Modules

Verified Integrated Software

Verified Software

Software Test Description (Software System Verification)

Software Test Plan

Software Test Description

(Software Integration Verification)

Software Test

Description

(Software Code Verification)

Software Code Verification Results

Software Integration Results

Software System Verification Results

Requirements Decomposition

Risk Analysis

Softw

are In

tegrat

ion

Verifi

catio

n of R

isk C

ontro

l

Development Lifecycle Activities

Inputs to problem resolution process

Outputs to problem resolution process

Deliverables transferred into/out of activities

Deliverables to the Risk Management File

Key

Software Requirements

Capture

Software Architectural

Design

Software Detailed Design

Software Coding

Software Code Verification

Software Integration Verification

Software System

Verification

Software Release

Procedure

System Requirements

Software Requirements Specifications

Software Design Document (High Level Design)

Software Design Document (Low Level Design) Raw Code

Verified Modules

Verified Integrated Software

Verified Software

Software Test Description (Software System Verification)

Software Test Plan

Software Test Description

(Software Integration Verification)

Software Test

Description

(Software Code Verification)

Software Code Verification Results

Software Integration Results

Software System Verification Results

Requirements Decomposition

Risk Analysis

Softw

are In

tegrat

ion

Verifi

catio

n of R

isk C

ontro

l

Development Lifecycle Activities

Inputs to problem resolution process

Outputs to problem resolution process

Deliverables transferred into/out of activities

Deliverables to the Risk Management File

Key




2.5 Creating a new Functional Safety RTOS portPortinganRTOStoanewprocessor/compilercombinationinvolvescreatinganewPortableLayerfortheRTOS,andthen integrating the core code layer with the new port layer. When creating a new Functional Safety RTOS port the process issimilar,butincludesextrasafetyactivities.TheRTOSportingtaskismadeeasieriftheRTOShasbeendesignedtothehighestqualitylevelforallrelevantsafetydesignstandards,asthismaximizesdesignreuse.

Theinitialactivityundertakenisanimpactanalysis.ThisinvolvesimplementingaHAZOPanderratastudytoensuretheRTOSissuitableforuseonthenewprocessor/compilercombination,andthatnoknownerrorshaveaneffectontheuse of the RTOS.

TheexistingRTOSCoreLayerdesigndefinestherequirementsforthenewPortableLayer,anditisfromtheserequirementsthatthenewPortableLayerisdesignedandtestcasesconstructed.RequirementtracingisimplementedtotracefromtheexistingCoreLayerdesigntothenewPortableLayerdesignandtestingdocumentation.

Oncethecodeisready,verificationandvalidationworkcancommence.Static,inspection,moduleandintegrationtestsareundertakenonthenewPortableLayer.Forcompleteness,moduleandintegrationregressiontestsforthepre-existingCoreLayercodearealsorepeatedonthenewprocessor/compilerplatform.Thenthehigh-levelsystemverification,validation,MC/DCandsoaktestsareimplemented,tocompletethetesting.

TheresultingDAPisconstructedfromtheexistingCoreLayerdesignandtestingdocumentsandthenewPortableLayerdocumentation.TheDAPwillalsoincludeallverificationandvalidationtestresults.

Byimplementingacomprehensivestructurecoveragemeasurementanalysistothecompleterequirementscoveragetestingsuchasthosediscussedabove,itcanbedemonstratedthat:

• Theoutputofthecompilerisoperatingasintendedbytheinputtothecompiler;• Allrequirementshavebeentestedsuccessfully;• Theobjectcodecontainsnoused,orundocumentedcodesegments.

Thisapproachverifiesthecompiler’sinterpretationofitsinput,ratherthantrustingthecompilertobehaveasexpected.Achangeindevelopmenttoolswouldonlyrequireachangeimpactanalysisfollowedbythere-executionoftheRTOStestsinordertohaveconfidenceinthecompileroutput[6].




3.1 ScopeofaFunctionalSafetyComponent

Byimplementingthesafetyactivitiesdescribed,andusingtheresultingdocumentationtocreateaDAP,theRTOSbecomesaFunctionalSafetyComponent.Generally,FunctionalSafetyComponentsprovidespecificandwelldocumentedfunctionality,andaredesignedtomeettherigorousdemandsofspecificsafetydesignstandards.

FunctionalSafetyComponentsaresuppliedwithaDAP(orequivalent)supportingusewithinasafetycriticalproduct,andallowingthecomponenttobecertifiedonceintegratedintotheapplication.FunctionalSafetyComponentsaredeliveredforaspecificusecase.Usingthecomponentwithinitsdefinedenvironment,inaccordancewiththeSafetyManual,removestheneedforretesting.FunctionalSafetyComponentsshouldhelptoshortendevelopmenttimesandreduceriskwithinsafetycriticaldevelopmentprograms.ItsignificantlyhelpsiftheFunctionalSafetyComponenthasbeenpre-certifiedbyarecognizedCertificationBody,asthisreducestheriskofanycertificationissuesrelatingtothecomponentbeingidentifiedlateinthedevelopmentlifecycle.

AhiddenbenefitofFunctionalSafetyComponentsisscaleofuse.FunctionalSafetyComponentsfromawell-establishedcompanywillbeinusebymanydifferentdevelopersacrossmanydifferentapplications.Thismultiplicityofuseprovidesahigherlevelofconfidenceintheproduct.Intheunfortunateeventaproblemisdiscoveredwithacomponentinoneproduct,thiscanbefedbacktoallthedevelopersusingthecomponent.

3.2 CreatingasafetycriticalembeddedplatformfromFunctionalSafetyComponentsA Functional Safety embedded platform is created from the microprocessor, self-test libraries, RTOS, and drivers. Inmostinstancesthemicroprocessorandtheself-testlibrariesaresuppliedfromonecompany,asonlythemicroprocessormanufacturerhasthe in-depthknowledgeofthemicrocontroller’sdesignandmanufacturingmethodsneededtocreateasetofteststhatprovideenoughcoverage.TheRTOSandthedriversarealsonormallysuppliedbyasinglecompany,allowingthesamesafetycriticaldesignlifecycletobeused.

CreatingtheFunctionalSafetyembeddedplatformrequirestheintegrationoftheindividualFunctionalSafetyComponentsaccording to the detailed instructions within their SafetyManuals. This process should be straightforward. Taking theRTOSasanexample,theaccompanyingSafetyManualwillconciselyexplainhowtoinstalltheRTOSintoadevelopmentenvironment,ensuringeachelementispresent,inthecorrectlocationandisfreefromcorruption.TheSafetyManualwillalso give concise instructions on how to integrate the RTOS with the rest of the application, and clearly detail any residual risksthatneedtobemanagedbytheoveralldesign.

FollowingtheconciseSafetyManual instructionswillalsogeneratetheevidencerequiredbytheCertificationBody.TheCertificationBodywillwanttoseeevidencethattheinstallationandintegrationhastakenplacecorrectly,thatacompetentpersonhasundertakentheinstallationandintegration,andthatsomeonecompetentandindependentfromtheprocesshasreviewedtheevidenceandhasconfirmedtheworkhastakenplaceasexpected.TheCertificationBodywilltypicallywanttoseethattheFunctionalSafetyComponenthasbeenlicensedforuse,andthatitcanbesupportedinthelongterm.[7]

CHAPTER 3 Functional Safety Components




FunctionalSafetyComponentsarerobust,deterministicandprovideasmoothpathtoachievingcertificationonceintegratedwithinaproduct.Theyshouldprovidethebuildingblocksrequiredtobuildsafetycriticalproducts.ThefollowingsectionsdetailthebuildingblocksthataresometimesprovidedbyFunctionalSafetyRTOSs.

4.1 Creating a Mixed SIL Software ArchitectureFunctionalSafetyRTOSscontainbuildingblocksthatenabletheseparationandisolationofindividualTasks.ThisfeaturecanassistdeveloperstocreateasinglebuildofcodethatcontainssoftwareofdifferingSILs.TodothistheRTOSwillusetheprocessor’sunderlyingMPUorMMUfeature.MPUsarebecomingastandardfeatureofmicroprocessors.Theyprovideameanstoestablishaccesspermissionsforregionsofmemory.Codeexecutioncanbeallowedordisallowedforeachregion.Aregioncanbesetforread-onlyaccess,read/writeaccess,ornoaccessforbothprivilegedandusermodes.

AFunctionalSafetyRTOSshouldallowthedefinitionandmanipulationofMPUregionsonaperTaskbasis,whereeachTaskisassignedspecificmemoryregions.Memoryregionscanbeusedforeithersafetyornon-safetycode.AusefulprotectionfeatureistoprotecteachTaskstackwithitsownMPUmemoryregion.EachtimeanewTaskisgiventhecontext,theMPUwillbere-programmedwiththememoryregionsforthatnewTask.AnyaccessviolationofaregionwillcauseaMemoryManagementFault,andtheprocessorfaulthandlerwillbeactivated.Thefaulthandlerisinvokedpriortotheactualmemoryaccess.Withcare,thisallowsdeveloperstocreateabuildofsoftwarecontainingsoftwaredesignedfordifferentSILs.AnexampleisshowninFig.4[8].

CHAPTER 4 Functional Safety RTOS Architecture Considerations

Figure 4. Building Mixed SIL Software Applications




4.2 Controlling Access to the Processor’s ResourcesControllingaccesstotheprocessor’sresourcescanbeachievedinavarietyofways.Therearetworisksthatneedtobemanaged;ensuringthatonlyoneTaskhasaccesstotheresourceatanyonetime;andavoidingpriorityinversion,wherebyalowpriorityTaskhascontrolofaresourcethatblocksahigherpriorityTaskfromgainingaccesstotheresource.OneapproachistouseMutexes,whicharebinarysemaphoresthatincludeapriorityinheritancemechanism.WhenusedformutualexclusiontheMutexactslikeatokenthatisusedtoguardaresource.WhenaTaskwishestoaccesstheresourceitmustfirstobtain(‘take’)thetoken.Whenithasfinishedwiththeresourceitmust‘give’thetokenback–allowingothertasks access.

Mutexes employpriority inheritance. Thismeans that if a highpriority Taskblockswhile attempting to obtain aMutex(token)thatiscurrentlyheldbyalowerpriorityTask,thenthepriorityoftheTaskholdingthetokenistemporarilyraisedtothatoftheblockingTask.ThismechanismisdesignedtoensurethehigherpriorityTaskiskeptintheblockedstatefortheshortesttimepossible,andinsodoingminimizethe‘PriorityInversion’thathasalreadyoccurred.Priorityinheritancedoesnotcurepriorityinversion,itjustminimizesitseffects.It’sbesttoensurerealtimeapplicationsavoidpriorityinversionissuesbydesign.

AnalternativeoptionistouseaGatekeeperTaskFig.5,tocontrolaccesstotheresource.AbasicGatekeeperTaskconsistsofaTask thatcontrols the ‘resource’,aqueue for receivingdata/command,andacallback function.ApplicationTaskswritedata/commandstothequeueinsteadofdirectlyaccessingtheresource.TheGatekeeperTaskprocessesthedatacommandsandtheresourceisupdatedaccordingly.WhentheresourcechangesstateanInterruptServiceRoutine(ISR)istriggeredwhichisplacedintheQueue,theGatekeeperTaskwillthenexecutetheregisteredcallbackfunctiontopassbackthe new data to the Application Task.

Figure 5. Architecture of a Gatekeeper Task




4.3 Multicore SupportItisbecomingcommonforembeddedsystemstoincorporatemorethanoneCPUonasingleSystemonChip.Fromahardwareperspective,therearebroadlytwotypesofmulticoredesign.IfalltheCPUshaveexactlythesamearchitecture,itistermedhomogeneousmulticore;ifthereisvariabilityinthearchitectures,itisheterogeneousmulticore.

FromtheRTOSperspective,thechoiceisbetweenAMPandSMP.WhereAMPstandsforAsymmetricMulti-ProcessingandSMPmeansSymmetricMulti-Processing.AnSMPsystem is typicallyarrangedwithmultiplehomogeneousCPUs.ThereisnormallyonlyasingleinstanceoftheRTOS,andTasksaresharedacrosscoreswiththeobjectiveofimprovingprocessorthroughput.Inembeddedapplications,SMPisusedtoimplementprocessingheavyroutines,forexampleAIorimageprocessingactivities.

AnAMPsystemhasmultipleCPUs.EachCPUhasitsowninstanceoftheRTOS,andtheRTOSprovidesacommunicationfacilitybetweentheCPUstosharedataandprovidecoordination,usingthestandardRTOSAPIcalls.AMPsolutionsarenormallydeployedwhereeachCPUisundertakingadifferentrolewithinthesystem.AMPissuitedforuseinsafetycriticalormixedsafetycriticalembeddedsystems.Aseachprocessingcoreisperformingaspecificfunction,therecouldbeamixofdifferentRTOSswithinanAMPsolution.Forexample,alargeSoCusedforautonomousdrivingislikelytocontainARMCortex-AclustersalongsideARMCortex-Rsafetycores;theRTOSrequirementsbetweenthesecoretypescouldbeverydifferent.RTOSmulticoresolutionsareavailableasFunctionalSafetyComponents,andprovideaveryfastandeffectivewayofcreatingfunctionalsafetycapabilityacrossamulticoreSystemonChip.




5.1 Conclusion Thispaperhasexaminedthecomplexity,effortanddetailedknowledgerequiredtoadaptanRTOStoarangeofdifferenttechnologyplatforms,whilstmaintainingcompliance toawidespectrumof vertical specificsafetydesignstandards. Ithasdetailedhow theexperienceand ‘knowhow’of safetycriticaldevelopmentcanbecaptured, andpackagedasaFunctionalSafetyComponent,andhowFunctionalSafetyComponentsenabledeveloperstoquicklycreateaFunctionalSafety embeddedplatformwithminimumeffort. TheprinciplesdiscussedgobeyondRTOSdevelopment, andcanbeappliedtothedevelopmentofanystandalonesoftwarecomponent.

ThispaperhasdemonstratedthattheadvantagesofusingaFunctionalSafetyRTOSarenotlimitedtosimplercertificationonceembeddedintoanapplication,butalsotheFunctionalSafetyfeaturesthatanRTOScanprovide.Thesefeaturesallowsoftwareofmixedsafetycriticalitytobedeveloped,theprocessor’sresourcesaccessedsafely,andthecapabilitytoscalefromstraightforwardsinglecoreuseuptocomplexmulticoredevices.Formoreinformationpleaserefertowww.highintegritysystems.com.

5.2 Reference List

[1]IEC61508:2010Functionalsafetyofelectrical/electronic/programmableelectronicsafety-relatedsystems.[2]ISO26262-2011--Roadvehicles–FunctionalSafety[3]IEC62304:2006Medicaldevicesoftware–Softwarelifecycleprocesses.[4]CENELEC – EN 50128Railway applications –Communication, signaling and processing – Software for railwaycontrolandprotectionsystems.June2011.[5]DO-178CSoftwareConsiderationsinAirborneSystemsandEquipmentCertification,December13,2011.[6]R.Barry“HowtoverifyyourcompilerforuseinIEC61508safetycriticalapplications”October2007.[7]“CopingwithComplexity,DesigningforSafety”,WITTENSTEINhighintegritysystems,June2018.[8]“UsinganMPUtoenforcespatialseparation”WITTENSTEINhighintegritysystems,May2017.

CHAPTER 5 Conclusion & References




UserfeedbackisessentialtothecontinuedmaintenanceanddevelopmentofSAFERTOS. Please provide all software and documentationcommentsandsuggestionstothemostconvenientcontactpointlistedbelow.

ContactWITTENSTEINhighintegritysystemsAddress: WITTENSTEINhighintegritysystems Brown’s Court, Long Ashton Business Park Yanley Lane, Long Ashton Bristol, BS41 9LB England

Phone: +44(0)1275395600Fax: +44(0)1275393630Email: [email protected] Website www.HighIntegritySystems.com

AllTrademarksacknowledged.

Contact Information

This document was prepared by WITTENSTEIN aerospace & simulation ltd for the Embedded World Conference 2019, date as document, all rights reserved.

safety critical rtos - high integrity systems...an rtos is a software component that rapidly...

Documents