-----Original Message-----
From: Lukas.Bulwahn@... <Lukas.Bulwahn@...>
Sent: Donnerstag, 14. Mai 2020 08:35
To: MacGregor John (CR/ADT4) <John.MacGregor@...>
Cc: development-process@...
Subject: AW: "Pseudo-DIA" between the Linux Kernel Development Community and
its Users - 2/5 We're talking about an Operating System here
John,
We continue.
According to the textbook definition, the operating system-related
part of the development process starts at the software architecture
phase. The system developer may initially have a set of operating
system alternatives to choose from, say an RTOS or Linux or even BSD
for all I know. The basic application functionality and its (logical)
requirements on the OS are defined in the architecture phase. As
processing aspects are considered, specific interfaces to the OS are
identified at the technical design stage. Probably at this stage at
the latest, the alternatives have been narrowed down to one operating
system. Extraneous OS functionality, such as communication stacks or
file systems can be eliminated and options can be chosen which defines
a specific OS configuration. Code may have to be developed to bring the OS up
at run- time.
Agree. If we exclude the run-time code, there is no "coding" (as in changing C code)
involved.
However, you would expect this complete process above to be executed under
some quality management (and the execution of those activities meeting some
procedural requirements).
So, it is relevant to formulate the requirements that we would expect to be met for
those steps in the context of "selecting and configuring a Linux kernel".
There are then OS-related aspects to the validation activities which
correspond to the various development phases.
==> The system developer selects, configures and tests an operating system:
no development is involved, neither by the system developer nor by the
operating system supplier, and by extension there is no need for a DIA.
I agree that the system developer has the task (and the responsibility) to select,
configure and test the operating system.
I do not agree to the statement that "no development is involved".
You describe above a complete development step, and I believe multiple clauses in
the standards apply; although, it never results in code.
It only results in a kernel build configuration, and this kernel build configuration is the
interface to the operating system supplier.
The system developer wants that the operating system supplier provides "a good
implementation" for this kernel build configuration.
I agree. At the time the system developer decides to use the operating system,
the operating system developer has already finished testing. The process is more
like the selection process for a hardware component. The customer can assess the
testing that the supplier has already done and do its own testing to evaluate alternative
components.
This process isn't particularly foreseen in the safety standards. That being said, we're talking
about the general functionality in this e-mail, not the safety functionality.
What 26262 says, in 20262-8 Clause 12 is that the organization should prepare a specification
for the component, including the requirements on the component. The organization must
then provide evidence the requirements have been tested to an adequate coverage level
and that the component is valid for its intended use by verification according to clause 9.
The process for deriving the specification and requirements is not described and I assume that the
component should be treated like any component created by bespoke development, i.e. in the architecture
and design phases of 20262-6.
Nicolas Mc Guire addressed this in his 61508-based approach, especially noting that when other factors are relatively
equal, one criteria for selection between alternative components could be their certifiabliity; their
systematic capability. That's one of the uses for Annex QR.
That is the implicit DIA here. Then the operating system supplier executes an own
"development process" down to the implementation (with his own V model process).
Either we misunderstand each other or I disagree. At the point that the customer uses
the operating system, as in using it in its architecture and design phase, the
operating system already exists and should be completely implemented.
The only DIA I see here, is the DIA I discussed below, where the user community
issues a generic DIA that the operating system developer can consider during
further development. Considering that I said that the OS has already been developed
in this scenario, the OS has been developed based on the requirements, including any
customer requirements, that the OS developer gathered in its requirement phase.
And longer question:
So, does the operating system supplier or the system developer test the operating
system?
(I have an assumption here and there is again a certain split of the activities in this
area.)
Both do testing. The operating system supplier can, of course, integrate the OS in
its test harnesses, or representative test user systems, before release. The system
developer does acceptance and validation testing in its development process.
I think a process description should cover these insights above from you, and the
assumed responsibilities here.
(If this is part of a DIA or some even more basic overview document on the process
is secondary to me; we will figure it out while constructing.)
It is clear though (even if we do not have the description) that we certainly need to
have the common understanding, e.g., as you described the overall process above,
and one core aspect of it is "who does what". Otherwise, this mapping of ISO
clauses/QM standards (ASPICE and such) to described activities is hardly to
understand.
Off the top of my head, I don't know what the implications are for supplier management. I
could imagine that acceptance test development is covered there as well.
As we see in this discussion, already on the higher levels, we assume multiple "V-
model like development process" happening in some interweaved and temporally
decoupled way.
Like I said, I think that component development has finished before the system developer
starts. What is happening, especially with Linux, is that, after a version is released, the version
continues to be updated with bug-fixes. That, for me, is part of the maintenance process, the
quality of which could be a criteria in the component selection process.
Documenting that as if it is "one V-model process" will probably distort the whole
process assessment and that has impact on results (at least, in comprehensibility,
and maybe even in the risk assessment).
There is of course, the possibility that the system developer needs
custom OS functionality, a new feature (or, to use Chris Temple's terminology, a
chunk).
In which case, if the system developer can afford it, either party can
develop the feature or enhancement from scratch. Consider what Google
has done with off-tree development of Linux functionality for Android,
which they sometimes got retroactively accepted upstream. In this
case, Google would be making a DIA with itself: between its Android
and Linux organisations, which is foreseen in the definition of a DIA.
Agree. I consider this a completely new and different development process, that
needs a DIA in itself.
An organization making a DIA with itself is the default. Usually, the organization
using Linux will act internally and as part of the community. That does not invalidate
the idea of a DIA. Still activities in the community are different than the activities that
are done internally, and in the end, the quality statement comes from understanding
how well both activities (internally, and in the community with others) work, and how
well they "work together" (interact, are aligned, etc.).
While a system developer must choose an operating system from the
flavours and versions that are available at the time, what ELISA is
actually looking at is the interaction between the user community and
the Linux development community. The user community has the
possibility to specify its expectations on future operating system
development: a DIA for future functionality in general rather than for
a specific feature development effort. The operating system
developers then have the possibility of considering the needs of the user
community when adding or modifying OS features.
Agree. That is the upfront development to the development process above.
Summarizing, we identified three "development processes":
1. Understanding the system needs and selecting and configuring the operating
system appropriately. Result: kernel build configuration
2. Previous development process of the operating system (without any involvement
of the own organization)
Result: source code (relevant here to the system integrator is the source code for
kernel build configuration above)
3. Specific development process of the operating system (with involvement of the
own organization and a clear goal towards a specific quality level)
Result: New features specifically driven by extensions of 1.
Again, 2. And 3. Intersect but it help in the discussion to separate those.
Do you agree to "all" above?
Yes, there are these 3 development processes, whereby 1) does not involve operating
system development would not involve a DIA between an individual user and the
OS developer.
I let it sink on the mailing list and then see where such basic information must be
documented for this process assessment we are executing to be comprehensible.
Maybe it is just a scope section, as it is already a split of activities on a very high
level, not on individual clauses.
Sounds good. Hmmm. The list is a pretty quiet bunch. Silence surely means consent...
at least when they've read this far.
John
Lukas
