This application claims the benefit of EP 14198001.1, filed on Dec. 15, 2014, which is hereby incorporated by reference in its entirety.
The present embodiments relate to automated recertification of a safety critical system with at least one altered functionality.
A safety critical system is a system where failure or malfunction may result in damages of the equipment or where failure or malfunction may result in injuring people. Design methods for designing a safety critical system include probabilistic risk assessment, failure mode and effect analysis including fault tree analysis. Fault tree analysis offers the decomposition of the system into modules. Fault tree analysis is a deductive procedure used to determine various combinations of hardware and software failures as well as human errors that may cause undesired events referred to as top events at the system level. Complex technical systems may include a plurality of hardware and/or software components. An area where the development of safety analysis models is provided is safety critical cyberphysical systems. These cyberphysical systems include loosely coupled embedded systems. The alignment of the embedded systems is unclear at design time, and possible configurations at design time are almost infinite. Each embedded system forming part of a cyberphysical system may be reused in many different configurations. For such complex systems, a safety critical function may be certified automatically at runtime to assure a safe operation.
The scope of the present invention is defined solely by the appended claims and is not affected to any degree by the statements within this summary.
The present embodiments may obviate one or more of the drawbacks or limitations in the related art. For example, a method and an apparatus that allow automated recertification of a safety critical system (e.g., a safety critical cyberphysical system with altered functionality at runtime) are provided.
According to a first aspect, a method for automated recertification of a safety critical system with at least one altered functionality includes providing a failure propagation model of the safety critical system. The method also includes updating the failure propagation model of the safety critical system according to the altered functionality using inner port dependency traces between inports and outports of a failure propagation model element representing the altered functionality, calculating top events of the updated failure propagation model, and comparing the calculated top events with predetermined system requirements to recertify the safety critical system.
In one embodiment of the method according to the first aspect, the failure propagation model of the safety critical system includes a component fault tree model having component fault tree elements related to corresponding components of the safety critical system.
In a further embodiment of the method according to the first aspect, the component fault tree element includes output failure modes related to outports of the component fault tree element and input failure modes related to inports of the component fault tree element.
In another embodiment of the method according to the first aspect, the failure propagation model element representing the altered functionality is inserted into the failure propagation model of the safety critical system.
In a further embodiment of the method according to the first aspect, each inner port dependency trace indicates a possible dependency between the respective inport and outport of the failure propagation model element representing the altered functionality of the safety critical system.
In a further embodiment of the method according to the first aspect, the safety critical system with at least one altered functionality includes additional system components and/or replaced system components represented by corresponding failure propagation model elements.
In a further embodiment of the method according to the first aspect, if the calculated top events match with the predetermined system requirements, the safety critical system with the altered functionality is successfully recertified and implemented.
One or more of the present embodiments provide, according to the second aspect, a recertification apparatus for automatic recertification of a safety critical system with altered functionality. The apparatus includes a database storing a failure propagation model of the safety critical system. The apparatus also includes a calculation unit (e.g., a processor) configured to update the stored failure propagation model with at least one failure propagation model element representing the altered functionality of the safety critical system and including inner port dependency traces between inports and outports of the failure propagation model element. The calculation unit is further configured to compare calculated top events of the updated failure propagation model with predetermined system requirements to certify or recertify the safety critical system.
In one embodiment of the recertification apparatus according to the second aspect, the failure propagation model of the safety critical system includes a component fault tree model having component fault tree elements related to corresponding components of the safety critical system.
In an embodiment of the recertification apparatus according to the second aspect, the component fault tree element includes output failure modes related to outports of the component fault tree element and input failure modes related to inports of the component fault tree element.
In yet another embodiment of the recertification apparatus according to the second aspect, the calculation unit is configured to insert the failure propagation model element representing the altered functionality into the failure propagation model of the safety critical system.
In a further embodiment of the recertification apparatus according to the second aspect, each inner port dependency trace between an inport and an outport of the failure propagation model element representing the altered functionality indicates a possible dependency between the respective inport and outport of the failure propagation model element.
In a further embodiment of the recertification apparatus according to the second aspect, if the calculated top events match with the predetermined system requirements, the safety critical system with altered functionality is successfully certified or recertified by the calculation unit and implemented.
One or more of the present embodiments provide, according to the third aspect, a safety critical system implemented after the recertification apparatus according to the second aspect has certified or recertified the safety critical system.
In an embodiment of the safety critical system according to the third aspect, the safety critical system with altered functionality includes additional and/or replaced hardware or software components.
The recertification apparatus 1 according to one or more of the present embodiments, as illustrated in
Safety critical systems such as a cyberphysical safety critical system, as illustrated in
For example, in a vehicle including a plurality of hardware and software components, a hardware component may be added to the complex system or replaced by another component. Further, software components of the complex system may be added, or existing software components may be updated to provide additional or altered functionality. In one embodiment, the calculation unit 3 is configured to insert automatically a failure propagation element representing the altered functionality into the stored failure propagation model of the safety critical system. Each inner port dependency trace between an inport and an outport of the inserted failure propagation model element representing the altered functionality indicates a possible dependency between the respective inport and outport of the failure propagation model element. If the calculated top events match with predetermined system requirements, the safety critical system with altered functionality is successfully recertified by the recertification apparatus 1 and may be implemented or further developed. In one embodiment, the certification or recertification of the safety critical system is performed automatically at runtime of the safety critical system to provide a safe and continuous operation of the safety critical system.
In act S1, a failure propagation model of the safety critical system is provided. The failure propagation model of the safety critical system may be stored in a database or a memory such as the database 2 of the recertification apparatus 1 illustrated in
In act S2, the failure propagation model of the safety critical system is updated according to the altered functionality using inner port dependency traces between inports and outports of a failure propagation model element representing the altered functionality.
In act S3, top events of the updated failure propagation model are calculated.
In act S4, the calculated top events are compared with predetermined system requirements to recertify the safety critical system. The successfully recertified safety critical system may be implemented. The failure propagation model of the safety critical system used by the method shown in
For fault tree analysis, fault tree elements are related to development artifacts and may be reused along with the reused development artifact. Modular or compositional safety analysis methodologies such as component fault trees as specified in Bernhard Kaiser, Peter Liggesmeyer and Oliver Mäckel: “A new component concept for fault trees” in SCS, 03: Proceedings of the 8th Australian workshop on safety critical systems and software, pages 37-46, Darlinghurst, Australia, 2003, Australian Computer Society, Inc., or HipHops, as described by Yiannis Papadopoulos and John A. McDermid: “Hierarchically Performed Hazard Origin and Propagation Studies” in Computer Safety, Reliability and Security, 1999, may be used to ease adoption of changes for existing development artifacts by constraining the adoption activities for safety to the artifacts that require changes and provide benefits for an automated proof of the safety critical system.
The method and apparatus according to one or more of the present embodiments provide automation to fill empty safety analysis artifacts. Components or artifacts that are developed from scratch or a new safety critical system to be developed and which did not exist in any former safety critical system require the development of safety analysis models to be integrated in the existing failure propagation model of the safety critical system for a system-wide analysis at early stages of the development or planning of the new safety critical system.
With the method and apparatus according to one or more of the present embodiments, empty safety analysis artifacts are automatically filled up to enable a fuzzy but rapid analysis of the entire safety critical system at a very early development stage if safety analysis models exist at least for some development artifacts. The method and apparatus according to one or more of the present embodiments also allow an automated certification at runtime of the safety critical system. The method and apparatus according to one or more of the present embodiments use inner port relations to fill up safety analysis models on component fault trees of components that do not include a safety analysis model.
Ports are interfaces that allow joining subcomponents of a system together. To preserve the direction of gates, two types of ports may be distinguished (e.g., inports and outports). In a component fault tree, CFT, each component may be stored independently of each other so that the different components of the system may be developed by different people. Further, each component of the system is modeled only once and may be reused as often as needed. Component fault trees may be described by a set of Boolean functions, with each one belonging to one output port. Each function maps the input port and the internal events of the respective component to a Boolean term assigned to an output port. Inports and outports of a single component are related to each other. The developer may relate an outport to an inport of a component if the output of the outport is dependent on the input from the inport.
A component fault tree is a Boolean model associated to system development elements such as components including hardware and/or software components of the safety critical system. Similar to conventional fault trees, a component fault tree may be used to model a failure behavior of a safety critical system. This failure behavior is used to document that a system is safe and may also be used to identify drawbacks of the design of the respective safety critical system.
As illustrated in the meta model of
Each component fault tree may be transformed to a classic fault tree by removing the input failure mode elements and the output failure mode elements.
With the method and apparatus according to one or more of the present embodiments, inner port dependency traces are used to automatically generate missing safety analysis model elements or component fault trees.
With C=c1, . . . , cn being the set of components of a system, CFT=cft1, . . . , cftm∪ϕ is the set of component fault trees with
C{tilde over (F)}T(c)=cft with c∈C and cft∈CFT
with
IN(c)=in1, . . . ,ini, and OUT(c)=out1, . . . ,outj
being the in- and outports of a component c.
is the set of all possible port connections, and
CON⊆
is the set of actual port connections modeling the data flow from the outport of a component to the inport of another component.
is the set of all possible inner port dependency traces of a component c, with
TRACE(c)⊆
forming the actual inner port dependencies of the component c. For the exemplary system illustrated in
C=c1,c2,c3,c4,c5 (1)
IN(c1)=IN(c2)={ } (2)
IN(c3)=p2,p8 (3)
IN(c4)=p4 (4)
IN(c5)=p6 (5)
OUT(c1)=p1 (6)
OUT(c2)=p7 (7)
OUT(c3)=p3,p5 (8)
OUT(c4)=OUT(c5)={ } (9)
CONN=(p1,p2),(p3,p4),(p7,p8),(p5,p6) (10)
TRACE(c1)=TRACE(c2)={ } (11)
TRACE(c4)=TRACE(c5)={ } (12)
TRACE(c3)=(p2,p3),(p2,p5),(p8,p5). (13)
If component c includes a component fault tree, then
C{tilde over (F)}T(c)=cft,cft≠ϕ.
If component c has input and output failure modes, then
IFM(in)≠{ } and OFM(out)≠{ }
for an import in∈IN(c) and an outport out∈OUT(c). In the example system, as depicted in
OFM(p1)=A,B (14)
OFM(p7)=C,D (15)
OFM(p3)=OFM(p5)={ } (16)
IFM(p2)=IFM(p8)={ } (17)
IFM(p4)=A,B (18)
IFM(p6)=A,B,C,D. (19)
For a component c that has no component fault tree,
C{tilde over (F)}T(c)=ϕ.
If all components c have component fault trees, CFT, and the model is used in a proper way, all input and output failure modes may be connected with each other by using the connections defined in CON. If one component has no component fault tree, it is unclear how the output failure modes that came from other components propagate through the component with no component fault tree. If a component c has no component fault tree, and one inport in∈IN(c) receives information from the outport out′ of another component c′ with
C{tilde over (F)}T(c′)=cft′,cft′≠ϕ.
and (out′, in)∈CON, a conventional system-wide fault tree analysis may not be performed; there is no component fault tree, CFT, that indicates how the output failure modes OFM (out′) propagate to the outports OUT(c) of the respective component c. In the exemplary system shown in
With the method according to one or more of the present embodiments, inner port dependency traces TRACE(c) of a component c that has no component fault tree are used. If there are outports of c that have an inner dependency trace with in,
o1, . . . ,ok⊆OUT(c) and (in,oi)∈TRACE for i=1, . . . ,k.
The inner port dependency traces express that the output of the outports o1, . . . , ok depend on the input provided by the inport in. Vice versa, the other outputs of c, o1, . . . , ok∩OUT(c) are independent from the input provided by inport in. Without the information about the port dependencies, only a worst case scenario may be assumed for the failure propagation. The worst case assumption may be that if any failure mode is activated at one of the inports, all failure modes of all outports are active. With the inner port dependency, this worst case scenario may be isolated to the ports that depend on the port that has an active failure mode by propagating all provided output failure modes from OFM (out′) of component c′ to the dependent outports of c with
OFM(oi)=OFM (out′),i=1, . . . ,k.
In the example system, as depicted in
TRACE(c3)=(p2,p3),(p2,p5),(p8,p5)
may be used to complete the data model.
(p2,p3)∈TRACE(c3)→OFM(p3)=A,B (20)
(p2,p5),(p8,p5)∈TRACE(c3)→OFM(p5)=A,B,C,D. (21)
may be set.
Depending on the application or the context in the system, either all failure modes of the dependent outports o1, . . . , ok of a component c are active if one of the output failure modes OFM(out′) is active, or only the failure mode that has the same type is active. For example, if a failure mode of OFM(out′) models the situation that a signal is too late, the inner port dependency trace may be used to mark all dependent outputs as late if this failure mode is active. In some situations, however, the failure type may change in a component (e.g., a delayed signal may causes an erroneous output).
It is to be understood that the elements and features recited in the appended claims may be combined in different ways to produce new claims that likewise fall within the scope of the present invention. Thus, whereas the dependent claims appended below depend from only a single independent or dependent claim, it is to be understood that these dependent claims can, alternatively, be made to depend in the alternative from any preceding or following claim, whether independent or dependent, and that such new combinations are to be understood as forming a part of the present specification.
While the present invention has been described above by reference to various embodiments, it should be understood that many changes and modifications can be made to the described embodiments. It is therefore intended that the foregoing description be regarded as illustrative rather than limiting, and that it be understood that all equivalents and/or combinations of embodiments are intended to be included in this description.
Number | Date | Country | Kind |
---|---|---|---|
14198001 | Dec 2014 | EP | regional |
Number | Name | Date | Kind |
---|---|---|---|
4870575 | Rutenberg | Sep 1989 | A |
7913232 | Erkkinen | Mar 2011 | B2 |
8015550 | Berenbach | Sep 2011 | B2 |
8457996 | Winkler | Jun 2013 | B2 |
8831926 | Van der Velden | Sep 2014 | B2 |
10095994 | Winkler | Oct 2018 | B2 |
20020049625 | Kilambi | Apr 2002 | A1 |
20020193920 | Miller | Dec 2002 | A1 |
20030028823 | Kallela | Feb 2003 | A1 |
20030070108 | Groen | Apr 2003 | A1 |
20040011325 | Benson | Jan 2004 | A1 |
20050015217 | Weidl | Jan 2005 | A1 |
20050036162 | Edge | Feb 2005 | A1 |
20050043922 | Weidl | Feb 2005 | A1 |
20050049988 | Dahlquist | Mar 2005 | A1 |
20050281456 | Garvey | Dec 2005 | A1 |
20060072265 | Bucella | Apr 2006 | A1 |
20060072480 | Deval | Apr 2006 | A1 |
20060085108 | Grier | Apr 2006 | A1 |
20060241931 | Abu el Ata | Oct 2006 | A1 |
20070050178 | Linzey | Mar 2007 | A1 |
20080255682 | Zhao | Oct 2008 | A1 |
20090083734 | Hotra | Mar 2009 | A1 |
20090113247 | Gofuku | Apr 2009 | A1 |
20100100251 | Chao | Apr 2010 | A1 |
20100179918 | Meunier | Jul 2010 | A1 |
20100317420 | Hoffberg | Dec 2010 | A1 |
20120317058 | Abhulimen | Dec 2012 | A1 |
20130166135 | Dunsdon | Jun 2013 | A1 |
20130301073 | Niimura | Nov 2013 | A1 |
20130337867 | Brennan | Dec 2013 | A1 |
20150088476 | Guo | Mar 2015 | A1 |
20150142402 | Ramesh | May 2015 | A1 |
20170023935 | Armbruster | Jan 2017 | A1 |
20170185971 | Masuko | Jun 2017 | A1 |
Entry |
---|
Pilot Simha, “What Is a Fault Tree Analysis”, Quality Progress, 3/02 found at http://asq.org/quality-progress/2002/03/problem-solving/what-is-a-fault-tree-analysis.html. |
Jamboti et al., “Modeling and Analysis of State/Event Fault Trees using ESSaRel”, DEPEND 2013: The Sixth International Conference on Dependability, ISBN: 978-1-61208-301-8, 2013. |
Skrobanek et al., “Analysis of Timing Requirements for Intrusion Detection and Prevention using Fault Tree with Time Dependencies”, Mar. 22, 2011, DOI: 10.5772/15609. |
Lo et al, “Reliability and Sensitivity Analysis of Embedded Systems with Modular Dynamic Fault Trees”, DOI: 10.1109/TENCON.2005.300968, TENCON 2005-2005 IEEE Region 10 Conference, Dec. '05. |
Paul Mason, “On Traceability for Safety Critical Systems Engineering”, Proceedings of the 12th Asia-Pacific Software Engineering Conference (APSEC'05), 0-7695-2465-6/05, 2005. |
Liggesmeyer et al., “Automatic Reliability Analysis of Electronic Designs using Fault Trees”, in 13. Workshop Testmethoden und Zuverlässigkeit von Schaltungen und Systemen, 2001. |
Karanki et al., “Dynamic Fault Tree analysis using Monte Carlo simulation in probabilistic safety assessment”, Article in Reliability Engineering [?] System Safety, DOI: 10.1016/j.ress.2008.09.007, Apr. 2009. |
Helmer et al., A Software Fault Tree Approach to Requiments Analysis of an Intrusion Detection System, Iowa State University & Jet Propulsion Laboratory, Oct. 2000. |
Steele et al., “Analysis of Critical System Certification”, 2014 IEEE 15th International Symposium on High-Assurance Systems Engineering, 978-1-4799-3466-9/14 (Year: 2014). |
Ebbah, “Deploying Artificial Intelligence Techniques in Software Engineering”, American Journal of Undergraduate Research vol. 1 No. 1, (Year: 2002). |
Mason, “On Traceability for Safety Critical Systems Engineering”, APSEC '05: Proceedings of the 12th Asia-Pacific Software Engineering Conference, ISBN: 978-0-7695-2465-8 (Year: 2005). |
Kaiser B. et al: “A New Component Concept for Fault Trees,” SCS, 03: Proceedings of the 8th Australian workshop on safety critical systems and software, pp. 37-46, 2003. |
Papadopoulos Y. et al: “Hierarchically Performed Hazard Origin and Propagation Studies,” Computer Safety, Reliability and Security, 1999. |
Number | Date | Country | |
---|---|---|---|
20160171506 A1 | Jun 2016 | US |