add first draft for PiU paper #21
Conversation
Signed-off-by: shetze <[email protected]>
There was a problem hiding this comment.
The problem I see with a proven in use argumentation is that it requires:
- defining a very specific HW/SW combination
*. if you want to generalise the HW/SW combination with more pairs, you have to prove that they will be equivalent, with regard to the use for which you have historical data - you need to have evidence from operating that (class of) HW/SW combination in the field (meaning that it's not sufficient to say that it has worked, you need to have stats about MTBF, for example)
- you need to prove that the HW/SW combination for which you want to make the proven in use argumentation is equivalent to the one for which you have gathered data
- you need to prove that the use case and operating conditions to which this new HW/SW combination will be exposed are equivalent to those for which you have historical data.
If you can do THAT, there is no need to do much in terms of safety analysis and study of freedom from interference, because you have already proven that the new system is equivalent to one that would work, as long as they are used in the same scenario.
The fact that Linux is modular even if it is not a microkernel doesn't mean much - what the microkernel brings to the table is the HW-backed isolation.
What I was - and still am - VERY skeptic about are point #3 and #4, because (IMHO) it is very unlikely that you will find sufficient data about sufficiently homogenous systems used in a very similar way.
The fact that linux evolves so rapidly already makes it unrealistic to expect that one would have sufficient data for something sufficiently close (unless you want to use a 4.0 kernel, or example)
The point where linux not being a microkernel comes into play is that as soon as you need a new/different device driver, you have voided the assumption of similarity between your target system and the one which has produced the historical data.
The reason for being so strict in rejecting changes compared to the initial configuration is that, even assuming one might be able to re-use the very same HW and kernel, changing only user-space, that change alone might expose latent safety issues that have been there all the time - even while gathering data about how safe the system is - but never got a chance to be exposed.
By radically altering even the pattern by which memory is allocated, CPU is used, etc. the system ends up exerting very different activation patterns that are now outside the scope of the historical data, which becomes useless.
All in all, the arguments made in the pull request are unfit for a generic approach to "Proven in Use", because they do not really capture its purpose, which is all but generic.
I would rather suggest to pursue the use of PAS, because it's a much better fit and can actually yield some usable outcome.
|
@igor-stoppa wrote
What does 'PAS' refer to in this context? |
Proven-In-Use-Argument.md
Outdated
| @@ -0,0 +1,77 @@ | |||
| # Is Linux mature and proven enough for use in safety-critical applications? | |||
|
|
|||
| Linux has proven itself thousands, probably millions of times over in business-critical applications. So it makes sense to use Linux for safety-critical applications as well. Linux has many advantages | |||
There was a problem hiding this comment.
There are several misconceptions already at the beginning:
- "Linux", as intended in the document, doesn't exist. There are a large number of versions and revisions, each with own set of features and bugs.
- When making claims of proven in use, one MUST refer to a specific SW configuration, its features and its bugs.
- When making claims about proven in use, one MUST refer to a specific HW configuration.
There would be even the aspect of the toolchain, but the previous points are already sufficient to void the rest of the considerations.
As I already stated, these sort of statements are not per se comepltely wrong, but they do nto belong to "Proven in Use", they rather fit in the PAS 8926 https://www.iso.org/standard/83346.html approach.
There was a problem hiding this comment.
I still do not accept to give up the option of PiU alltogether. Can you agree with the following text? Would this make the problem sufficiently clear and still provide a constructive path for the argument?
"""
It is obvious and must nevertheless be clearly repeated: Linux can never be approved 'as a whole' and 'in general' for use in safety-critical applications. There are any number of examples of Linux configurations and constellations in which the operating system fails mercilessly. Therefore, according to the conservative interpretation of the standard documents, only individual, fully specified systems can prove themselves. In this sense, every Linux system is unique and a PiU argument is categorically ruled out.
In order to approach the PiU argumentation for Linux, the dimension of the system under consideration or the elements under consideration must be reduced and focused on the one hand. On the other hand, value ranges for configuration and constellation must be described that are recognized as equivalent with regard to the safety-critical application. If it is possible to document the elements in focus in running systems with their behavior, especially in the event of system errors and in extreme situations, and to document robust behavior, a PiU argumentation could be based on this.
"""
There was a problem hiding this comment.
In my opinion, the initial problem lies in the wording "Proven in Use" - it is already widely asociated to certain concepts which do not match what you are after. I do not understand why you seem unmovable on this.
Of course you can arbitrarily redefine words and expressions, to mean what you wish them to mean.
However, it seems an unnecessary uphill battle.
Then, there are a bunch of further considerations on several assumptions that you seem to make, like what is the "installed base" that can be taken as reference, what is the accept/reject criteria.
For example: a handheld console, a water plant management system, a server, a drone, can all run linux.
How do you define which ones can be taken as reference and which cannot?
Assuming that you have defined such a set, which changes can one make and still keep the claims valid and which would void the claims.
To me, this whole argumentation looks very verbose, but it lacks the clarity of scope that I would expect when making such claims.
It is a fact that - usually - one will want to take something as baseline and alter it.
This whole thing is missing clear criteria for what is admissible, what is not, and what is admissible, but introduces extra validation (for example).
I'd rather see a set of conicise bullet points with ok/nok do/don't and so on.
The PAS 8926 https://www.iso.org/standard/83346.html |
Thank you for the comment, these are good objections. |
I totally agree that the PiU argument is not easy to make. However, my understanding is that it has certainly been applied in the automotive industry. Here it would be good if someone could contribute concrete data on how often this has actually been the case so far. However, with the limits given in the current standard (10-⁹ for ASIL-D), it is not easy to prove the required operating times even for the automotive industry with the large numbers of units compared to other technical systems. If I understand correctly, the automotive industry expects an average of 400 operating hours per year. The series are quite respectable with perhaps 10k to 20k, but still small in view of 11416 years. For Linux servers, however, we can count on a number of operating hours that is larger by a factor of 20. For a constructive handling of the challenge, I suggest to formulate the concrete requirements for the data to be collected. We can then leave the question of whether it is realistically possible to collect this data to the stakeholders interested in such proof. |
Co-authored-by: Paul Albertella <[email protected]> Signed-off-by: Sebastian Hetze <[email protected]>
The fact that there needs to be a fixed HW/SW combination stems from the need to have homogeneous data. The ISO desn't get into details because it's up to specific HW/SW instances how much the can be generalised. You cannot expect the ISO to give direct guidance on specific applications, because it would most likely miss many sub-cases. Instead, it gives generic guidelines and it is up to who deals with a certain application to understand how the ISO applies. |
The concrete requirement, as I stated earlier, and it doesn't come from me, but from the ISO and the way it is applied (please check it with Gab, for example) is that you need to have a high level of uniformity between HS/SW that has produced the data, the one you want to use now, the use cases that have produced the data and the use case you intend to use. Unless you plan to put a server in a car (or a train) and use similar sw, I see little use for that data collected from servers. I do not how else to say it: it's clear you really wan to use linux, and so we all do, but if it was just a matter of making these claims you are attempting to do, don't you think that it would have been already done a long time ago? Also, as I already wrote, you seem t mix PiU and PAS. The arguments you bringing are not devoid of merit, but they are simply unfit for PIU, and they are a much better match for the PAS. Please also for this talk with Gab. |
Proven-In-Use-Argument.md
Outdated
| For obvious reasons, the dangers posed by an item must be reduced to an acceptable level before the item is put into operation or placed on the market. | ||
| Thus, to reduce the unavoidable risks from an item to an acceptable level, appropriate safeguards must be found and implemented at the design stage. These protective measures come into action under certain conditions and regulate the item in such a way that a previously identified and determined risk remains below a predetermined threshold. These protective measures are called safety functions. In certain situations, a safety function can put the item in a state recognized as safe, for example, by shutting the item down. | ||
|
|
||
| With the introduction of safety functions, the risk posed by an item now depends on the correct operation of that protective measure. Thus, the item is safe only to the extent that the safety function operates correctly and reliably. This is the safety of the safety function, or simply functional safety. |
There was a problem hiding this comment.
I am bit unsure about the wording but it is not only correctly and reliably, both also robustly. Robustness means that the function should operate correctly even in the presence of faults within the item.
Proven-In-Use-Argument.md
Outdated
| For obvious reasons, the dangers posed by an item must be reduced to an acceptable level before the item is put into operation or placed on the market. | ||
| Thus, to reduce the unavoidable risks from an item to an acceptable level, appropriate safeguards must be found and implemented at the design stage. These protective measures come into action under certain conditions and regulate the item in such a way that a previously identified and determined risk remains below a predetermined threshold. These protective measures are called safety functions. In certain situations, a safety function can put the item in a state recognized as safe, for example, by shutting the item down. | ||
|
|
||
| With the introduction of safety functions, the risk posed by an item now depends on the correct operation of that protective measure. Thus, the item is safe only to the extent that the safety function operates correctly and reliably. This is the safety of the safety function, or simply functional safety. |
There was a problem hiding this comment.
The last sentence is a bit confusing "functional safety" usually does not refer to the safety of the safety function; but it is rather refering to the engineering field for the development of safe items/systems.
There was a problem hiding this comment.
This formulation is perhaps a little abbreviated, but I'm actually quite proud of it. Do you think it's wrong?
In Wikipedia I find the following for functional safety
Functional safety is the part of the overall safety of a system or piece of equipment that depends on automatic protection operating correctly in response to its inputs or failure in a predictable manner (fail-safe).
Somewhat abbreviated that means:
Functional safety is the part of the overall safety of a system that depends on automatic protection operating correctly in a predictable manner.
The automatic protection implemented in software is the safety function, this leads to safety of the safety function. Can you go along with that?
Proven-In-Use-Argument.md
Outdated
|
|
||
| It is obvious to implement safety functions at least partially with electronic or programmable components. It is only in this context that the question of using Linux for safety-critical applications arises: as an operating system for a programmable component in one or more safety functions. | ||
|
|
||
| The Linux operating system is not an item. Therefore, it makes no sense to say Linux or any software is safe. Linux is a general-purpose operating system, it is not designed for any specific use case. For special use cases, Linux can be customized and configured both at compile time and at runtime. |
There was a problem hiding this comment.
This connection between the two sentence created here with use case is strange. Linux is designed for use cases in general, but of course not for system/item-level use cases. Then the use of use case, is again something different. Overall it is mixed too many things that are not strictly related to each other in one paragraph.
There was a problem hiding this comment.
I'd argue that nothing here is very obvious, since the discussion on htese topics has been going on for years.
If you want to make statements, provide backing evidence.
|
|
||
| The Linux operating system is not an item. Therefore, it makes no sense to say Linux or any software is safe. Linux is a general-purpose operating system, it is not designed for any specific use case. For special use cases, Linux can be customized and configured both at compile time and at runtime. | ||
|
|
||
| As a component of a specific safety function, the instance of Linux that is individually configured and optimized for that use case must be functionally safe so that the safety function can reduce the danger posed by an item to an acceptable level. As a rule, specific real-time requirements are placed on the operating system for safety functions, among other things. For the mass of business-critical applications, for which Linux has proven itself so well in the past decades, such requirements are not made. This consideration alone gives a first indication that an analogy of applicability from mission-critical to safety-critical applications is not so simple. |
There was a problem hiding this comment.
We are already talking about the whole element Linux that seems jumping too quickly...
There was a problem hiding this comment.
The real-time requirement is a really unfortunate one, as most hardware would not even allow making such claims for safety.
There was a problem hiding this comment.
@bulwahn What would address your concerns here? Should we omit the reference to real-time requirements, for example? Could you suggest a rewording?
|
|
||
| As a component of a specific safety function, the instance of Linux that is individually configured and optimized for that use case must be functionally safe so that the safety function can reduce the danger posed by an item to an acceptable level. As a rule, specific real-time requirements are placed on the operating system for safety functions, among other things. For the mass of business-critical applications, for which Linux has proven itself so well in the past decades, such requirements are not made. This consideration alone gives a first indication that an analogy of applicability from mission-critical to safety-critical applications is not so simple. | ||
|
|
||
| As a component of a safety function, Linux becomes part of the safety architecture of a particular item. For the risk analysis of the item, the risk that the safety function does not intervene in time, does not intervene at all or intervenes incorrectly in some way must then also be systematically analyzed and evaluated for each safety function. |
There was a problem hiding this comment.
It remains unclear: what should not intervene with what?
There was a problem hiding this comment.
I will try to clarify this sentence
There was a problem hiding this comment.
Proven-In-Use-Argument.md
Outdated
|
|
||
| As a component of a safety function, Linux becomes part of the safety architecture of a particular item. For the risk analysis of the item, the risk that the safety function does not intervene in time, does not intervene at all or intervenes incorrectly in some way must then also be systematically analyzed and evaluated for each safety function. | ||
|
|
||
| The systematic analysis and evaluation of risks is, at its core, a job that involves a lot of statistics and probability calculation. Probability theory is one of those mathematical disciplines where intuition and "common sense" often fail. This is the simple answer to the question of why Linux is not so easily a component for safety functions, even though it has proven itself so well for mission-critical applications. The simple analogy from mission-critical to safety-critical is intuitively obvious, but mathematically incorrect. |
There was a problem hiding this comment.
Actually: statistics and probability calculation is used very little in systematic analysis and evaluation of risks.
Proven-In-Use-Argument.md
Outdated
| A more accurate answer requires somewhat deeper considerations. | ||
| The risk analysis for a technical system and its safety architecture is necessarily application-specific. Linux itself is only part of the safety function. In the specific mathematical consideration, a possible error of Linux in the safety function enters into a probability calculation. It is recognized and admitted that components can be used in a safety function which have proven themselves in other (as similar as possible) applications. Realistically, however, it must not simply be assumed that such a component is absolutely safe, i.e. that it functions correctly with probability 1. | ||
|
|
||
| An exact value for the intuitively obvious reliability of Linux is difficult to determine because of the complexity of the monolithic kernel. In order to arrive at a reasonably accurate value for the purpose with a defined small uncertainty, a lot of testing has to be done, and probability calculation is again used. |
There was a problem hiding this comment.
Quantification of reliability of software is generally difficult to determine; Linux is not special in that way.
There was a problem hiding this comment.
Testing is not really a method mentioned to compute quantification of reliability.
Proven-In-Use-Argument.md
Outdated
|
|
||
| An exact value for the intuitively obvious reliability of Linux is difficult to determine because of the complexity of the monolithic kernel. In order to arrive at a reasonably accurate value for the purpose with a defined small uncertainty, a lot of testing has to be done, and probability calculation is again used. | ||
|
|
||
| The mathematical details of the analysis established in IEC 61508 for proven in use are very well described, for example, at Exida and shall not be repeated in detail here. This way is possible, but unfortunately no longer intuitive. In IEC 61508 probabilistic limits are set for the SIL, which must be met for approval. For SIL 4, it is required that a dangerous failure occurs for a safety function with a high or continuous demand rate with an average frequency of less than 10-⁸/h (Probability of Dangerous Failure per Hour, PFHD). This means that proof must be provided that this safety function fails on average only every 11416 years. The limits from IEC 61508 for the PFHD have also been adopted in EN 50129 for the Tolerable Hazard Rate (THR). In ISO 26262-8 14.4.5.2.4, even 10-⁹/h is required for ASIL-D as the limit for the average frequency of actually observable malfunctions. For ASIL-B and ASIL-C, the limit of 10-⁸/h is set without difference. |
There was a problem hiding this comment.
"at Exida"---that is strange wording: Exida is a company, but we want to refer to a specific document. So let us refer to that document by name.
Co-authored-by: Paul Albertella <[email protected]> Signed-off-by: Sebastian Hetze <[email protected]>
|
My aim is still to produce a positive, constructive text on the subject of PiU. This is important to me because ELISA in particular can also aspire to criticize the existing formulations and established interpretations of the current standards and suggest changes. Igor refers to PAS 8926 in which this has been done for ISO 26262 and the qualification of software. Why shouldn't it be possible for IEC 61508 and PiU, for example? I would also like to point out that, as far as I can see, the argument against PiU assumes that there will be no SIL-2 safety function with Linux kernel support. That is fatalistic. And why shouldn't we demand that such a PiU argument is also valid across sector boundaries? Automated Train is precisely about making the transfer from the automotive industry to the rail sector. That's why I'm interested in PiU. If I understand correctly, such calls to improve the standards have already been made. We should reference a few of these attempts from the past. https://gitlab.opentech.at/markus/sil2linuxmp/-/blob/main/doc/literature/HSE/crr01337.pdf |
Let's forget for a moment all the standards, ISO or not. But, as soon as you want to change something, either in the use case, or in the components - let's say swap the chipmunk for an hamster or the gnome for an elf, THEN you have to prove that they are REALLY equivalent for the perspective of the intended use. Even if you keep it as-it-is, but change what you will use it for, you still have to prove that it is good enough. This is the sort of reasoning that I do not see in all the stuff you wrote. Do you want to put a GM vehicle with RHIVOS on a railroad track? Something else? What is the argumentation that they are equivalent? What is the argumentation that the data collected by driving cars is good enough for trains? Personally, I am not interested in discussing only the astronaut-architect perspective, where very practical problems are not considered. |
…on the earlier pull request. Signed-off-by: shetze <[email protected]>
|
Overall, I think this is a useful discussion of the topic, which explains why an apparently intuitive 'proven in use' argument cannot be applied, and explores both how such an argument is applied to other kinds of system, as well as some of the alternative strategies for arguing that pre-existing software is acceptably safe in a given context. I have made some suggestions, and Lukas has requested a few more tweaks. However, I think we are not too far from having a document that we can publish. Can we resolve some of the other threads e.g. those from @igor-stoppa by adding a note in the text to make it clear that a claim is disputed, or including an alternative framing alongside it? |
Discussed in weekly meeting and agreed with the original author Signed-off-by: Paul Albertella <[email protected]>
|
|
||
| As a component of a specific safety function, the instance of Linux that is individually configured and optimized for that use case must be functionally safe so that the safety function can reduce the danger posed by an item to an acceptable level. As a rule, specific real-time requirements are placed on the operating system for safety functions, among other things. For the mass of business-critical applications, for which Linux has proven itself so well in the past decades, such requirements are not made. This consideration alone gives a first indication that an analogy of applicability from mission-critical to safety-critical applications is not so simple. | ||
|
|
||
| As a component of a safety function, Linux becomes part of the safety architecture of a particular item. For the risk analysis of the item, the risk that the safety function does not intervene in time, does not intervene at all or intervenes incorrectly in some way must then also be systematically analyzed and evaluated for each safety function. |
There was a problem hiding this comment.
@bulwahn Does this rewording address your concern?
| As a component of a safety function, Linux becomes part of the safety architecture of a particular item. For the risk analysis of the item, the risk that the safety function does not intervene in time, does not intervene at all or intervenes incorrectly in some way must then also be systematically analyzed and evaluated for each safety function. | |
| As a component of a safety function, Linux becomes part of the safety architecture of a particular item. For the risk analysis of the item, the risk that a component of the OS that is involved in implementing the safety function does not fulfil its responsibilities (e.g. does not intervene in time, or does not intervene at all or intervenes incorrectly in some way) must then also be systematically analyzed and evaluated for each safety function. |
as discussed in our meeting yesterday, here is the first draft as PR