The assignee for this patent, patent number 8620873, is
Reporters obtained the following quote from the background information supplied by the inventors: "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.
"When a safety function is executed its reliability and correctness can be influenced by the occurrence of errors. Typically errors such as random hardware faults or systematic design errors can occur in such cases. A possible defect in a processing unit could be cited as an example of a random hardware fault. This produces a malfunction which adversely affects the handling of a device (e.g. of a vehicle) in which the processor unit is employed. Possible design errors can occur even during the development phase because of incorrect implementation of the specification (e.g. modeling or planning). Such errors and similar errors can have serious consequences in safety-relevant systems.
"If the transport area (e.g. railways or aircraft) is considered as an example, such 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. Nor is a permanent adverse effect on the environment beyond the bounds of possibility.
"To ensure functional safety at least one safety requirement is generally specified for each specified safety function, in order to achieve and/or to fulfill a predetermined safety level. Functional safety is then seen is being provided if each specified safety function is executed and for each safety function a desired level of fulfillment is achieved in accordance with the corresponding safety integrity level. It should be noted here that the safety integrity level (SIL) is a property of a safety function and does not relate to a system or to a subsystem. This safety function is realized through a combination of systems however, which consist of software and hardware components. The safety integrity system thus relates to an end-to-end safety function of a safety-related system.
"Like every other component of the safety-oriented system, 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.
"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.
"Thus 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. The enabling or the usability of a subsystem for SSILn (with n=1, 2, 3 or 4) is achieved if the SW subsystem fulfils the requirements of prespecified safety standards (e.g. IEC 61508, EN50128 etc.).
"Furthermore product-liability is also an important aspect as far as safety-relevant or safety-oriented systems are concerned. If a (purchased) product is faulty, under some circumstances claims for damages can also be made. The manufacturer can deny responsibility for the damage if the fault was not present when the product was put into circulation or if the product met predetermined safety expectations and predetermined legal requirements.
"There is currently no legal standard in the European legal system which imposes mandatory requirements on the electronic systems in relation to checking their fault safety or functional safety. However the fact that the electronics sector is becoming ever larger and safety is consequently becoming ever more important means that an alternative was created which guarantees the mostly demanded safety of products here. It is therefore sufficient for the evidence and accordingly an approval of a failsafe characteristic of electronic systems to be available from the responsible authority, (e.g. test certification authority or railway governing board) and the manufacturer's technical service. An approval is given in such cases based on predetermined rules or standards (e.g. IEC 61508, EN50128 etc.).
"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.
"In this case the embodiment of a 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.
"The implementation of the 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.
"Further known procedures again follow the path of separating the safety-critical and non-safety-critical software components by setting up hardware components which have either safety-critical of non-safety-critical software components. In this way a physical separation of the components is achieved. Since these components interact however, the appropriate safe interfaces must be set up. Both the design of the hardware components and also the design of the respective interfaces result in a higher outlay.
"The above-mentioned known way of using software components in safety-oriented systems results in the implemented software being bound into the respective area of application. If one wishes to use implemented software in another way in order to save development costs it is generally only possible with a major effort in conversion, in which case the safety questions have to be asked and checked once more."
In addition to obtaining background information on this patent, VerticalNews editors also obtained the inventors' summary information for this patent: "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. In such cases 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.
"In at least one embodiment, a method is disclosed 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: Identifying a possibility of mutual influencing of a safety-critical software component and a non-safety-critical software component and Defining a set of technical measures for preventing the possibility of influencing.
"In at least one embodiment, 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.
"In accordance with at least one embodiment of the present invention, within the context of identifying the possibility of mutual influencing of a safety-critical software component and a non-safety-critical software component and/or the definition of a set of technical measures to prevent the possibility of influencing can be implemented using formal methods and techniques.
"In accordance with an example embodiment of the present invention, 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.
"In accordance with an example embodiment of the present invention 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.
"In accordance with an embodiment of the present invention, the definition of the set of technical measures can be undertaken by analyzing the possibility of mutual influencing.
"In this case 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.
"In accordance with an example embodiment of the present invention the definition of a set of technical measures can feature specification of a configuration measure.
"Furthermore 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.
"Furthermore the definition of the set of technical measures can feature specification of an application for preventing the possibility of mutual influencing.
"In addition 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. I.e. 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.
"The use of public domain or open source software in safety-oriented systems has been avoided thus far since the public domain or open source software has not been able to be verified as being suitable for the safety-oriented applications.
"For economic reasons companies are often forced nowadays not to develop software components in a system themselves but to opt to reuse existing components. Often the software pool of a company does not contain sufficient software parts to meet all requirements for specific software components in the respective projects oriented towards safety-oriented systems.
"In such cases software components which are bought in (so-called COTS, commercial off-the-shelf) products or can be obtained from the inexhaustible pool of open source software provide a remedy. When COTS (commercial off-the-shelf) or 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. In such cases evidence of the absence of feedback is provided for when the respective (non-safety-critical) components are used in a corresponding project. In particular the evidence is guaranteed for non-safety-critical software components which can include COTS or open source software components. In such cases the evidence of the absence of feedback is produced in accordance with the existing safety standards using formal methods and techniques. In accordance with the present invention, 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: To identify a possibility of a safety-critical software component and a non-safety-critical software component influencing each other; and To define a set of technical measures for preventing the possibility of the components influencing each other.
"Overall the device is configured to execute the steps of the method outlined above and is explained below in greater detail.
"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.
"Furthermore, 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. In this case the computer program can be stored on a data carrier.
"In addition the above-mentioned task is achieved by a data carrier having the computer program mentioned here.
"In addition 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. As already explained at least one open source software component or COTS can be embodied in this case as at least one non-safety-critical software component."
For more information, see this patent: Liakos, Efthimios; Porsch, Roland; Rothbauer, Stefan; Rothfelder, Martin; Zanzinger, Michael; Zeilmann, Hartmut. Method for Supporting a Safety-Oriented System. U.S. Patent Number 8620873, filed
Keywords for this news article include: Software,
Our reports deliver fact-based news of research and discoveries from around the world. Copyright 2014, NewsRx LLC
Most Popular Stories
- Obama Administration Releases Proposal to Regulate For-Profit Colleges
- Koch Brothers Step up Anti-Obamacare Campaign
- Elizabeth Vargas' Husband Marc Cohn Addresses Rumors
- Keurig Adds Peet's coffee, Alters Starbucks deal
- U.S. to Relinquish Gov't Control Over Internet
- Quiznos Files for Chapter 11
- SoCalGas Reaches Record Spend on Diversity Suppliers
- FDIC Sues Big Banks Over Rate Manipulation
- Vybz Kartel Convicted of Murder
- U.S. Consumer Sentiment Falls in Early March