US8620873B2 - Method for supporting a safety-oriented system - Google Patents

Method for supporting a safety-oriented system Download PDF

Info

Publication number
US8620873B2
US8620873B2 US12/808,370 US80837008A US8620873B2 US 8620873 B2 US8620873 B2 US 8620873B2 US 80837008 A US80837008 A US 80837008A US 8620873 B2 US8620873 B2 US 8620873B2
Authority
US
United States
Prior art keywords
safety
software components
critical software
critical
possibility
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related, expires
Application number
US12/808,370
Other languages
English (en)
Other versions
US20100313075A1 (en
Inventor
Efthimios Liakos
Roland Porsch
Stefan Rothbauer
Martin Rothfelder
Michael Zanzinger
Hartmut Zeilmann
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Siemens AG filed Critical Siemens AG
Assigned to SIEMENS AKTIENGESELLSCHAFT reassignment SIEMENS AKTIENGESELLSCHAFT ASSIGNMENT OF ASSIGNORS INTEREST (SEE DOCUMENT FOR DETAILS). Assignors: LIAKOS, EFTHIMIOS, ROTHFELDER, MARTIN, PORSCH, ROLAND, ROTHBAUER, STEFAN, ZANZINGER, MICHAEL, ZEILMANN, HARTMUT
Publication of US20100313075A1 publication Critical patent/US20100313075A1/en
Application granted granted Critical
Publication of US8620873B2 publication Critical patent/US8620873B2/en
Expired - Fee Related legal-status Critical Current
Adjusted expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING OR CALCULATING; COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Prevention of errors by analysis, debugging or testing of software
    • G06F11/3604—Analysis of software for verifying properties of programs
    • G06F11/3608—Analysis of software for verifying properties of programs using formal methods, e.g. model checking, abstract interpretation

Definitions

  • At least one embodiment of the present invention generally relates to a method for supporting a safety-oriented system.
  • One of the objectives of a safety-relevant or safety-oriented system is to guarantee a reliable and correct functioning of software components which are involved in safety-critical functions.
  • transport area e.g. railways or aircraft
  • errors can typically lead to a system or a device (of a vehicle for example) becoming unmanageable, with the concomitant serious consequences for the passengers.
  • SIL safety integrity level
  • a software component does not have any Safety Integrity Level (SIL) if it is considered in isolation from a safety-related system. If the software component is integrated into a system, the software component can be suitable for supporting safety functions for a specific SIL. This depends on how the software component was specified, developed, implemented and/or verified.
  • SIL Safety Integrity Level
  • the software safety integrity level n or SSIL n is specified as follows: Software which has been developed using appropriate techniques and measures, with the techniques and measures ensuring that the software meets the requirements for systematic failures of a specific safety function X for SSIL n.
  • a software safety integrity level is not a property of systems, subsystems or components.
  • the above specification can be interpreted such that the software system, software subsystem or the software components can be used at integrity levels up to SSIL 1, 2, 3 or 4. This alone is not sufficient however to establish a safety function for the required SSIL.
  • the software safety integrity level of a subsystem determines the highest SSIL which can be made to apply for a safety function using this subsystem.
  • Safety-relevant or safety-oriented systems having software components have safety requirements imposed upon them by the predetermined rules or standards which describe how a safe behavior of the system is guaranteed and how the occurrence of danger situations can be prevented.
  • the safety relevance of technical systems is derived from the maximum safety requirement on the functions made available by these systems. If one considers the use of software in safety-oriented systems, then as a rule only a small part of safety functions are taken over by the software. I.e. the software components used are to be subdivided into safety-relevant or safety-critical software components on the one hand and non-safety-relevant or non-safety-critical software components on the other hand. Since there is the possibility that the non-safety-critical software components can impinge on the safety of the safety-critical software components, i.e. they can mutually influence each other, these are developed to be just as safe as the safety-critical software components.
  • non-safety-critical software component or software function may not negatively influence the reliable or correct execution of a safety-critical software component or software function.
  • This influencing occurs as so-called feedback.
  • This feedback can be suppressed by an explicit separation between the function classes (safety-critical, or non-safety critical) on a system. This separation is to be understood as absence of a feedback from non-safety-critical software components or functions to safety-critical software components or functions.
  • non-safety-critical software components or functions with the same level of safety as the safety-critical software components or functions leads however to restrictions in the non-safety-critical software components (e.g. in respect of their functionality or coding guidelines) and to great expense in relation to the development of the non-safety-critical software components to be used.
  • At least one embodiment of the invention provides for an improved support for a safety-oriented system having safety-critical software components and non safety-critical software components.
  • supporting the safety-oriented system especially includes verifying and/or ensuring absence of feedback. I.e. the suppression of a mutual influencing of a safety-critical software component and a non-safety-critical software component and evidence of the fact that such mutual influencing is excluded or is at least excluded up to the specified possible maximum.
  • a method for supporting a safety-oriented system with the safety-oriented system having safety-critical software components and non-safety-critical software components and with the method comprising:
  • the present invention makes it possible to use formal methods and techniques in software and system development, with the correctness of a software design, an analysis or design model being able to be shown in relation to functional safety requirements.
  • the method also makes it possible to impose the highest safety demands on a safety-relevant or safety-oriented system and to guarantee said demands.
  • the identification features determination of a subset of technical system resources of an area of activity of the safety-critical software component and of an area of activity of the non-safety-critical software component. In this way a general and thereby reusable identification of the possibilities of mutual influencing or ensuring absence of feedback is permitted which can the at same time also be employed explicitly.
  • the identification features evaluation of at least one technical system resource from the subset of technical system resources in respect of the possibility of mutual influencing.
  • This enables one possible resource of the technical system resources determined, e.g. main memory, file system, software resource, indication mechanism or communication means) to be investigated more precisely and to be marked accordingly in respect of their safety system relevance.
  • the definition of the set of technical measures can be undertaken by analyzing the possibility of mutual influencing.
  • the definition of a set of technical measures can be undertaken based on the evaluation of the at least one technical system resource.
  • the definition of the set of technical measures can feature different types of technical measure in accordance with at least one embodiment of the present invention, which makes a flexible implementation of at least one embodiment of the present invention possible. In such cases a mixed form or a combination of the different types of technical measure is also possible.
  • the definition of a set of technical measures can feature specification of a configuration measure.
  • the definition of the set of technical measures can feature an analysis using software techniques of the safety-critical software components in respect of the possibility of mutual influencing.
  • the definition of the set of technical measures can feature specification of an application for preventing the possibility of mutual influencing.
  • At least one non-safety critical software component of the set of non-safety-critical software components of the safety-oriented system can be an open source software component.
  • an open source software component can be used as the non-safety-critical software components for which the possibility of mutual influencing is identified and in respect of which a set of technical measures is defined.
  • COTS commercial off-the-shelf
  • open source software is used in safety systems however, the requirements of the safety standards must be met. As already mentioned this has not been the case previously.
  • At least one embodiment of the present invention offers a formal method of operation for verifying and ensuring predetermined safety-relevant standards.
  • evidence of the absence of feedback is provided for when the respective (non-safety-critical) components are used in a corresponding project.
  • the evidence is guaranteed for non-safety-critical software components which can include COTS or open source software components.
  • the evidence of the absence of feedback is produced in accordance with the existing safety standards using formal methods and techniques.
  • constructive, analytical and/or applicative measures make it possible to prevent threats which, when they occur, have a negative influence on the execution of the safety-critical functions in the system.
  • At least one embodiment is directed to a device which is designed to support a safety-oriented system, with the safety-oriented system having safety-critical software components and non-safety-critical software components and with the device been configured:
  • At least one embodiment is directed to a system which is designed to execute steps of the method outlined above and explained in greater detail below.
  • At least one embodiment is carried out by a computer program with the computer program having coding which is configured to execute the steps of at least one embodiment of the method outlined above and explained in greater detail below.
  • the computer program can be stored on a data carrier.
  • the above-mentioned task is achieved by way of a safety-oriented system having safety-critical software components and non-safety-critical software components and which is configured to ensure an absence of feedback to the safety-critical components by executing the steps of the method outlined above and explained below in greater detail.
  • a safety-oriented system having safety-critical software components and non-safety-critical software components and which is configured to ensure an absence of feedback to the safety-critical components by executing the steps of the method outlined above and explained below in greater detail.
  • at least one open source software component or COTS can be embodied in this case as at least one non-safety-critical software component.
  • FIG. 1 shows possible interactions between software components of a safety-oriented system in accordance with an example embodiment of the present invention
  • FIG. 2 shows an interface of a safety-critical software component and a non-safety-critical software component in accordance with an example embodiment of the present invention
  • FIG. 3 shows a feedback barrier implemented or embodied in accordance with an example embodiment of the present invention.
  • FIG. 4 shows a block diagram of an analysis of a source code as an applicative measure in accordance with an example embodiment of the present invention.
  • FIG. 1 shows possible interactions between software components of a safety-oriented system in accordance with an example embodiment of the present invention.
  • Described below is the verification and the ensuring of absence of feedback when an open source software component is used, namely the SQLite embedded database as a message archive, standard EN50128 with formal methods and techniques in accordance with an example embodiment of the present invention.
  • the message archive is involved in the execution of non-safety-critical functions. These can threaten to create feedback to the correct and reliable execution of safety-critical functions in the safety-oriented system. Constructive, analytical and applicative measures prevent these threats (which have arisen through the mutual influencing of the safety-critical and non-safety-critical software components) negatively influencing the execution of the safety-critical functions in the system.
  • the software components 101 , 111 , 12 , 13 and 14 are divided up into three function classes.
  • safety-critical (safety-relevant) software components 12 , 13 a safety-critical or safety-relevant function is generally implemented technically using software by collaboration, i.e. by software components working together in a system. This occurs regardless of whether the safety function is executing in continuous mode or in on-demand mode.
  • the collaborating components thus belong to the safety group from which the software safety integrity level (SSIL) results.
  • All software components 12 , 14 which are involved in the execution of a safety-critical functionality belong to the function class of safety-critical software components with a corresponding SSIL.
  • Monitoring software components 13 represent self-test and monitoring/diagnostic software components. These have the task of checking system resources for random hardware faults.
  • Such software components can typically be a monitor adapter in collaboration with an SEP (Safety Environment Processor) on a system server for example.
  • SEP Safety-critical software component
  • monitor adapter would be the non-safety-critical software component.
  • All software components 13 which are involved in monitoring and diagnosis of hardware belong to the function class of monitoring software components. These components too may not be influenced by other software components.
  • non-safety-critical software components 101 , 111 Those software components which are involved in non-safety-critical functionalities are regarded as non-safety-critical software components 101 , 111 . These software components belong to SSIL 0 so to speak.
  • the message archive belongs to this class in accordance with the present example embodiment.
  • the relationships between the software components 101 , 111 , 12 , 13 , 14 are shown by arrows in FIG. 1 .
  • the dotted-line arrows originating from the monitoring software components 13 point to the software components 12 , 14 , 101 , 111 which are monitored by the monitoring software component 13 .
  • the solid arrows indicate that collaboration is taking place between the respective software components 12 and 101 , 12 and 14 .
  • the dashed-line arrows leading from the non-safety-critical software component 101 to the software components 12 , 13 , 14 and 111 indicate those components on which the non-safety critical software component 101 (here typically an SQLite Embedded Database as a message archive) has a feedback effect. I.e.
  • a mutual influencing in accordance with the present invention includes both influencing in both directions (influencing of a non-safety-critical software component 101 by a safety-critical software component 12 , 13 and 14 and influencing of a safety-critical software component 12 , 13 and 14 by a non-safety-critical software component 101 ) and also influencing in only one direction, (i.e. influencing of a non-safety-critical software component 101 by a safety-critical software component 12 , 13 and 14 or influencing of a safety-critical software component 12 , 13 and 14 by a non-safety-critical software component 101 ).
  • the non-safety-critical components 101 and 111 each have an interface 10 , 11 in order to interact, to communicate and/or to collaborate with the safety-critical software components 12 , 13 , 14 .
  • These interfaces 10 , 11 are however not absolutely necessary, the present invention can be implemented and executed even without using such interfaces 10 , 11 .
  • Each software component 101 , 111 , 12 , 13 , 14 has an effective area in a system.
  • An effective area is an area of the safety-oriented system in which all within the framework of which the respective software component 101 , 111 , 12 , 13 , 14 is effective, i.e. works, communicates, interacts and/or collaborates or acts with other components of the system. Since a safety-related or safety-oriented system consists of a number of software components 101 , 111 , 12 , 13 , 14 , each with its own effective area, there is a potential danger of these components influencing each other during the execution of a function. In such cases the influencing occurs via the interfaces of the effective areas of the software components 101 , 111 , 12 , 13 , 14 . This means that there is the danger of feedback in the execution of a function to the execution behavior of a safety function so that the correctness and reliability of this safety group can no longer be guaranteed in accordance with the associated safety integrity level.
  • these interfaces form the jointly-used resources of the operating system or of the framework lying above it which provide the execution framework of the SW components.
  • feedback between the software components 101 , 111 , 12 , 13 , 14 typically occurs via the main memory, the file system, kernel resources or via the communication mechanisms within a processor or even across processors.
  • FIG. 2 shows an example of an interface 22 (i.e. a subset of technical system resources) of the effective areas 21 and 20 of a safety-critical software component 211 and a non-safety-critical software component 210 (e.g. an SQLite Embedded database as message archive).
  • a safety-critical software component 211 e.g. an SQLite Embedded database as message archive.
  • non-safety-critical software component 210 e.g. an SQLite Embedded database as message archive.
  • a type of barrier is constructed in order to suppress certain influences between safety-critical and non-safety-critical software components of the safety oriented system or to avoid them and thereby to prevent any feedback.
  • the so-called barrier or shell is designed to capture and if necessary to remove the various threats which arise from the respective software components. This enables the necessary measures to be taken by the safety-oriented system in order to capture the feedback.
  • a disruptive event which might typically cause no more main memory to be available
  • the execution of a non-safety-critical function affected by this event can be ended by the system (operating system or framework).
  • the events can be captured or identified and the execution process of the message archive can be ended in order to guarantee the operational integrity of the safety-oriented system.
  • FIG. 3 shows a feedback barrier implemented or designed in accordance with the exemplary embodiment of the present invention.
  • the components of FIG. 3 correspond to the components of FIG. 1 .
  • the monitoring and collaboration relationships which are shown as dotted-line or solid arrows are also provided or embodied between the software component as in the original diagram.
  • the inventively used feedback barrier or shell 30 has the effect of capturing the feedback from the non-safety-critical software components 101 to the safety-critical software components 12 , 13 and 14 , i.e. of ensuring absence of feedback.
  • the capturing of the feedback is represented by the restriction of the feedback relationships which are shown as dashed-line arrows, by the feedback barrier 30 .
  • the non-safety-critical software component 101 is isolated by establishing a runtime shell as a feedback barrier 30 .
  • the measures in this case can be divided into constructive, applicative and analytical measures.
  • Constructive measures are a type of preventive measures which can already be taken into consideration during configuration so that no feedback to other software components 12 , 13 , 14 , 111 can arise from a non-safety-critical software component 101 in a safety-oriented system. In this case is tried and tested operating system mechanisms for establishing a separate runtime shell of the non-safety-critical software component can be used. Accordingly a runtime shell 30 can be configured or implemented for example by appropriate definition or embodying of user rights, file system, partitions etc.
  • Analytical or verification measures have the objective of testing, evaluating and (external) verification of the absence of feedback of the items under test. This can for example be undertaken by an explicit checking of the software code, with a series of software test tools and methods able to be used for this purpose.
  • Applicative measures implement prevention of the feedback to other software components in the system using programming steps (e.g. by operating system API calls to restrict the main memory).
  • programming steps e.g. by operating system API calls to restrict the main memory.
  • standardized software tools oriented to the respective problem can be used which are constructed for example based on the experience of experts.
  • an SQLite embedded database in the form of a message archive is used as the non-safety-critical software component.
  • identified possibilities or interfaces i.e. subset of technical system resources
  • SQLite embedded database in the form of a message archive a set of technical measures for preventing the possibility of influencing and thereby of feedback is defined.
  • Archive is used by potentially safety-critical processes (e.g. system map) and does not in itself have any safety-critical function.
  • a constructive measure such as setting a defined hard system limit for the use of main memory can be defined for example.
  • an evaluation in respect of the main memory can reveal that a possible threat for the safety-oriented system can occur in the overwriting of files by other processes or software components 12 , 13 , 14 , 111 .
  • a constructive measure such as the realization of the SQLite database can be defined as an autonomous container in the system framework.
  • the SQLite database as archive thus becomes a separate operating system process. This means that the influencing of other processes or software components 12 , 13 , 14 , 111 by the SQLite database via the main memory is not possible.
  • an evaluation in respect of the main memory can reveal that a possible threat for the safety-oriented system can occur in accidental writing into another partition.
  • a constructive measure such as starting the SQLite database as an archive process with a restricted user rights can be defined. This means that no write accesses to other partitions of other processes or software components 12 , 13 , 14 , 111 are allowed.
  • an evaluation in respect of communication reveals that a possible threat for the safety-oriented system can occur in an undesired link to other processes or system components 12 , 13 , 14 , 111 by the SQLite database as archive 101 .
  • the following analytical measure can be defined: Calls (e.g. bind, socket, listen or accept under Linux), which result in a communication should be prevented or avoided as far as possible (e.g. provided other communication paths are provided). This can be implemented accordingly by an application.
  • the corresponding source code such as shown in FIG. 4 for example, can be analyzed for this purpose.
  • a configuration and compilation of the non-safety-critical software components here the SQLite database as archive
  • predetermined switches can be carried out.
  • step 42 and analysis of the external symbol dependencies of the program of the non-safety-critical software components and thus of the SQLite database as archive is undertaken.
  • an interrogation 43 is performed in which it is established whether external symbol dependencies are present. If no external symbol dependencies are present (indicated by “N”), the analysis of the corresponding source code is ended 44 , i.e. there is no threat in respect of an overlap in the communication between the SQLite database as archive and further software components or processes.
  • SQLite was evaluated as persistence medium under different alternative solutions in accordance with specific selection criteria and selected as the best solution. More details can be found in the decision table below in which possible risks, i.e. feedback or influencing possibilities and the measures defined for these are listed.
  • the feedback to other software components or systems can take place in accordance with the present exemplary embodiment through the use of shared resources between the further software components and the archive component as SQLite database.
  • the shared resources in this case can be:
  • the safety of the shared resources is likewise ensured by corresponding monitoring mechanisms, i.e. that weak points (feedback) to the safety-oriented system is recognized for the shared resources and that there is an appropriate reaction to this if necessary.
  • the archive component may not The archive component is influence the memory area of allowed to run as a service the other software components in a separate service (e.g. by accidentally container since a service overwriting memory etc.) container runs in a separate Linux or Windows process and thereby the memory protection mechanisms of the respective operating system operate.
  • the archive component may not Restrict the available main claim too much main memory, so memory for the archive that for the safety-oriented component via the operating system or for the other system.
  • function setrlimit In Linux for example software components on the with the aid of the API server of the system there is function setrlimit ( ). not enough main memory available and thus a secure functioning of the safety- oriented system is adversely affected.
  • Kernel resources There is the danger of the An analysis of the software SQLite database using code is sensible here. In unrestricted kernel resources. this case it is established Examples of such resources are which, how many and how the typically mutex(es) or file kernel resources are being handles. With file handle used by the SQLite database. there can be a number of “File In such cases the kernel Open” without the resources used by SQLite are corresponding number of “File covered. If necessary the Close” for the SQLite application ensures that database. This means that the these run without feedback. file handler in the kernel runs “full” so that other software components cannot perform any file operations. Re. 4.
  • a “grep” command can be the SQLite database executed on the source code establishing an undesired of SQLite here for example in communication to other SW order to search for such components. keywords as bind, socket etc. In such cases it can be ensured that the SQLite database is not establishing any communication to other software components.
  • An embodiment of the present invention thus relates to support for a safety-oriented system, with the safety-oriented system having safety-critical software components and non-safety-critical software components.
  • An embodiment of the invention identifies the possibility of mutual influencing of a safety-critical software component and a non-safety-critical software component and defines a set of technical measures to prevent the possibility of components influencing each other.
  • an embodiment of the present invention both verifies and also ensures the absence of feedback from non-safety-critical software components to safety-critical software components. This is especially the case when a freely-available software component, e.g. an open source software component, is used as a non-safety-critical component.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Software Systems (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Storage Device Security (AREA)
  • Debugging And Monitoring (AREA)
US12/808,370 2007-12-18 2008-11-12 Method for supporting a safety-oriented system Expired - Fee Related US8620873B2 (en)

Applications Claiming Priority (7)

Application Number Priority Date Filing Date Title
DE102007060814.6 2007-12-18
DE102007060814 2007-12-18
DE102007060814 2007-12-18
DE102008018680 2008-04-14
DE102008018680A DE102008018680A1 (de) 2007-12-18 2008-04-14 Verfahren zum Unterstützen eines sicherheitsgerichteten Systems
DE102008018680.5 2008-04-14
PCT/EP2008/065369 WO2009077271A1 (de) 2007-12-18 2008-11-12 Verfahren zum identifizieren gegenseitiger beeinflussung von softwarekomponenten

Publications (2)

Publication Number Publication Date
US20100313075A1 US20100313075A1 (en) 2010-12-09
US8620873B2 true US8620873B2 (en) 2013-12-31

Family

ID=40690882

Family Applications (1)

Application Number Title Priority Date Filing Date
US12/808,370 Expired - Fee Related US8620873B2 (en) 2007-12-18 2008-11-12 Method for supporting a safety-oriented system

Country Status (4)

Country Link
US (1) US8620873B2 (de)
EP (1) EP2225640A1 (de)
DE (1) DE102008018680A1 (de)
WO (1) WO2009077271A1 (de)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12608237B2 (en) 2022-11-23 2026-04-21 Red Hat, Inc. Detecting and migrating a rogue user application to avoid functional safety interference

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE102013218814A1 (de) * 2013-09-19 2015-03-19 Siemens Aktiengesellschaft Verfahren zum Betreiben eines sicherheitskritischen Systems
CN116644424A (zh) * 2023-07-25 2023-08-25 北京飞龙玥兵科技有限公司 计算装置安全保护方法及系统、电子设备、可读存储介质

Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6470430B1 (en) * 1999-06-17 2002-10-22 Daimlerchrysler Ag Partitioning and monitoring of software-controlled system
US20030014381A1 (en) * 1998-11-11 2003-01-16 John J. Mcmillan Method and system for identifying and resolving software conflicts and computer-readable storage medium having a program for executing the method
US20050283834A1 (en) 2004-06-17 2005-12-22 International Business Machines Corporation Probabilistic mechanism to determine level of security for a software package
US20060206855A1 (en) 2005-03-09 2006-09-14 Biju Nair System and method for conflict identification and resolution
US20070168957A1 (en) 2005-11-08 2007-07-19 Red Hat, Inc. Certifying a software application based on identifying interface usage
US8224791B2 (en) * 2009-09-11 2012-07-17 Sap Ag Information lifecycle cross-system reconciliation
US8285689B2 (en) * 2008-08-04 2012-10-09 Zte Corporation Distributed file system and data block consistency managing method thereof
US8291005B2 (en) * 2008-01-07 2012-10-16 International Business Machines Corporation Providing consistency in processing data streams

Patent Citations (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20030014381A1 (en) * 1998-11-11 2003-01-16 John J. Mcmillan Method and system for identifying and resolving software conflicts and computer-readable storage medium having a program for executing the method
US6470430B1 (en) * 1999-06-17 2002-10-22 Daimlerchrysler Ag Partitioning and monitoring of software-controlled system
US20050283834A1 (en) 2004-06-17 2005-12-22 International Business Machines Corporation Probabilistic mechanism to determine level of security for a software package
US20060206855A1 (en) 2005-03-09 2006-09-14 Biju Nair System and method for conflict identification and resolution
US20070168957A1 (en) 2005-11-08 2007-07-19 Red Hat, Inc. Certifying a software application based on identifying interface usage
US8291005B2 (en) * 2008-01-07 2012-10-16 International Business Machines Corporation Providing consistency in processing data streams
US8285689B2 (en) * 2008-08-04 2012-10-09 Zte Corporation Distributed file system and data block consistency managing method thereof
US8224791B2 (en) * 2009-09-11 2012-07-17 Sap Ag Information lifecycle cross-system reconciliation

Non-Patent Citations (8)

* Cited by examiner, † Cited by third party
Title
Gong Li et al., "Going Beyond the Sandbox: An Overview of the New Security Architecture in the Java Development Kit 1.2", Proceedings of the Usenix Symposium on Internet Technologies and Systems, XX, XX, Dec. 1, 1997, pp. 1-10; Others.
Hill M. G. et al., "Non-Interference Analsysis for Mixed Critically Code in Avionics Systems", Proceedings ASE 2000, 15th IEEE International Conference on Automated Software Engineering, 2000, pp. 257-260; Others.
Hill M. G. et al., "Non-Interference Analysis for Mixed Critically Code in Avionics Systems", Proceedings ASE 2000, 15th IEEE International Conference on Automated Software Engineering, 2000, pp. 257-260. *
Internet: http://www.oracle.com/database/berkeley-db/index.html Feb. 2010; Others.
Internet: http://www.sqlite.org Feb. 2010; Book.
Project FP6-015905 Mobius "Mobility, Ubiquity and Security: D1.1 Report on Resource and Information Flow Security Requirements (Submission date: Mar. 27, 2006, Revision 285, Final Public", Internet Citation, 2006, pp. 1-72 http://mobius.inria.fr/twiki/bin/view/DeliverablesList/WebHome; Others.
Standard EN 50128; ;"Railway Applications-Communications, Signalling and processing systems-Software for railway control and protection systems" Mar. 2001, 104 pages.
Standard IEC 61508;"Functional Safety of electrical /electronic /programmable electronic safety-related systems ," Dec. 1998, 122 pages.

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US12608237B2 (en) 2022-11-23 2026-04-21 Red Hat, Inc. Detecting and migrating a rogue user application to avoid functional safety interference

Also Published As

Publication number Publication date
DE102008018680A1 (de) 2009-07-02
EP2225640A1 (de) 2010-09-08
WO2009077271A1 (de) 2009-06-25
US20100313075A1 (en) 2010-12-09

Similar Documents

Publication Publication Date Title
KR101410099B1 (ko) 단위 테스트 케이스 재사용 기반의 함수 테스트 장치 및 그 함수 테스트 방법
Esper et al. How realistic is the mixed-criticality real-time system model?
Pretschner Defect-Based Testing.
Backes et al. Requirements analysis of a quad-redundant flight control system
US8620873B2 (en) Method for supporting a safety-oriented system
US7493528B1 (en) Resolving conflicts between multiple automation managers in the management of software resources using intention flags
Moukahal et al. Towards a secure software lifecycle for autonomous vehicles
Höller et al. Evaluation of diverse compiling for software-fault detection
Sandgren et al. Software safety analysis to support iso 26262-6 compliance in agile development
US20220067239A1 (en) Computer-implemented method and computerized device for testing a technical system
Wu et al. Ensuring safety of avionics software at the architecture design level: An industrial case study
Scherb et al. CyMed: a framework for testing cybersecurity of connected medical devices
Schulz et al. Strategy for security certification of high assurance industrial automation and control systems
Conmy Safety analysis of computer resource management software
Chiba et al. Formalization and Verification of AUTOSAR OS Standard's Memory Protection
Saha et al. Finding resource-release omission faults in linux
Firesmith Achieving quality requirements with reused software components: Challenges to successful reuse
Feiler Architecture-led safety analysis of the joint multi-role (JMR) joint common architecture (JCA) demonstration system
Obradov et al. A tool for detecting memory interference between AUTOSAR software components of different ASIL
Vismari et al. A practical analytical approach to increase confidence in software safety arguments
Brosgol Safety and security: Certification issues and technologies
Prause et al. Characterizing verification tools through coding error candidates reported in space flight software
Matsuno et al. Consensus building and in-operation assurance for service dependability
Guzman et al. Test4enforcers: Test case generation for software enforcers
Bishop et al. Integrity static analysis of COTS/SOUP

Legal Events

Date Code Title Description
AS Assignment

Owner name: SIEMENS AKTIENGESELLSCHAFT, GERMANY

Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:LIAKOS, EFTHIMIOS;PORSCH, ROLAND;ROTHBAUER, STEFAN;AND OTHERS;SIGNING DATES FROM 20100406 TO 20100413;REEL/FRAME:024643/0758

REMI Maintenance fee reminder mailed
LAPS Lapse for failure to pay maintenance fees

Free format text: PATENT EXPIRED FOR FAILURE TO PAY MAINTENANCE FEES (ORIGINAL EVENT CODE: EXP.)

STCH Information on status: patent discontinuation

Free format text: PATENT EXPIRED DUE TO NONPAYMENT OF MAINTENANCE FEES UNDER 37 CFR 1.362

FP Lapsed due to failure to pay maintenance fee

Effective date: 20171231