A Semantic Web Architecture for Model based Safety Engineering
A Semantic Web Architecture for Model based Safety Engineering
A Semantic Web Architecture for Model based Safety Engineering
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
A <strong>Semantic</strong> <strong>Web</strong> <strong>Architecture</strong> <strong>for</strong><strong>Model</strong> <strong>based</strong> <strong>Safety</strong> <strong>Engineering</strong>Vangelis VassiliadisGnomon In<strong>for</strong>maticswww.gnomon.com.grAADL Standards MeetingToulouse, FRMay 17-18, 20101
Contents• The project• The context, safety engineering• <strong>Model</strong>ing• Ontologies• System <strong>Architecture</strong>• Altarica and <strong>Safety</strong> Analysis2
Project organisation• Gnomon In<strong>for</strong>matics– Project management– System <strong>Architecture</strong>, Design and Implementation.– Ontology <strong>Engineering</strong>– Vangelis Vassiliadis• Arist. Univ . Thessaloniki– Dept. of In<strong>for</strong>matics.– <strong>Safety</strong> Analysis expertise– Trans<strong>for</strong>mation to Altarica– Panagiotis Katsaros• Ellidiss Technologies– LabAssert design tool.– Pierre Dissaux• Thales Alenia Space– Project extension– Provide industrial models <strong>for</strong> system validation– Xavier Olive• Funding ESA / ESTEC– Technical Officer: Yuri Yushtein3
ObjectivesDevelop a system to support model-<strong>based</strong> safety engineering• Distributed, Reusable, Collaborative Repository / Ontology of Components and Errormodels• AADL as system architecture and design language. Error and Behaviour Annex.• Integration with the ASSERT process through LABASSERT design tool.• Support safety analyses by trans<strong>for</strong>mation to Altarica.Benefits• <strong>Model</strong>-<strong>based</strong>: Integration of design and safety analysis.• <strong>Safety</strong> considerations early in the development phase.• Formal methods and traditional techniques (FTA, FMEA – manual techniques).• Compositional safety analysis• Handle system complexity (esp. Embedded systems complex SW/HW).• Use of <strong>Semantic</strong> <strong>Web</strong> and Ontology standards.• <strong>Semantic</strong>s <strong>based</strong> interoperability at a language and tool level.• <strong>Web</strong>-ready (Collaborative, Distributed)• Modular and extensible component representation.4
Project timeline and status• First phase study Dec ‘08• Second phase kick-off March ’09• Requirements Analysis Sep ’09• Ontology <strong>Engineering</strong> Sep ‘09• System Specification and Design Feb ‘10• Qualification Review Sep ’10• Final System (including Validation) Dec ’105
<strong>Model</strong> <strong>based</strong> <strong>Safety</strong> analysis process6
ASSERT Process (ESA)• <strong>Model</strong>ing phase– <strong>Model</strong>s described using AADL with TASTE / LABASSERT views• Data• Functional• Interface• Deployment Views– Function interfaces wrappers (AADL Subprograms with functionparameters as Features of given Data component).• <strong>Model</strong> trans<strong>for</strong>mation and Verification– <strong>Safety</strong> analysis with Altarica– Trans<strong>for</strong>m AADL model to Altarica <strong>Model</strong>• Code generation7
ASSERT process8
Error <strong>Model</strong>ingRepresentation•As collections of error States, and Transitions between states that are triggered by Events. (Labeledtransition system)<strong>Model</strong> Extension•Applying an Error <strong>Model</strong> to a Component (SW or HW) results in State space expansion: partitioningof its state space into normal / nominal and error states. For both SW and HW components:•Identify specific features as state variables•Applying Error <strong>Model</strong> to Component is to specify the values of state variables <strong>for</strong> each state in themodel•Applicability of Error <strong>Model</strong>s to Components <strong>based</strong> on Ontology reasoning (ClassificationHierarchies). (E.g. Specific Error <strong>Model</strong>s <strong>for</strong> Bus, Ethernet Bus etc).Error <strong>Model</strong>s in AADL•Combined Error and Behaviour Annex .Ontology•Provides a higher level – an abstraction – of the specific syntactic representation of the Annexes9
Error <strong>Model</strong> hierarchy: Feature Inheritanceerror model stuckfeaturesNominalState : error stateStuckState : error stateStuckEvent : error eventStuckProp : in out error propagationend stuckerror model recoverfeaturesRecoverEvent : error eventend recoverInheritserror model recoverable_stuckfeaturesNominalState : error stateStuckState : error stateStuckEvent : error eventStuckProp : out error propagationRecoverEvent : error eventend recoverable_stuck// -----------------------------------------------------error model implementation recoverable_stuck.implTransitionsNominalState –[StuckEvent] -> StuckStateNominalState –[StuckProp] -> StuckStateStuckState -[StuckProp] -> StuckStateStuckState –[RecoverEvent] -> NominalStateend recoverable_stuck.impl10The implementation isdefinedin the ‘child’
Device Error modelsOpen Circuit (OC)Short Circuit (SC) andbridging a specific case<strong>for</strong> SC betweenadjusted pins or wires.S/C with structureCurrent Leakage(having OC and SC astwo extremes)Output value drift (e.g.Frequence drift <strong>for</strong>crystalsTime drifts (Outputsdelay or reach fasterthe desired value)Stuck to 0/1 (digitaloutputs) or Stuck to(Blocked at) open/close<strong>for</strong> valves, thermostatsetc.Out of Range (Too lowor too high, Erroneous)output.Leakage (<strong>for</strong> pipes)Failure modes / errorstates11
<strong>Model</strong> extension example (1)error model recoverable_stuckfeaturesNominalState : error stateStuckState : error stateStuckEvent : error eventStuckProp : out error propagationRecoverEvent : error eventend recoverable_stuck// -----------------------------------------------error model implementation recoverable_stuck.implTransitionsNominalState –[StuckEvent] -> StuckStateNominalState –[StuckProp] -> StuckStateStuckState -[StuckProp] -> StuckStateStuckState –[RecoverEvent] -> NominalStateend recoverable_stuck.impldevice ButtonFeaturesuser_input : in event data port;output: out event data port;end Button;// -----------------------------------device implementation Button.implannex Error_<strong>Model</strong> {**<strong>Model</strong> => recoverable_stuck.impl;**};annex behavior_specification {**statesNominalState : initial state // copied from EAStuckState : return state // copied from EAtransitionsNominalState –[StuckEvent] -> StuckState{output = stuck} // functional, data codeNominalState –[StuckProp] -> StuckState{output = stuck}StuckState -[StuckProp] -> StuckState{output = stuck}StuckState –[RecoverEvent] -> NominalState{output = user_input}**}end Button.impl;12
<strong>Model</strong> Extension example (2)abAddrsubprogram ADDfeaturesa: in parameter behavior::integer ;b: in parameter behavior::integer ;r: out parameter behavior::integer ;propertiesCompute_Execution_Time => 1 Ms .. 1 Ms;end ADD;subprogram implementation ADD.implend ADD.impl;Error_FreeoverflowOver_Flowout overflow_properror model OVERFLOWfeaturesError_Free: initial error state;Over_Flow: error state;overflow: error event{occurrence => poisson 1E-4};overflow_prop: in out error propagation{occurrence => poisson 1E-4};end OVERFLOW;in overflow_properror model implementation OVERFLOW.NotionaltransitionsError_Free -[ overflow ]-> Over_Flow;Error_Free -[ in overflow_prop ]-> Over_Flow;Over_Flow -[ out overflow_prop ]-> Over_Flow;end OVERFLOW.Notional;13
example Behaviour Annexsubprogram ADDfeaturesa: in parameter behavior::integer ;b: in parameter behavior::integer ;r: out parameter behavior::integer ;propertiesCompute_Execution_Time => 1 Ms .. 1 Ms;end ADD;subprogram implementation ADD.implannex behavior_specification {**statesError_Free : initial state;Over_Flow : return state;transitionsnormal:Error_Free -[ ]-> Error_Free{ r:=(a+b);};overflow:Error_Free -[ ]-> Over_Flow{r:=OVERFLOW;};out_overflow_prop:Over_Flow -[ ]-> Over_Flow{r:=OVERFLOW;};in_overflow_prop:Error_Free -[ ]-> Over_Flow{r:=OVERFLOW;};**};annex error_model {**<strong>Model</strong> => error_models::OVERFLOW.Notional;**};end ADD.impl;States, Events andTransitions are copiedfrom the Error Annex.The user can add actioncode <strong>for</strong> the transitions.14
Taste (Assert) example----------------------------------------------------- AP-Level Container: Double_Adder::AU---------------------------------------------------system AUfeaturesADD: in event port {Compute_Entrypoint => "ADD";ASSERT_Properties::RCMoperation =>subprogram Double_Add::ADD;… };end AU;system implementation AU.otherspropertiesSource_Language => Ada;annex error_model {**<strong>Model</strong> => error_models::OVERFLOW.Notional;Guard_In => overflow_prop when(ADD[overflow]),mask when othersapplies to ADD;Guard_Event => ADD[overflow,overflow_prop]applies to ADD;Report => Error_Free; **};end AU.others;15
Example Interfaces (Function calls)----------------------------------------------------- AP-Level Container: Double_Adder::Calculator---------------------------------------------------system CalculatorfeaturesPer<strong>for</strong>m: in event port {Compute_Entrypoint => "Per<strong>for</strong>m";ASSERT_Properties::RCMoperation => subprogram Double_Add::Per<strong>for</strong>m;… };ADD1: out event data port add_data {ASSERT_Properties::RCMoperation => subprogram Double_Add::ADD;… };ADD2: out event data port add_data {ASSERT_Properties::RCMoperation => subprogram Double_Add::ADD;… };end Calculator;system implementation Calculator.otherspropertiesSource_Language => Ada;annex error_model {**<strong>Model</strong> => error_models::OVERFLOW.Notional;Guard_Out => overflow_prop when (Per<strong>for</strong>m[overflow_prop]),mask when othersapplies to ADD1;Report => Error_Free;**};end Calculator.others;end Double_Adder;Propagates overflow_prop from Per<strong>for</strong>m Port to ADD1 Port16
BA attached …...to System:SYSTEM IMPLEMENTATION Calculator.others …annex behavior_specification {**statess_OK : initial; // copied from EAs_NoData; // copied from EAs_Overflowtransitionss_OK -[] -> s_OK {ADD1.a = Per<strong>for</strong>m.a;ADD1.b = Per<strong>for</strong>m.b;ADD2.a = ADD1.r;ADD2.b=Per<strong>for</strong>m.b;r=ADD2.r}Error_Free -[overflow] -> Over_Flow {…17..to Subprogram:subprogram Per<strong>for</strong>mfeaturesa: in parameter behavior::integer {ASSERT_Properties::Encoding => native; };b: in parameter behavior::integer {ASSERT_Properties::Encoding => native;};c: out parameter behavior::integer {ASSERT_Properties::Encoding => native; };ovf: out parameter behavior::boolean {ASSERT_Properties::Encoding => native;};…end Per<strong>for</strong>m;subprogram implementation Per<strong>for</strong>m.implannex behavior_specification {**state variablestemp1: behavior::integer;temp2: behavior::boolean;temp3: behavior::boolean;statesError_Free : initial state;Over_Flow : return state;transitionsnormal:Error_Free -[ ]-> Error_Free {ADD!(a->a,b->b,temp1->c,temp2->ovf);ADD!(temp1->a,b->b,c->c,temp3->ovf);ovf := (temp2 and temp3);};overflow:Error_Free -[ ]-> Over_Flow { …};out_overflow_prop:Over_Flow -[ ]-> Over_Flow{ …};in_overflow_prop:Error_Free -[ ]-> Over_Flow{…};**};end Per<strong>for</strong>m.impl;
<strong>Semantic</strong> <strong>Web</strong> intro• <strong>Web</strong> of (HTML) documents <strong>Web</strong> of DataHuman interpretedSimple Metadata:XMLDATA• Relatively unstructured• Random• In<strong>for</strong>etrieval• <strong>Web</strong> searchDisplay rawdocuments;All interpretationdone by humansFind andcorrelate patternsin raw docs;display matchesonlyRicher Metadata:RDF/SVery Rich Metadata:OWLInterpretation Continuum• Text summarization• Content extraction• Topic mapsStore and connectpatterns viaconceptual model(i.e,. an ontology);link to docs to aidretrievalComputer interpretedKNOWLEDGE• Very structured• Logical• Reasoningservices• Ontology ...InductionAutomatically acquireconcepts; evolveontologies into domaintheories; link toinstitution repositories(e.g., MII)Automatically spandomain theories andinstitutionrepositories; interoperatewith fullyinterpreting computerMoving to the right depends on increasing automated semantic interpretationAdapted from: Leo Obrst, “Ontologies and the <strong>Semantic</strong> <strong>Web</strong>: An Overview” Mitre, June 2005Ontologies and the <strong>Semantic</strong> <strong>Web</strong>: An Overview” Mitre, June 200518
Protocol Stacks19
<strong>Model</strong> <strong>based</strong> systems engineering (ex. fromNASA)Adapted from TopQuadrant Inc., “Ontology <strong>Engineering</strong>”,20
Ontology Vocabulary• “Class” ≈ “Concept” ≈ “Category” ≈ “Type”• “Instance” ≈ “Individual”• “Entity” ≈ “object”, Class or individual• “Property” ≈ “Slot” ≈ “Relation” ≈ “Relationtype” ≈“Attribute” ≈ <strong>Semantic</strong> link type” ≈ “Role”• OWL– A language to define and use Ontologies on the (<strong>Semantic</strong>) <strong>Web</strong>.– Named Classes, Instances and Properties are represented by IRIS.• Both Symbols and Documents are dereferencable.– Based on DAML (DARPA) and OIL (OntoKnowledge)– Extension of RDFS.– OWL DL Based on Description Logics. Well defined semantics <strong>for</strong>easoning, Sound and complete reasoning algorithms.– W3C recommendation since Feb ’04.21
Component and Failure <strong>Model</strong> Ontology22
Software Error <strong>Model</strong>s: Events -PropagationsClass Subclasses InstancesEvent ComputationalEvent DivideByZeroInsufficientPrecisionNegativeSquareRootOverflowUnderflowTypeMismatchUnitialisedVariableExceptions as Events,Categories as StatesHardwareEventCorruptMemoryCrashDisconnectedDismountedInsufficientDiskSpacePowerOutageSpuriousInterruptsTimeoutTransientErrorsPropagation DataInputPropagation EmptyDataFileExtraneousDataIncorrectDelimitersMissingDataMissingEOFNonAsciiNonNumericFieldOutOfRangeReturnValuePropagationFailureHandleReturnCodeInvalidArgumentValuesWrongNumberOfArgumentsWrongTypeOfArgumentsUserInputPropagationErroneousPromptResponseIncorrectCommandLineArgumentsLatePromptResponseNoPromptResponse23
Software Error <strong>Model</strong>s: GuidelinesAll Error <strong>Model</strong>s <strong>for</strong> Computational (Functional) components are defined as subclassesof the ComputationalError<strong>Model</strong> subclass of the Error<strong>Model</strong> class.By definition all members of the ComputationalError<strong>Model</strong> class haveComputationErrorState and the MemoryErrorState as Error states.Error models <strong>for</strong> Computational components that have hardware – relatedexceptions are defined as subclasses of the Hardware-generatedError<strong>Model</strong> class.Error models <strong>for</strong> Computational components that have features in the left columnshould be defined as subclasses of the class in the right side of the following table:Feature of Computational componentFile Input - OutputCalling external librariesGets / reads input from external filesWaits/Prompts <strong>for</strong> user inputHandles return values from other functionsSuperClass of the associated Error <strong>Model</strong>IOFileError<strong>Model</strong>LibraryFunctionError<strong>Model</strong>DataInputError<strong>Model</strong>UserInputError<strong>Model</strong>ReturnValueError<strong>Model</strong>24
Software Error <strong>Model</strong>s: HierarchyComputationalHardwareGeneratedCHSoftware25
Proposed System <strong>Architecture</strong>Ontology<strong>Engineering</strong>EnvironmentComponent andFM OntologyLabassert[Function, Interface,Deployment Views]Labassert UIextensions<strong>for</strong> ErrorViewAADL/AAXL components /error models[<strong>Web</strong>/HTTP Service]Failure <strong>Model</strong>Ontology Server[<strong>Web</strong>/HTTP Service]FM OntologyFront End (UI)Error View[AADL generated code]Tras<strong>for</strong>m to Altaricamodel<strong>Model</strong> CheckingTool26
Ontology ServerImplements the Ontology APIOntology APIUse of external OWL reasoner (e.g.Pellet, RacerPro).Contains also a parser and aserialiser between OWL axiomsand components and error modelframes to AADL and AAXL.OWLLink27
LABASSERT Edit/View Error <strong>Model</strong>sGet Applicable Error <strong>Model</strong> List• Use the getApplicableError<strong>Model</strong>s (Comp)Select an Error <strong>Model</strong>• from the list of applicable Error <strong>Model</strong>s• Use the getComponent(Name)View the Error <strong>Model</strong>• States• Events• TransitionsView – Edit Error <strong>Model</strong> association• Error <strong>Model</strong> implementation details (Error + Behaviour Annex related) <strong>for</strong> this component.• Optionally post the updates back to the repository. (Iff Component Owner)28
LABASSERT Editing Behaviour AnnexnormalText editing browser <strong>for</strong> each transitionof the error model.Error_Free(in_)overflow_propEditing help to provide the list of validparameter identifiersoverflowOver_FlowGlobal syntactic check(out_)overflow_propw29
Altarica language• Formal language to model critical systems <strong>for</strong> safety analysis.• Developed at LaBRI• Failure propagation model. Constraint automata.• Components are represented as Nodes.– Flow variables: how components connect and pass data to each other.– State variables: internal state of component– Events: trigger state changes.– Transitions: Guard, Event, New state assignments.– Assertions: Global relations between state and flow variables(constraints).• Complex components, sub nodes.• Event synchronisation mechanisms.• <strong>Model</strong> checking tools: OCAS Cecilia, MEC, ARC30
Trans<strong>for</strong>mation to AltaricaAADL Components toAltarica NodesError <strong>Model</strong>s and BAFiltering and Masking•Components to Nodes•Data Features (Port andParameters) to Flows•Event Features to Eventsynchronisations•Features Data types toflows data types•Boolean and Enumeratedtypes only•Each interface callgenerates a separatecallee node.•Events, State andTransitions•BA state variables to ARstate variables•Implicit _state variableenumerates all EA states•EA transitions to _statevariable conditions andassignments•BA Transition codes toTransitions action code•Implicit OK OKtransition to assert code•Guard_In, Guard_Out toAltarica synchronizations•Actual_Bindings generatesynchronisation eventsbetween HW and SW31
Error View Example: Time_ConversionSYSTEM CalculatorFEATURESMul: IN OUT EVENT DATA PORT;{Compute_Entrypoint => “Mul";Assert_Properties::RCMoperation => SUBPROGRAM Calc::Mul.impl;…};……SUBPROGRAM MulFEATURESo1: in PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};o2: in PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};r: out PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};…32
Example Trans<strong>for</strong>mationError View: Error and Behaviour AnnexSUBPROGRAM MulFEATURESo1: in PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};o2: in PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};r: out PARAMETER behavior::integer{ Assert_Properties::encoding => NATIVE;};PROPERTIESCompute_Execution_Time => 1ms..1ms;END Mul;SUBPROGRAM implementation Mul.implannex error_model {**<strong>Model</strong> => error_models::subprogram_ASM.impl;**};annex behavior_specification {**statesNomimalState : initial state;ComputationalErrorState : return state;transitionsnormal:NomimalState -[ ]-> NomimalState {r:=(o1*o2);};InsufficientPrecision:NomimalState -[ ]->ComputationalErrorState {r:=0;};Overflow:NomimalState -[ ]-> ComputationalErrorState {r:=0;};in_OutOfRange:NomimalState -[ ]->ComputationalErrorState {r:=0;};out_OutOfRange:ComputationalErrorState -[ ]->ComputationalErrorState {r:=0;};RecoverEvent:ComputationalErrorState -[ ]->NomimalState {r:=(o1*o2);};**};END Mul.impl;33error model subprogram_ASMfeaturesNominalState: initial error state;ComputationalErrorState: error state;InsufficientPrecision, Overflow: error event;RecoverEvent: error event;OutOfRange: in out error propagation;end subprogram_ASM;error model implementation subprogram_ASM.impltransitionsNominalState -[InsufficientPrecision]->ComputationalErrorState;NominalState -[Overflow]->ComputationalErrorState;NominalState -[in OutOfRange]->ComputationalErrorState;ComputationalErrorState -[out OutOfRange]->ComputationalErrorState;ComputationalErrorState -[RecoverEvent]->NominalState;end subprogram_ASM.impl;
Example Trans<strong>for</strong>mation to Altaricanode Time_Conversion_Calculator_MulflowMul^o1:int:in;Mul^o2:int:in;Mul^r:int:out;state_state:{ComputationalErrorState, NominalState};eventOverflow,RecoverEvent,OutOfRange,InsufficientPrecision;trans(_state = NominalState) |- InsufficientPrecision -> _state := ComputationalErrorState;(_state = NominalState) |- Overflow -> _state := ComputationalErrorState;(_state = NominalState) |- OutOfRange -> _state := ComputationalErrorState;(_state = ComputationalErrorState) |- OutOfRange -> _state := ComputationalErrorState;(_state = ComputationalErrorState) |- RecoverEvent -> _state := NominalState;assertMul^r = (if (_state = NominalState) then (if ((Mul^o1 * Mul^o2) > 42949676) then 0 else (Mul^o1 * Mul^o2)) else 0);init_state := NominalState;edon34
Summary – key points1. Repository of Components Reusability2. Hierarchy / Classification not Partonomy (subcomponent)3. Ontology to annotation of components / associatethem with Error <strong>Model</strong>s.4. Combine EA to BA States, Events and Transitions.Use BA to specify, describe functional behaviour ofComponents.5. Trans<strong>for</strong>mation to Altarica <strong>for</strong> <strong>Safety</strong> Analysis35
Next Steps• Develop the system• Validate with industrial case studies(Components and Systems).36
End – Q&AThank you37