Upload
others
View
11
Download
1
Embed Size (px)
Citation preview
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.
HighIntegritySystems
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 2
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
HighIntegritySystems
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 3
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 4
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 5
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 6
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]
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 7
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.
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 9
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].
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 10
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 11
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 12
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 13
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.
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 14
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
Email: [email protected]: www.highintegritysystems.com
WITTENSTEIN high integrity systemsAmericas: +1 408 625 4712ROTW: +44 1275 395 600
Safety Critical RTOS Adapting Across ApplicationsCopyright date as document date.
Page 15
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.