I stand corrected. Perhaps more accurate:
Those who are "ok with Linux as is", believe that they
don't really need any by-products of ELISA. They will continue to do what they are already doing,
unless we communicate the benefits and feasibility..
From: Smith, Jason <Jason.Smith@...>
Sent: Thursday, February 10, 2022 3:49 PM
To: Elana Copperman <Elana.Copperman@...>; Shuah Khan <skhan@...>; devel@...
Subject: RE: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022
|
EXTERNAL EMAIL:
Do not click any links or open any attachments unless you trust the sender and know the content is safe.
|
Hi Elana,
Just wanted to respond to one of your comments:
Those who are "ok with Linux as is", don't really need any by-products of ELISA. They will continue to do what they are already doing.
I don’t believe this is entirely true.
More clearly communicating potential shortcomings of Linux to these folks will enable them to better design a system around Linux to make that overall system safer.
Jason R. Smith,
UL-CFSX
Principal Engineer, Robots & Control Systems (CMIT)
Distinguished Member of Technical Staff
--------------------------------------------------
UL LLC
333 Pfingsten Road
Northbrook, IL 60062-2096 US
T: 1.847.664.1352
W: https://www.ul.com
Thanks, Jason. I think we are pretty much saying the same thing, only (as usual in ELISA) from 2 different sides of the coin.
Those who are "ok with Linux as is", don't really need any by-products of ELISA. They will continue to do what they are already doing.
For those who need stricter compliance with the standards, it is already clear that full compliance will not happen. So that some iterative process (similar to what Jason describes) will bring Linux closer to what the safety standards
expect, leaving it up to the integrator to fill in any remaining gaps for his/her use case. I don't think ELISA can/should do more; but even this will be a great contribution.
My only real concern is that we need to bring in a broader spectrum of contributors, so that we can expand our context for deployment and acceptance. As Jason says, "I don't know if this is exactly what the community needs". The community
of Linux users for safety critical applications is enormous, and we have lost them (they attended the early workshops but have since petered out). We need to hear their voice.
Any proposal, Jason's or mine or anyone else's, is an iterative process. But we need to be moving in a clear direction for what the world needs.
Regards
Elana
|
EXTERNAL EMAIL:
Do not click any links or open any attachments unless you trust the sender and know the content is safe.
|
My goals are quick wins. There are safety applications using Linux that either don’t need safety certification or whose standards allow Linux to be treated as-is, i.e. software
of unknown pedigree. Just small improvements to Linux or relatively small additional pieces of information provided with Linux could offer a lot of value to these developers, allowing them to build safer products. Examples: code improvements, new modules
that add or support software safety measures, white papers, manuals, design guides, fault analyses, reports (verification, validation, review, etc.), release notes including known issues, etc. In a way, this is perhaps a scaled-down version of Elana’s (3).
That being said… I don’t know if this is exactly what the community needs.
I think (if we haven’t done so already) we should go out far and wide across not only ELISA but Linux developers in general to find out what they really need.
Are there enough developers of safety applications using Linux that are okay with treating Linux as-is, making it worthwhile to pursue my stated goal?
Or are most folks trying to develop systems for self-driving cars using Linux and ultimately need compliance with ISO 26262?
If the latter is true, start with Elana’s (1). It’s going to be a lot of work.
Jason
From: devel@... <devel@...>
On Behalf Of elana.copperman via lists.elisa.tech
Sent: Wednesday, February 09, 2022 9:37 AM
To: Shuah Khan <skhan@...>;
devel@...
Subject: Re: [ELISA Technical Community] TSC Meeting Agenda - February 16 2022
Thanks, Shuah. Some goals/ideas from my side:
-
To establish a framework for communication and collaboration between Linux kernel developers/maintainers, safety experts and designers/developers of Linux based safety critical systems. Without broader representation and communication,
the work products of ELISA cannot have a context for deployment and acceptance.
-
ELISA is a project of the Linux Foundation. To leverage this umbrella, learn from its strong points, and help to improve the weaker points towards the long-term goal of integrating Linux successfully in safety critical systems.
-
Work products (actual kernel patches) which will support the original ELISA mission statement: to define and maintain a common set of elements, processes and tools that can be incorporated into Linux-based, safety-critical systems
amenable to safety certification.
EXTERNAL EMAIL: Do not click any links or open any attachments unless you trust the sender and know the content is safe.
All,
Let's meet next week to discuss alignment on goals and what success
looks like. Please respond to this thread to add you 1 or 2 items
you consider important to achieve ELISA goals and make the project
successful.
I will compile the items and share the consolidated list before the
meeting.
thanks,
-- Shuah
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete
this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete
this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
