one question about Hybrid approach
|
Qian ChunLei 钱春雷
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. |
|
|
|
Paoloni, Gabriele <gabriele.paoloni@...>
Hi QianChunlei
WRT table6 it is something that we need to discuss (it may happen in the development process WG sometime);
Thanks Gab
From: safety-architecture@...
<safety-architecture@...> On Behalf Of Qian ChunLei ???
Sent: Tuesday, May 25, 2021 7:07 AM To: safety-architecture@... Subject: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Wang YuJue 王玉珏
Hi Gab
Thank you for your wonderful sharing, they are very interesting and have caused my questions, u Q That 8.12 is very clear "Objective of the qualification of software components is to provide evidence for their suitability for re-use in items developed in compliance with the ISO 26262 series of standards." The three important elements are "provide evidence", "compliance" and "re-use", This means that if: 1、That currently only have a QM-level (FOSS) Linux software unit, so it is impossible to "provide evidence" that it can "compliance" the safety requirements of the new project (may come from AoU) Or 2、Already have a Linux software unit with safety that has been approved by an some organization, so we can "provide evidence" that it can "compliance" the safety requirements of the new project (also from AoU)， So, in case 1 we all know that the current Linux does not use any safety software components, so how do we talk about "reuse" with safety feature? And in case 2 this original software shall been approved in development according to Part6. It is also impossible to help you bypass the heavy work. u Q I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory." But I don’t think this can solve the safety problem. like You also mentioned - No dynamic objects/variables -No implicit type conversion… These restrictions are all because they are easy to make mistakes, so we prohibit them unless it is proved that their application is reasonable and controllable . I think this is reasonable， After all, we are discussing the possibility of failure of less than 100FIT, which is far beyond The traditional industrial Linux ability, I don't think you can guarantee these safety benefits through your methodology. u Finally, I fully agree with Chris’s opinion that no matter whether the standards are perfect or not, as developers, we must respect the physical safety interests of the product. Any potential safety-related vulnerabilities/failures should be fully identified, This means that if the workload is too large to be accepted, then we should find more efficient equivalent alternatives, rather than bypass them, because this may harm safety interests.
Thank you so much!
B&R 王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
From: safety-architecture@...
<safety-architecture@...> On Behalf Of Paoloni, Gabriele
Sent: Tuesday, May 25, 2021 5:30 PM To: Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@... Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi QianChunlei
WRT table6 it is something that we need to discuss (it may happen in the development process WG sometime);
Thanks Gab
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Qian ChunLei ???
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. |
|
|
|
Paccapeli, Roberto
Hi 王玉珏 Wang Yujue,
I share my opinion below:
Q1 I disagree with your interpretation of the standard. You are basically merging “SEooC” and “Qualification of SW component” in a unique method. About 8.12 · << for re-use in items developed in compliance with the ISO 26262 series of standards>> means the context of your qualification activities must refer to an item context developed in compliance with ISO 26262 · <<to provide evidence for their suitability>> sets the goal of your qualification activities. Then to produce sufficient argumentations about the robustness of your design against the considered context. What you have described in your comment is a SEooC method, then SW components designed by adopting a list of AoUs and then developed and tested in accordance with Part 6. While 8.12 is (roughly) a black box approach in which some conditions are explicitly listed in clauses to make it applicable in “practice”.
Then, even if << the current Linux does not use any safety software components >> (and this is the case for a massive amount of SW designs currently available in the market space), conceptually the qualification method can be always applied for justifying its usage (or portions) for FuSa purpose.
Q2 Here I agree partially with you. But I don’t think that the challenge is really on the approach. But on the details of the approach, then on how to ensure there are no mistakes fully addressed.
From another side, we need to take in account that, since the final goal of safety standard is to have no unpredictable or unexpected behavior of intended functionalities, safety standards accept to have some exceptions only if properly analyzed and justified. And then under control.
Q3 Today, I have not observed something in contrast with the ISO 26262 2nd Edition or the intention of the proposers to not recognize the standard as pilar for Functional Safety or to try bypassing something. This hybrid approach seems interesting because it opens the possibility to have something usable in different context and scalable. With that, I am not saying that it is easy to apply… But Gab and Daniel’s line, “Divide and Conquer”, seems better facing the challenges with a concrete tactical scheme. There are other approaches that we could adopt, but, based on my experience, they are mainly focused on specific context, with limited scope due to the complexity of Linux Kernel and then not scalable. But as I said, the last comment is based on my experience 😊
Thanks,
Roberto Paccapeli Functional Safety Manager | IOTG PMCE FSS
D +39 050.782.0014 | M +39 339.589.2630 Via Lenin 132/p | S. Giuliano Terme, Italy, 56017 Intel Corporation | intel.com
From: safety-architecture@...
<safety-architecture@...> On Behalf Of Wang YuJue ???
Sent: Tuesday, May 25, 2021 1:50 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@... Cc: Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张海鹏-SW <zhanghaipeng02@...> Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi Gab
Thank you for your wonderful sharing, they are very interesting and have caused my questions, u Q That 8.12 is very clear "Objective of the qualification of software components is to provide evidence for their suitability for re-use in items developed in compliance with the ISO 26262 series of standards." The three important elements are "provide evidence", "compliance" and "re-use", This means that if: 1、That currently only have a QM-level (FOSS) Linux software unit, so it is impossible to "provide evidence" that it can "compliance" the safety requirements of the new project (may come from AoU) Or 2、Already have a Linux software unit with safety that has been approved by an some organization, so we can "provide evidence" that it can "compliance" the safety requirements of the new project (also from AoU)， So, in case 1 we all know that the current Linux does not use any safety software components, so how do we talk about "reuse" with safety feature? And in case 2 this original software shall been approved in development according to Part6. It is also impossible to help you bypass the heavy work. u Q I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory." But I don’t think this can solve the safety problem. like You also mentioned - No dynamic objects/variables -No implicit type conversion… These restrictions are all because they are easy to make mistakes, so we prohibit them unless it is proved that their application is reasonable and controllable . I think this is reasonable， After all, we are discussing the possibility of failure of less than 100FIT, which is far beyond The traditional industrial Linux ability, I don't think you can guarantee these safety benefits through your methodology. u Finally, I fully agree with Chris’s opinion that no matter whether the standards are perfect or not, as developers, we must respect the physical safety interests of the product. Any potential safety-related vulnerabilities/failures should be fully identified, This means that if the workload is too large to be accepted, then we should find more efficient equivalent alternatives, rather than bypass them, because this may harm safety interests.
Thank you so much!
B&R 王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Paoloni, Gabriele
Hi QianChunlei
WRT table6 it is something that we need to discuss (it may happen in the development process WG sometime);
Thanks Gab
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Qian ChunLei ???
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Paoloni, Gabriele <gabriele.paoloni@...>
Hi YuJue
From my side I agree with the opinion from Roberto. WRT your statement I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory."
I think that this statement would be correct if the hybrid mode was about the single qualification of the different “SW blocks” or “SW Units” identified in Linux. Instead as you have seen from the deck we are introducing semi-formal and formal methods to describe the interactions between modules and more importantly we are introducing active monitors that verify the code to behave exactly as described by the models. This imply adding a significant amount of collaterals compared to the current Linux baseline: - Formal/semiformal SW architectural design describing the SW blocks/units interactions according to the different functionalities (e.g. ioctl(), open(), watchdog_ioctl(), watchdog_open()..) - Natural Language specifications for the single blocks - FMEA or equivalent safety analyses based on the specs above for each functionality - Best set of CONFIGs following the results of the safety analysis - Eventual code modifications/improvements following the results of the safety analysis - KSelftest campaign for the single blocks qualification - KSeftest campaign for the module integration (with active monitors verifying the real code to behave as modelled)
Then WRT table6 of part6 we cannot apply it to Linux just because it is a pre-existing piece of code that we cannot re-write entirely to meet the table requirements however we have static code analysis in place to spot and evaluate weaknesses.
Thanks Gab
From: Paccapeli, Roberto <roberto.paccapeli@...>
Sent: Tuesday, May 25, 2021 5:12 PM To: Wang YuJue 王玉珏 <Wangyujue@...>; Paoloni, Gabriele <gabriele.paoloni@...>; Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@... Cc: Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张海鹏-SW <zhanghaipeng02@...> Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi 王玉珏 Wang Yujue,
I share my opinion below:
Q1 I disagree with your interpretation of the standard. You are basically merging “SEooC” and “Qualification of SW component” in a unique method. About 8.12 · << for re-use in items developed in compliance with the ISO 26262 series of standards>> means the context of your qualification activities must refer to an item context developed in compliance with ISO 26262 · <<to provide evidence for their suitability>> sets the goal of your qualification activities. Then to produce sufficient argumentations about the robustness of your design against the considered context. What you have described in your comment is a SEooC method, then SW components designed by adopting a list of AoUs and then developed and tested in accordance with Part 6. While 8.12 is (roughly) a black box approach in which some conditions are explicitly listed in clauses to make it applicable in “practice”.
Then, even if << the current Linux does not use any safety software components >> (and this is the case for a massive amount of SW designs currently available in the market space), conceptually the qualification method can be always applied for justifying its usage (or portions) for FuSa purpose.
Q2 Here I agree partially with you. But I don’t think that the challenge is really on the approach. But on the details of the approach, then on how to ensure there are no mistakes fully addressed.
From another side, we need to take in account that, since the final goal of safety standard is to have no unpredictable or unexpected behavior of intended functionalities, safety standards accept to have some exceptions only if properly analyzed and justified. And then under control.
Q3 Today, I have not observed something in contrast with the ISO 26262 2nd Edition or the intention of the proposers to not recognize the standard as pilar for Functional Safety or to try bypassing something. This hybrid approach seems interesting because it opens the possibility to have something usable in different context and scalable. With that, I am not saying that it is easy to apply… But Gab and Daniel’s line, “Divide and Conquer”, seems better facing the challenges with a concrete tactical scheme. There are other approaches that we could adopt, but, based on my experience, they are mainly focused on specific context, with limited scope due to the complexity of Linux Kernel and then not scalable. But as I said, the last comment is based on my experience 😊
Thanks,
Roberto Paccapeli Functional Safety Manager | IOTG PMCE FSS
D +39 050.782.0014 | M +39 339.589.2630 Via Lenin 132/p | S. Giuliano Terme, Italy, 56017 Intel Corporation | intel.com
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Wang YuJue ???
Hi Gab
Thank you for your wonderful sharing, they are very interesting and have caused my questions, u Q That 8.12 is very clear "Objective of the qualification of software components is to provide evidence for their suitability for re-use in items developed in compliance with the ISO 26262 series of standards." The three important elements are "provide evidence", "compliance" and "re-use", This means that if: 1、That currently only have a QM-level (FOSS) Linux software unit, so it is impossible to "provide evidence" that it can "compliance" the safety requirements of the new project (may come from AoU) Or 2、Already have a Linux software unit with safety that has been approved by an some organization, so we can "provide evidence" that it can "compliance" the safety requirements of the new project (also from AoU)， So, in case 1 we all know that the current Linux does not use any safety software components, so how do we talk about "reuse" with safety feature? And in case 2 this original software shall been approved in development according to Part6. It is also impossible to help you bypass the heavy work. u Q I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory." But I don’t think this can solve the safety problem. like You also mentioned - No dynamic objects/variables -No implicit type conversion… These restrictions are all because they are easy to make mistakes, so we prohibit them unless it is proved that their application is reasonable and controllable . I think this is reasonable， After all, we are discussing the possibility of failure of less than 100FIT, which is far beyond The traditional industrial Linux ability, I don't think you can guarantee these safety benefits through your methodology. u Finally, I fully agree with Chris’s opinion that no matter whether the standards are perfect or not, as developers, we must respect the physical safety interests of the product. Any potential safety-related vulnerabilities/failures should be fully identified, This means that if the workload is too large to be accepted, then we should find more efficient equivalent alternatives, rather than bypass them, because this may harm safety interests.
Thank you so much!
B&R 王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Paoloni, Gabriele
Hi QianChunlei
WRT table6 it is something that we need to discuss (it may happen in the development process WG sometime);
Thanks Gab
From:
safety-architecture@... <safety-architecture@...>
On Behalf Of Qian ChunLei ???
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
|
Wang YuJue 王玉珏
Hi Gab.
I agree with your approach to active monitors, which will effectively help existing Linux to improve robustness.，But I still have to say that this cannot eliminate my doubts. Let’s go back to the Foundation of Functional Safety, 1) Avoid systematic faults during design, development and manufacturing 2) Control of systematic faults during operation 3) Control of random hardware failures during operation Since our topic is only part6, let us just consider 1) and 2), however in order for promoting the use of commercial off-the-shelf software, 8-12 is to allow the use of similar black box method to approval that low-complexity software. This means that from a methodological point of view, it is not in use either 1), This is true, because for low-complexity software, perfect black box testing can basically cover all its behaviors with very few potential risks , which is achievable. But instead, you now want a re-use software unit-is it really low-complexity software? I understand that you want to disassemble each software unit into 8-12 acceptable low-complexity units through the method of part6-maybe each software unit only has 1 to 2 thousand lines of code. Then how many software units that can be considered "low complexity" need to be integrated? I don't know the exact number, but considering that we face tens of millions of lines of code, the number should not be small. The question to be raised at this time is that a certain number of "low complexity" software units will be integrated in a V development cycle, does 8-12 really support this? Essentially, even if you conceptually decompose a 1 million-line software unit into 100 software sub-units, you will eventually add 1 million lines of code to the new project. In this case, is black box testing enough? From a mathematical point of view, I think it is very dangerous. It is easy to know that the probability of potential failures not found by black box testing is magnified by 100 times
Of course, I checked entire document, so I found that in the next step, Hybrid Approach will return to Part6 and use software unit integration testing to solve the omission of black box testing. This is also a point of my concern: Directly conclusion: Part6's Integration Tests or other test concepts may not be able to solve the safety issues in the Hybrid Approach solution, at least not as required by ASIL B. As described earlier, the safety concept of Part 6 is based on 1) + 2), that is, first restrict the use of high-risk methods such as Table 3 in the design process, and then use testing methods to find possible design flaws on this basis. This is a combined approach. In the new method, we bypassed(Or partially bypassed) 1), so the test must bear greater responsibility, then how to choose the appropriate method for testing has become the core of the problem. The traditional ASIL B test requirements in Part 6 will no longer be sufficient. And I think tests such as "fault injection" or "MC/DC" need to be considered, but unfortunately, first of all these tests are expensive, and then even after implementing them, it is difficult to prove that this can really effectively find all potential problems, because we have broken away from the standard’s guidance. This is the flaw of the "hybrid approach" I want to express (maybe the example in the previous email is not appropriate), functional safety is always a systematic analysis and approval method, and It has always been different from Lego, which can be assembled freely.
Finally, I want to express my opinion again. I think your methodology is a great improvement. After so much effort like static code analysis and other measures, obviously it can make a lot of contributions to safety, but I still can’t see how it proves that the software is sufficiently safety then that it can support ASIL B, C or D levels, so Maybe "state of the art" is the perfect explanation, if this is what we are after.
Thank you!
B&R. 王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
From: safety-architecture@...
<safety-architecture@...> On Behalf Of Paoloni, Gabriele
Sent: Wednesday, May 26, 2021 2:06 AM To: Paccapeli, Roberto <roberto.paccapeli@...>; Wang YuJue 王玉珏 <wangyujue@...>; Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@... Cc: Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张海鹏-SW <zhanghaipeng02@...> Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi YuJue
From my side I agree with the opinion from Roberto. WRT your statement I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory."
I think that this statement would be correct if the hybrid mode was about the single qualification of the different “SW blocks” or “SW Units” identified in Linux. Instead as you have seen from the deck we are introducing semi-formal and formal methods to describe the interactions between modules and more importantly we are introducing active monitors that verify the code to behave exactly as described by the models. This imply adding a significant amount of collaterals compared to the current Linux baseline: - Formal/semiformal SW architectural design describing the SW blocks/units interactions according to the different functionalities (e.g. ioctl(), open(), watchdog_ioctl(), watchdog_open()..) - Natural Language specifications for the single blocks - FMEA or equivalent safety analyses based on the specs above for each functionality - Best set of CONFIGs following the results of the safety analysis - Eventual code modifications/improvements following the results of the safety analysis - KSelftest campaign for the single blocks qualification - KSeftest campaign for the module integration (with active monitors verifying the real code to behave as modelled)
Then WRT table6 of part6 we cannot apply it to Linux just because it is a pre-existing piece of code that we cannot re-write entirely to meet the table requirements however we have static code analysis in place to spot and evaluate weaknesses.
Thanks Gab
From: Paccapeli, Roberto <roberto.paccapeli@...>
Hi 王玉珏 Wang Yujue,
I share my opinion below:
Q1 I disagree with your interpretation of the standard. You are basically merging “SEooC” and “Qualification of SW component” in a unique method. About 8.12 · << for re-use in items developed in compliance with the ISO 26262 series of standards>> means the context of your qualification activities must refer to an item context developed in compliance with ISO 26262 · <<to provide evidence for their suitability>> sets the goal of your qualification activities. Then to produce sufficient argumentations about the robustness of your design against the considered context. What you have described in your comment is a SEooC method, then SW components designed by adopting a list of AoUs and then developed and tested in accordance with Part 6. While 8.12 is (roughly) a black box approach in which some conditions are explicitly listed in clauses to make it applicable in “practice”.
Then, even if << the current Linux does not use any safety software components >> (and this is the case for a massive amount of SW designs currently available in the market space), conceptually the qualification method can be always applied for justifying its usage (or portions) for FuSa purpose.
Q2 Here I agree partially with you. But I don’t think that the challenge is really on the approach. But on the details of the approach, then on how to ensure there are no mistakes fully addressed.
From another side, we need to take in account that, since the final goal of safety standard is to have no unpredictable or unexpected behavior of intended functionalities, safety standards accept to have some exceptions only if properly analyzed and justified. And then under control.
Q3 Today, I have not observed something in contrast with the ISO 26262 2nd Edition or the intention of the proposers to not recognize the standard as pilar for Functional Safety or to try bypassing something. This hybrid approach seems interesting because it opens the possibility to have something usable in different context and scalable. With that, I am not saying that it is easy to apply… But Gab and Daniel’s line, “Divide and Conquer”, seems better facing the challenges with a concrete tactical scheme. There are other approaches that we could adopt, but, based on my experience, they are mainly focused on specific context, with limited scope due to the complexity of Linux Kernel and then not scalable. But as I said, the last comment is based on my experience 😊
Thanks,
Roberto Paccapeli Functional Safety Manager | IOTG PMCE FSS
D +39 050.782.0014 | M +39 339.589.2630 Via Lenin 132/p | S. Giuliano Terme, Italy, 56017 Intel Corporation | intel.com
From:
safety-architecture@...
<safety-architecture@...>
On Behalf Of Wang YuJue ???
Hi Gab
Thank you for your wonderful sharing, they are very interesting and have caused my questions, u Q That 8.12 is very clear "Objective of the qualification of software components is to provide evidence for their suitability for re-use in items developed in compliance with the ISO 26262 series of standards." The three important elements are "provide evidence", "compliance" and "re-use", This means that if: 1、That currently only have a QM-level (FOSS) Linux software unit, so it is impossible to "provide evidence" that it can "compliance" the safety requirements of the new project (may come from AoU) Or 2、Already have a Linux software unit with safety that has been approved by an some organization, so we can "provide evidence" that it can "compliance" the safety requirements of the new project (also from AoU)， So, in case 1 we all know that the current Linux does not use any safety software components, so how do we talk about "reuse" with safety feature? And in case 2 this original software shall been approved in development according to Part6. It is also impossible to help you bypass the heavy work. u Q I think any formal safety review will not accept the "hybrid approach" you introduced. This is like two 10-year-old girls are not equal to one 20-year-old girl, or two bottles of 10% normal saline mixed together- It will not become 20% concentration also. Imagine that the whole process of your methodology is trying to "a low-cost way to bypass the heavy (But necessary) work and achieve victory." But I don’t think this can solve the safety problem. like You also mentioned - No dynamic objects/variables -No implicit type conversion… These restrictions are all because they are easy to make mistakes, so we prohibit them unless it is proved that their application is reasonable and controllable . I think this is reasonable， After all, we are discussing the possibility of failure of less than 100FIT, which is far beyond The traditional industrial Linux ability, I don't think you can guarantee these safety benefits through your methodology. u Finally, I fully agree with Chris’s opinion that no matter whether the standards are perfect or not, as developers, we must respect the physical safety interests of the product. Any potential safety-related vulnerabilities/failures should be fully identified, This means that if the workload is too large to be accepted, then we should find more efficient equivalent alternatives, rather than bypass them, because this may harm safety interests.
Thank you so much!
B&R 王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
From:
safety-architecture@...
<safety-architecture@...>
On Behalf Of Paoloni, Gabriele
Hi QianChunlei
WRT table6 it is something that we need to discuss (it may happen in the development process WG sometime);
Thanks Gab
From:
safety-architecture@...
<safety-architecture@...>
On Behalf Of Qian ChunLei ???
Hi Gab:
Thanks for the workshop and introduction qualification approach, this is really helpful.
From the workshop, it looks like ELISA is using above Hybrid Approach, I have one question, does this Hybrid Approach mean the small SW unit didn’t need to comply the following Table6 of ISO26262 part-6? And if so, does ISO26262 standard accept this?
钱春雷 QianChunlei | Patrick ) +86 15221412751 基础软件平台 | Basic Software Platform 上海汽车集团股份有限公司零束软件分公司 SAIC Motor Z-ONE Software Company 上海市嘉定区汽车·创新港 | 安研路201号 Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai
邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. |
|
|
|
Paoloni, Gabriele <gabriele.paoloni@...>
Hi YuJue
toggle quoted message
Show quoted text
-----Original Message-----^^^ Why would you add code? enough? From a mathematical point of view, I think it is very dangerous. It is^^^ How can you justify that the probability of systematic failure is magnified by 100 times if, by definition, the hybrid approach implies the single SW block/unit to be simple enough to have the behavior specified comprehensively by the respective specifications and if we are specifying the interactions between blocks using formal or semiformal methods? This is a good point...in fact we need to consider two things: a) we are proposing an integration test campaign leveraging a "verification of the control flow and data flow" (active monitors); this is not required usually for ASILB for example b) Structural coverage is still to be discussed; it is not required in 8.12 for ASILB but we may decide to go for it anyway as additional measure of all these tests are expensive, and then even after implementing them, it isCan Linux be reworked to meet part6? Is it doable? This is the flaw of the "hybrid approach" I want to express (maybe thePersonally I disagree because the hybrid approach could even go to the extreme of specifying a single SW Unit as a single function (if there is such a complex SW component that must be so heavily broken down to be "specified"); BTW we have never discussed, so far, what ASIL level can be claimed as we are still in the first phase of discussion WRT this approach. As of today I don’t think that Linux can be reworked to meet part6 so we are trying to brainstorm to come up with alternate approaches and we are trying to get feedbacks on how to improve such approaches; for instance recently Paul Albertella put on the plate a new approach that we are going to analyze, improve and eventually use if it turns usable/useful. We will continue the evaluation of qualification approaches in the Development Process WG; you are welcome to give feedbacks, propose improvements or even a new approach in the sessions that will come ahead. Thanks Gab --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. |
|
|
|
Wang YuJue 王玉珏
Hi Gab,
The bad typography makes the email difficult to read, so I extracted your reply and attached my thoughts. => Why would you add code? I always try to bring things into the standard original text, so I mean the code that is re-use into the new project is the newly added(into new project) code =>How can you justify that the probability of systematic failure is magnified by 100 times if, by definition, the hybrid approach implies the single SW block/unit to be simple enough to have the behavior specified comprehensively by the respective specifications and if we are specifying the interactions between blocks using formal or semiformal methods? This is not a functional safety methodology, but from the engineering perspective, no method can cover or find problems to 100%, especially in the analysis of FMEDA safety measures-even if we use a very mature and perfect method to go Protect a safety-critical function-we only think that its diagnostic coverage is only 99%-sometimes 99.7% is used, but in any case, it is not 100%, because no one can be perfect. So back to that conclusion, usually, when we use 8-12, we integrate a small number of "low complexity" software units, and think that black box testing is also sufficient-the residual risk is acceptable. And when we have 100 software units that need to be integrated, and the black box detection coverage rate of each unit is 99% -then how much have we missed? 8-12 Should it be used this way? By the way, in my opinion, black box testing cannot detect the soul of the software-that is, the inner behavior, and the test of external performance is far from expressing the logic of software operation in many cases, so if it is a "black box test" Perform dynamic code behavior coverage scoring-it may not even reach 60%. => This is a good point...in fact we need to consider two things: a) we are proposing an integration test campaign leveraging a "verification of the control flow and data flow" (active monitors); this is not required usually for ASILB for example b) Structural coverage is still to be discussed; it is not required in 8.12 for ASILB but we may decide to go for it anyway as additional measure This is really a wise decision! Maybe we can discuss with the experts of the ISO26262 organizing committee-find a way that they approve. I also heard that they are discussing revising and improving this part of the content. =>Personally I disagree because the hybrid approach could even go to the extreme of specifying a single SW Unit as a single function (if there is such a complex SW component that must be so heavily broken down to be "specified"); BTW we have never discussed, so far, what ASIL level can be claimed as we are still in the first phase of discussion WRT this approach. As of today I don’t think that Linux can be reworked to meet part6 so we are trying to brainstorm to come up with alternate approaches and we are trying to get feedbacks on how to improve such approaches; for instance recently Paul Albertella put on the plate a new approach that we are going to analyze, improve and eventually use if it turns usable/useful. We will continue the evaluation of qualification approaches in the Development Process WG; you are welcome to give feedbacks, propose improvements or even a new approach in the sessions that will come ahead. This is also the part that I think needs to be vigilant-because the "extreme way" you pointed out can actually be applied to any software, when other people who don’t understand the background also start to use this method, things will become uncontrollable. I repeatedly saw the words "that Linux can not be reworked to meet part6", which made me realize that I might have missed something (SAIC is following the ELISA formally this month), I understand this is due to the huge amount of Linux code and some of the core concepts it advocates (such as virtual memory dynamic allocation and a large number of pointer calls) are fundamentally in conflict with Part6 resulting in no company or organization that can afford such work costs to re-encode that according to Part6. Of course, from a realistic point of view, I agree with this. This is also one of the main reasons why SAIC hopes to become a member of ELISA -in order to find better solutions, while meeting workload constraints and standard requirements, We are currently considering a way to strengthen the Linux kernel based on specific safety applications for safety program flow/data flow protection, which means restricting lib C API call behavior by analyzing APP call behavior or possibly disabling safety-related function call dynamics Memory or safety isolation. Of course, it is still in a very early conceptual stage, and shortcomings can be seen everywhere. For example, the safety environment built based on the behavior of specific apps is actually very fragile, and portability is very low. So this means that we try to follow in the footsteps of ELISA and ask our questions, and thank you for listening to our opinions,-also Thank you for sharing Paul Albertella's new approach, and we will follow it. --------------
Thank you!
B&R.
王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
-----Original Message-----
From: Paoloni, Gabriele <gabriele.paoloni@...> Sent: Wednesday, May 26, 2021 9:32 PM To: Wang YuJue 王玉珏 <wangyujue@...> Cc: Paccapeli, Roberto <roberto.paccapeli@...>; Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@...; Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张海鹏-SW <zhanghaipeng02@...>; Hua Ming 华明 <huaming@...>; Zhang Tao 张涛-SW <zhangtao14@...> Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi YuJue
> -----Original Message----- > From: Paoloni, Gabriele <gabriele.paoloni@...> > Sent: Wednesday, May 26, 2021 2:58 PM > To: Paoloni, Gabriele <gabriele.paoloni@...> > Subject: FW: [ELISA Safety Architecture WG] one question about Hybrid > approach > > > > From: Wang YuJue 王玉珏 <wangyujue@...> > Sent: Wednesday, May 26, 2021 2:44 PM > To: Paoloni, Gabriele <gabriele.paoloni@...>; Paccapeli, Roberto > <roberto.paccapeli@...>; Qian ChunLei 钱春雷 > <qianchunlei@...>; safety-architecture@... > Cc: Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张 > 海鹏-SW <zhanghaipeng02@...>; Hua Ming 华明 > <huaming@...>; Zhang Tao 张涛-SW > <zhangtao14@...> > Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab. > > I agree with your approach to active monitors, which will effectively > help existing Linux to improve robustness.，But I still have to say > that this cannot eliminate my doubts. > Let’s go back to the Foundation of Functional Safety, > 1) Avoid systematic faults during design, development and > manufacturing > 2) Control of systematic faults during operation > 3) Control of random hardware failures during operation Since our > topic is only part6, let us just consider 1) and 2), however in order > for promoting the use of commercial off-the-shelf software, 8-12 is to > allow the use of similar black box method to approval that > low-complexity software. > This means that from a methodological point of view, it is not in use > either 1), This is true, because for low-complexity software, perfect > black box testing can basically cover all its behaviors with very few > potential risks , which is achievable. > But instead, you now want a re-use software unit-is it really > low-complexity software? > I understand that you want to disassemble each software unit into 8-12 > acceptable low-complexity units through the method of part6-maybe each > software unit only has 1 to 2 thousand lines of code. > Then how many software units that can be considered "low complexity" > need to be integrated? I don't know the exact number, but considering > that we face tens of millions of lines of code, the number should not be small. > The question to be raised at this time is that a certain number of > "low complexity" software units will be integrated in a V development > cycle, does > 8-12 really support this? Essentially, even if you conceptually > decompose a 1 million-line software unit into 100 software sub-units, > you will eventually add > 1 million lines of code to the new project. In this case, is black box > testing ^^^ Why would you add code?
> enough? From a mathematical point of view, I think it is very > dangerous. It is easy to know that the probability of potential > failures not found by black box testing is magnified by 100 times ^^^ How can you justify that the probability of systematic failure is magnified by 100 times if, by definition, the hybrid approach implies the single SW block/unit to be simple enough to have the behavior specified comprehensively by the respective specifications and if we are specifying the interactions between blocks using formal or semiformal methods?
> > Of course, I checked entire document, so I found that in the next > step, Hybrid Approach will return to Part6 and use software unit > integration testing to solve the omission of black box testing. This is also a point of my concern: > Directly conclusion: Part6's Integration Tests or other test concepts > may not be able to solve the safety issues in the Hybrid Approach > solution, at least not as required by ASIL B. > As described earlier, the safety concept of Part 6 is based on 1) + > 2), that is, first restrict the use of high-risk methods such as Table > 3 in the design process, and then use testing methods to find possible > design flaws on this basis. This is a combined approach. > In the new method, we bypassed(Or partially bypassed) 1), so the test > must bear greater responsibility, then how to choose the appropriate > method for testing has become the core of the problem. The traditional > ASIL B test requirements in Part 6 will no longer be sufficient. And I > think tests such as "fault injection" or "MC/DC" need to be > considered, but unfortunately, first This is a good point...in fact we need to consider two things: a) we are proposing an integration test campaign leveraging a "verification of the control flow and data flow" (active monitors); this is not required usually for ASILB for example b) Structural coverage is still to be discussed; it is not required in 8.12 for ASILB but we may decide to go for it anyway as additional measure
> of all these tests are expensive, and then even after implementing > them, it is difficult to prove that this can really effectively find > all potential problems, because we have broken away from the standard’s guidance. Can Linux be reworked to meet part6? Is it doable?
> This is the flaw of the "hybrid approach" I want to express (maybe the > example in the previous email is not appropriate), functional safety > is always a systematic analysis and approval method, and It has always > been different from Lego, which can be assembled freely. > > Finally, I want to express my opinion again. I think your methodology > is a great improvement. After so much effort like static code analysis > and other measures, obviously it can make a lot of contributions to > safety, but I still can’t see how it proves that the software is > sufficiently safety then that it can support ASIL B, C or D levels, so > Maybe "state of the art" is the perfect explanation, if this is what we are after. Personally I disagree because the hybrid approach could even go to the extreme of specifying a single SW Unit as a single function (if there is such a complex SW component that must be so heavily broken down to be "specified"); BTW we have never discussed, so far, what ASIL level can be claimed as we are still in the first phase of discussion WRT this approach.
As of today I don’t think that Linux can be reworked to meet part6 so we are trying to brainstorm to come up with alternate approaches and we are trying to get feedbacks on how to improve such approaches; for instance recently Paul Albertella put on the plate a new approach that we are going to analyze, improve and eventually use if it turns usable/useful. We will continue the evaluation of qualification approaches in the Development Process WG; you are welcome to give feedbacks, propose improvements or even a new approach in the sessions that will come ahead.
Thanks Gab
> > Thank you! > > B&R. > 王玉珏 Wang Yujue > 基础软件平台 | Basic Software Platform > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Paoloni, Gabriele > Sent: Wednesday, May 26, 2021 2:06 AM > To: Paccapeli, Roberto <mailto:roberto.paccapeli@...>; Wang > YuJue > 王玉珏 <mailto:wangyujue@...>; Qian ChunLei 钱春雷 > <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi YuJue > > From my side I agree with the opinion from Roberto. > WRT your statement > I think any formal safety review will not accept the "hybrid approach" > you introduced. This is like two 10-year-old girls are not equal to > one 20-year-old girl, or two bottles of 10% normal saline mixed > together- It will not become 20% concentration also. > Imagine that the whole process of your methodology is trying to "a > low-cost way to bypass the heavy (But necessary) work and achieve victory." > > I think that this statement would be correct if the hybrid mode was > about the single qualification of the different “SW blocks” or “SW > Units” identified in Linux. Instead as you have seen from the deck we > are introducing semi- formal and formal methods to describe the > interactions between modules and more importantly we are introducing > active monitors that verify the code to behave exactly as described by > the models. This imply adding a significant amount of collaterals compared to the current Linux baseline: > - Formal/semiformal SW architectural design describing the SW > blocks/units interactions according to the different functionalities > (e.g. ioctl(), open(), watchdog_ioctl(), watchdog_open()..) > - Natural Language specifications for the single blocks > - FMEA or equivalent safety analyses based on the specs above for each > functionality > - Best set of CONFIGs following the results of the safety analysis > - Eventual code modifications/improvements following the results of > the safety analysis > - KSelftest campaign for the single blocks qualification > - KSeftest campaign for the module integration (with active monitors > verifying the real code to behave as modelled) > > Then WRT table6 of part6 we cannot apply it to Linux just because it > is a pre- existing piece of code that we cannot re-write entirely to > meet the table requirements however we have static code analysis in > place to spot and evaluate weaknesses. > > Thanks > Gab > > From: Paccapeli, Roberto <mailto:roberto.paccapeli@...> > Sent: Tuesday, May 25, 2021 5:12 PM > To: Wang YuJue 王玉珏 <mailto:Wangyujue@...>; Paoloni, Gabriele > <mailto:gabriele.paoloni@...>; Qian ChunLei 钱春雷 > <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi 王玉珏 Wang Yujue, > > I share my opinion below: > > Q1 > I disagree with your interpretation of the standard. You are basically > merging “SEooC” and “Qualification of SW component” in a unique method. > About 8.12 > • << for re-use in items developed in compliance with the ISO 26262 > series of > standards>> means the context of your qualification activities must > standards>> refer to > an item context developed in compliance with ISO 26262 • <<to provide > evidence for their suitability>> sets the goal of your qualification > activities. Then to produce sufficient argumentations about the > robustness of your design against the considered context. > What you have described in your comment is a SEooC method, then SW > components designed by adopting a list of AoUs and then developed and > tested in accordance with Part 6. > While 8.12 is (roughly) a black box approach in which some conditions > are explicitly listed in clauses to make it applicable in “practice”. > > Then, even if << the current Linux does not use any safety software > components >> (and this is the case for a massive amount of SW designs > currently available in the market space), conceptually the > qualification method can be always applied for justifying its usage > (or portions) for FuSa purpose. > > Q2 > Here I agree partially with you. > But I don’t think that the challenge is really on the approach. But on > the details of the approach, then on how to ensure there are no > mistakes fully addressed. > > From another side, we need to take in account that, since the final > goal of safety standard is to have no unpredictable or unexpected > behavior of intended functionalities, safety standards accept to have > some exceptions only if properly analyzed and justified. And then under control. > > Q3 > Today, I have not observed something in contrast with the ISO 26262 > 2nd Edition or the intention of the proposers to not recognize the > standard as pilar for Functional Safety or to try bypassing something. > This hybrid approach seems interesting because it opens the > possibility to have something usable in different context and scalable. > With that, I am not saying that it is easy to apply… But Gab and > Daniel’s line, “Divide and Conquer”, seems better facing the > challenges with a concrete tactical scheme. > There are other approaches that we could adopt, but, based on my > experience, they are mainly focused on specific context, with limited > scope due to the complexity of Linux Kernel and then not scalable. > But as I said, the last comment is based on my experience 😊 > > Thanks, > > > > Roberto Paccapeli > Functional Safety Manager | IOTG PMCE FSS > > D +39 050.782.0014 | M +39 339.589.2630 Via Lenin 132/p | S. > Giuliano Terme, Italy, 56017 Intel Corporation | intel.com > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Wang YuJue ??? > Sent: Tuesday, May 25, 2021 1:50 PM > To: Paoloni, Gabriele <mailto:gabriele.paoloni@...>; Qian > ChunLei 钱 > 春雷 <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab > > Thank you for your wonderful sharing, they are very interesting and > have caused my questions, > * Q > That 8.12 is very clear "Objective of the qualification of software > components is to provide evidence for their suitability for re-use in > items developed in compliance with the ISO 26262 series of standards." > The three important elements are "provide evidence", "compliance" and > "re- use", This means that if: > 1、That currently only have a QM-level (FOSS) Linux software unit, so > it is impossible to "provide evidence" that it can "compliance" the > safety requirements of the new project (may come from AoU) Or > 2、Already have a Linux software unit with safety that has been > approved by an some organization, so we can "provide evidence" that it > can "compliance" the safety requirements of the new project (also from > AoU)， > So, > in case 1 we all know that the current Linux does not use any safety > software components, so how do we talk about "reuse" with safety feature? > And in case 2 this original software shall been approved in > development according to Part6. It is also impossible to help you bypass the heavy work. > * Q > I think any formal safety review will not accept the "hybrid approach" > you introduced. This is like two 10-year-old girls are not equal to > one 20-year-old girl, or two bottles of 10% normal saline mixed > together- It will not become 20% concentration also. > Imagine that the whole process of your methodology is trying to "a > low-cost way to bypass the heavy (But necessary) work and achieve victory." > But I don’t think this can solve the safety problem. like You also > mentioned > - No dynamic objects/variables > -No implicit type conversion… > These restrictions are all because they are easy to make mistakes, so > we prohibit them unless it is proved that their application is > reasonable and controllable . I think this is reasonable， After all, > we are discussing the possibility of failure of less than 100FIT, > which is far beyond The traditional industrial Linux ability, I don't > think you can guarantee these safety benefits through your methodology. > * > Finally, I fully agree with Chris’s opinion that no matter whether the > standards are perfect or not, as developers, we must respect the > physical safety interests of the product. Any potential safety-related > vulnerabilities/failures should be fully identified, This means that > if the workload is too large to be accepted, then we should find more > efficient equivalent alternatives, rather than bypass them, because > this may harm safety interests. > > Thank you so much! > > B&R > 王玉珏 Wang Yujue > 基础软件平台 | Basic Software Platform > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Paoloni, Gabriele > Sent: Tuesday, May 25, 2021 5:30 PM > To: Qian ChunLei 钱春雷 <mailto:qianchunlei@...>; > mailto:safety-architecture@... > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi QianChunlei > > WRT table6 it is something that we need to discuss (it may happen in > the development process WG sometime); my idea is to avoid enforcing it > as part8.12 is used to qualify the “SW Units”. > > Thanks > Gab > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Qian ChunLei ??? > Sent: Tuesday, May 25, 2021 7:07 AM > To: mailto:safety-architecture@... > Subject: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab: > > > Thanks for the workshop and introduction qualification approach, this > is really helpful. > > From the workshop, it looks like ELISA is using above Hybrid Approach, > I have one question, does this Hybrid Approach mean the small SW unit > didn’t need to comply the following Table6 of ISO26262 part-6? And if > so, does ISO26262 standard accept this? > > > > > > > > > 钱春雷 QianChunlei | Patrick > Q +86 15221412751 > 基础软件平台 | Basic Software Platform > 上海汽车集团股份有限公司零束软件分公司 > SAIC Motor Z-ONE Software Company > 上海市嘉定区汽车·创新港 | 安研路201号 > Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai > > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > attivita' di direzione e coordinamento di INTEL CORPORATION, USA This > e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by > others is strictly prohibited. If you are not the intended recipient, > please contact the sender and delete all copies. > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > attivita' di direzione e coordinamento di INTEL CORPORATION, USA This > e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by > others is strictly prohibited. If you are not the intended recipient, > please contact the sender and delete all copies. > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. |
|
|
|
Dear Qian ChunLei and Wang YuJue, I will not go into the details of the technical concerns you raised towards the proposed approach. I just quickly would like to confirm to you: I also feel sad and sorry that some might believe that the approach and activity described would lead to increased confidence to conclude that a specific safety claim is ensured by the software under investigation; and hence, some would make wrong conclusions causing harm to our society based on this unjustified conclusions. Further, there may be others that share this feeling with me. Some attempts of explaining that feeling within the group have been made (in the best interest of guiding the idea into an area of value) and have been ignored by others. Somebody might state that the sketched approach has not been described completely, and there are further steps and activities in which some of the results are used. So under that assumption, we are currently not at a position to actually understand and judge if it is valuable: the unknown extension of all of that might simply turn it in the end into some something valuable. E.g., in the defense of the approach that might turn out to have some valuable contribution, I do agree that some other activity might eventually use some basic _data_ of this investigation, but currently, the value of the investigation is not visible yet. I simply believe the persons that think the approach is valuable need to continue without critical attention of the group and questioning what they are doing. We need to understand the open-source model here: An open-source project is always open: so, any idea and investigation, even the worst idea, may be proposed by anyone. However, there are always multiple co-existing (and potentially competing) proposed ideas in an open-source project. Now, in the course of obtaining contributors for the competing ideas, everyone should really only contribute to those ideas that they themselves believe are valuable and should not contribute to the alternative (in other rather harsh words: simply ignore them). In an open-source project, there is no fixed plan or fixed strategy of only one approach to be followed. If a single open-source project sees this differently, the natural thing to do is simply to "fork": we start a new project with the same goal, but welcome alternative approaches. I hope the ELISA governance acknowledges that we should not drive many contributors to believe we would need to fork, as long as it is really not required. The ELISA governance needs to foster that other approaches can be started and executed (and others may be ignored until they are ready) in order to avoid failure due to a single approach being so centrally enforced and driving away various potential contributors. I personally do not believe in the discussed approach above and hence I simply do not contribute to that and ignore it as much as possible. Feel free to do the same. Just as one example: the presentation of Paul A., Paul S. and Jonathan M. have proposed an alternative idea and approach; maybe that is worth contributing to that. If there is interest, we should form new working groups for the various ideas mentioned in their presentation to work out the further details. I am sure you are welcome in those new groups and your contributions are welcome there. Also, we always welcome new further proposals and ideas. In the best interest of the overall mission and welcoming all your contributions and critical thought, I hope this helps. P.S.: In this email thread, I am happy to explain more details on the open-source model of organisation, decision making, "control" and execution, and this needs to apply to ELISA. I will not comment or assist on the specific technical suggested approach: I already decided to ignore in the best interest of this project and I will not give it any attention as this is the best solution for the existing and any further contributors until the understanding among the contributors has evolved and they raise and reach out with valid and valuable questions to address. Best regards, Lukas |
|
|
|
Paoloni, Gabriele <gabriele.paoloni@...>
Hi Yujue
I used the indentantion that is usually used by Linux mailing list. BTW I am replying inline (GP) hoping that it is ok for you.
Many thanks Gab
From: Wang YuJue
王玉珏 <wangyujue@...>
Sent: Thursday, May 27, 2021 5:39 AM To: Paoloni, Gabriele <gabriele.paoloni@...> Cc: Paccapeli, Roberto <roberto.paccapeli@...>; Qian ChunLei 钱春雷 <qianchunlei@...>; safety-architecture@...; Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张海鹏-SW <zhanghaipeng02@...>; Hua Ming 华明 <huaming@...>; Zhang Tao 张涛-SW <zhangtao14@...> Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid approach
Hi Gab,
The bad typography makes the email difficult to read, so I extracted your reply and attached my thoughts. => Why would you add code? I always try to bring things into the standard original text, so I mean the code that is re-use into the new project is the newly added(into new project) code GP: Ok I see now. I thought that you wanted to add code to the SW component(s) under qualifications; instead you mean code interfacing with the component(s) being qualified
=>How can you justify that the probability of systematic failure is magnified by 100 times if, by definition, the hybrid approach implies the single SW block/unit to be simple enough to have the behavior specified comprehensively by the respective specifications and if we are specifying the interactions between blocks using formal or semiformal methods? This is not a functional safety methodology, but from the engineering perspective, no method can cover or find problems to 100%, especially in the analysis of FMEDA safety measures-even if we use a very mature and perfect method to go Protect a safety-critical function-we only think that its diagnostic coverage is only 99%-sometimes 99.7% is used, but in any case, it is not 100%, because no one can be perfect. So back to that conclusion, usually, when we use 8-12, we integrate a small number of "low complexity" software units, and think that black box testing is also sufficient-the residual risk is acceptable. And when we have 100 software units that need to be integrated, and the black box detection coverage rate of each unit is 99% -then how much have we missed? 8-12 Should it be used this way? By the way, in my opinion, black box testing cannot detect the soul of the software-that is, the inner behavior, and the test of external performance is far from expressing the logic of software operation in many cases, so if it is a "black box test" Perform dynamic code behavior coverage scoring-it may not even reach 60%. GP: I start to be a bit worried that we can
loop forever on this point 😊.
The Hybrid approach is about qualifying simple enough SW blocks using 8.12, however these blocks would be integrated following part6 (specifically part6.10 and following clauses) up in the V diagram.
=> This is a good point...in fact we need to consider two things: a) we are proposing an integration test campaign leveraging a "verification of the control flow and data flow" (active monitors); this is not required usually for ASILB for example b) Structural coverage is still to be discussed; it is not required in 8.12 for ASILB but we may decide to go for it anyway as additional measure This is really a wise decision! Maybe we can discuss with the experts of the ISO26262 organizing committee-find a way that they approve. I also heard that they are discussing revising and improving this part of the content. GP: indeed these are points to be discussed (also remember that we also have static code analysis on our side providing additional mitigation)
=>Personally I disagree because the hybrid approach could even go to the extreme of specifying a single SW Unit as a single function (if there is such a complex SW component that must be so heavily broken down to be "specified"); BTW we have never discussed, so far, what ASIL level can be claimed as we are still in the first phase of discussion WRT this approach. As of today I don’t think that Linux can be reworked to meet part6 so we are trying to brainstorm to come up with alternate approaches and we are trying to get feedbacks on how to improve such approaches; for instance recently Paul Albertella put on the plate a new approach that we are going to analyze, improve and eventually use if it turns usable/useful. We will continue the evaluation of qualification approaches in the Development Process WG; you are welcome to give feedbacks, propose improvements or even a new approach in the sessions that will come ahead. This is also the part that I think needs to be vigilant-because the "extreme way" you pointed out can actually be applied to any software, when other people who don’t understand the background also start to use this method, things will become uncontrollable. I repeatedly saw the words "that Linux can not be reworked to meet part6", which made me realize that I might have missed something (SAIC is following the ELISA formally this month), I understand this is due to the huge amount of Linux code and some of the core concepts it advocates (such as virtual memory dynamic allocation and a large number of pointer calls) are fundamentally in conflict with Part6 resulting in no company or organization that can afford such work costs to re-encode that according to Part6. Of course, from a realistic point of view, I agree with this. This is also one of the main reasons why SAIC hopes to become a member of ELISA -in order to find better solutions, while meeting workload constraints and standard requirements, We are currently considering a way to strengthen the Linux kernel based on specific safety applications for safety program flow/data flow protection, which means restricting lib C API call behavior by analyzing APP call behavior or possibly disabling safety-related function call dynamics Memory or safety isolation. Of course, it is still in a very early conceptual stage, and shortcomings can be seen everywhere. For example, the safety environment built based on the behavior of specific apps is actually very fragile, and portability is very low. So this means that we try to follow in the footsteps of ELISA and ask our questions, and thank you for listening to our opinions,-also Thank you for sharing Paul Albertella's new approach, and we will follow it. GP: Yes this is the spirit !! We are trying to bring different ideas on the plate, evaluate them, find pros and cons; I would be very happy to look deeper in the mitigation measures you are working on (the restrictions you mentioned).
--------------
Thank you!
B&R.
王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
王玉珏 Wang Yujue 基础软件平台 | Basic Software Platform
-----Original Message-----
Hi YuJue
> -----Original Message----- > From: Paoloni, Gabriele <gabriele.paoloni@...> > Sent: Wednesday, May 26, 2021 2:58 PM > To: Paoloni, Gabriele <gabriele.paoloni@...> > Subject: FW: [ELISA Safety Architecture WG] one question about Hybrid > approach > > > > From: Wang YuJue 王玉珏 <wangyujue@...> > Sent: Wednesday, May 26, 2021 2:44 PM > To: Paoloni, Gabriele <gabriele.paoloni@...>; Paccapeli, Roberto > <roberto.paccapeli@...>; Qian ChunLei 钱春雷 > <qianchunlei@...>; safety-architecture@... > Cc: Jiang LingYan 蒋凌燕 <jianglingyan@...>; Zhang HaiPeng 张 > 海鹏-SW <zhanghaipeng02@...>; Hua Ming 华明 > <huaming@...>; Zhang Tao 张涛-SW > <zhangtao14@...> > Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab. > > I agree with your approach to active monitors, which will effectively > help existing Linux to improve robustness.，But I still have to say > that this cannot eliminate my doubts. > Let’s go back to the Foundation of Functional Safety, > 1) Avoid systematic faults during design, development and > manufacturing > 2) Control of systematic faults during operation > 3) Control of random hardware failures during operation Since our > topic is only part6, let us just consider 1) and 2), however in order > for promoting the use of commercial off-the-shelf software, 8-12 is to > allow the use of similar black box method to approval that > low-complexity software. > This means that from a methodological point of view, it is not in use > either 1), This is true, because for low-complexity software, perfect > black box testing can basically cover all its behaviors with very few > potential risks , which is achievable. > But instead, you now want a re-use software unit-is it really > low-complexity software? > I understand that you want to disassemble each software unit into 8-12 > acceptable low-complexity units through the method of part6-maybe each > software unit only has 1 to 2 thousand lines of code. > Then how many software units that can be considered "low complexity" > need to be integrated? I don't know the exact number, but considering > that we face tens of millions of lines of code, the number should not be small. > The question to be raised at this time is that a certain number of > "low complexity" software units will be integrated in a V development > cycle, does > 8-12 really support this? Essentially, even if you conceptually > decompose a 1 million-line software unit into 100 software sub-units, > you will eventually add > 1 million lines of code to the new project. In this case, is black box > testing ^^^ Why would you add code?
> enough? From a mathematical point of view, I think it is very > dangerous. It is easy to know that the probability of potential > failures not found by black box testing is magnified by 100 times ^^^ How can you justify that the probability of systematic failure is magnified by 100 times if, by definition, the hybrid approach implies the single SW block/unit to be simple enough to have the behavior specified comprehensively by the respective specifications and if we are specifying the interactions between blocks using formal or semiformal methods?
> > Of course, I checked entire document, so I found that in the next > step, Hybrid Approach will return to Part6 and use software unit > integration testing to solve the omission of black box testing. This is also a point of my concern: > Directly conclusion: Part6's Integration Tests or other test concepts > may not be able to solve the safety issues in the Hybrid Approach > solution, at least not as required by ASIL B. > As described earlier, the safety concept of Part 6 is based on 1) + > 2), that is, first restrict the use of high-risk methods such as Table > 3 in the design process, and then use testing methods to find possible > design flaws on this basis. This is a combined approach. > In the new method, we bypassed(Or partially bypassed) 1), so the test > must bear greater responsibility, then how to choose the appropriate > method for testing has become the core of the problem. The traditional > ASIL B test requirements in Part 6 will no longer be sufficient. And I > think tests such as "fault injection" or "MC/DC" need to be > considered, but unfortunately, first This is a good point...in fact we need to consider two things: a) we are proposing an integration test campaign leveraging a "verification of the control flow and data flow" (active monitors); this is not required usually for ASILB for example b) Structural coverage is still to be discussed; it is not required in 8.12 for ASILB but we may decide to go for it anyway as additional measure
> of all these tests are expensive, and then even after implementing > them, it is difficult to prove that this can really effectively find > all potential problems, because we have broken away from the standard’s guidance. Can Linux be reworked to meet part6? Is it doable?
> This is the flaw of the "hybrid approach" I want to express (maybe the > example in the previous email is not appropriate), functional safety > is always a systematic analysis and approval method, and It has always > been different from Lego, which can be assembled freely. > > Finally, I want to express my opinion again. I think your methodology > is a great improvement. After so much effort like static code analysis > and other measures, obviously it can make a lot of contributions to > safety, but I still can’t see how it proves that the software is > sufficiently safety then that it can support ASIL B, C or D levels, so > Maybe "state of the art" is the perfect explanation, if this is what we are after. Personally I disagree because the hybrid approach could even go to the extreme of specifying a single SW Unit as a single function (if there is such a complex SW component that must be so heavily broken down to be "specified"); BTW we have never discussed, so far, what ASIL level can be claimed as we are still in the first phase of discussion WRT this approach.
As of today I don’t think that Linux can be reworked to meet part6 so we are trying to brainstorm to come up with alternate approaches and we are trying to get feedbacks on how to improve such approaches; for instance recently Paul Albertella put on the plate a new approach that we are going to analyze, improve and eventually use if it turns usable/useful. We will continue the evaluation of qualification approaches in the Development Process WG; you are welcome to give feedbacks, propose improvements or even a new approach in the sessions that will come ahead.
Thanks Gab
> > Thank you! > > B&R. > 王玉珏 Wang Yujue > 基础软件平台 | Basic Software Platform > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Paoloni, Gabriele > Sent: Wednesday, May 26, 2021 2:06 AM > To: Paccapeli, Roberto <mailto:roberto.paccapeli@...>; Wang > YuJue > 王玉珏 <mailto:wangyujue@...>; Qian ChunLei 钱春雷 > <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi YuJue > > From my side I agree with the opinion from Roberto. > WRT your statement > I think any formal safety review will not accept the "hybrid approach" > you introduced. This is like two 10-year-old girls are not equal to > one 20-year-old girl, or two bottles of 10% normal saline mixed > together- It will not become 20% concentration also. > Imagine that the whole process of your methodology is trying to "a > low-cost way to bypass the heavy (But necessary) work and achieve victory." > > I think that this statement would be correct if the hybrid mode was > about the single qualification of the different “SW blocks” or “SW > Units” identified in Linux. Instead as you have seen from the deck we > are introducing semi- formal and formal methods to describe the > interactions between modules and more importantly we are introducing > active monitors that verify the code to behave exactly as described by > the models. This imply adding a significant amount of collaterals compared to the current Linux baseline: > - Formal/semiformal SW architectural design describing the SW > blocks/units interactions according to the different functionalities > (e.g. ioctl(), open(), watchdog_ioctl(), watchdog_open()..) > - Natural Language specifications for the single blocks > - FMEA or equivalent safety analyses based on the specs above for each > functionality > - Best set of CONFIGs following the results of the safety analysis > - Eventual code modifications/improvements following the results of > the safety analysis > - KSelftest campaign for the single blocks qualification > - KSeftest campaign for the module integration (with active monitors > verifying the real code to behave as modelled) > > Then WRT table6 of part6 we cannot apply it to Linux just because it > is a pre- existing piece of code that we cannot re-write entirely to > meet the table requirements however we have static code analysis in > place to spot and evaluate weaknesses. > > Thanks > Gab > > From: Paccapeli, Roberto <mailto:roberto.paccapeli@...> > Sent: Tuesday, May 25, 2021 5:12 PM > To: Wang YuJue 王玉珏 <mailto:Wangyujue@...>; Paoloni, Gabriele > <mailto:gabriele.paoloni@...>; Qian ChunLei 钱春雷 > <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: RE: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi 王玉珏 Wang Yujue, > > I share my opinion below: > > Q1 > I disagree with your interpretation of the standard. You are basically > merging “SEooC” and “Qualification of SW component” in a unique method. > About 8.12 > • << for re-use in items developed in compliance with the ISO 26262 > series of > standards>> means the context of your qualification activities must > standards>> refer to > an item context developed in compliance with ISO 26262 • <<to provide > evidence for their suitability>> sets the goal of your qualification > activities. Then to produce sufficient argumentations about the > robustness of your design against the considered context. > What you have described in your comment is a SEooC method, then SW > components designed by adopting a list of AoUs and then developed and > tested in accordance with Part 6. > While 8.12 is (roughly) a black box approach in which some conditions > are explicitly listed in clauses to make it applicable in “practice”. > > Then, even if << the current Linux does not use any safety software > components >> (and this is the case for a massive amount of SW designs > currently available in the market space), conceptually the > qualification method can be always applied for justifying its usage > (or portions) for FuSa purpose. > > Q2 > Here I agree partially with you. > But I don’t think that the challenge is really on the approach. But on > the details of the approach, then on how to ensure there are no > mistakes fully addressed. > > From another side, we need to take in account that, since the final > goal of safety standard is to have no unpredictable or unexpected > behavior of intended functionalities, safety standards accept to have > some exceptions only if properly analyzed and justified. And then under control. > > Q3 > Today, I have not observed something in contrast with the ISO 26262 > 2nd Edition or the intention of the proposers to not recognize the > standard as pilar for Functional Safety or to try bypassing something. > This hybrid approach seems interesting because it opens the > possibility to have something usable in different context and scalable. > With that, I am not saying that it is easy to apply… But Gab and > Daniel’s line, “Divide and Conquer”, seems better facing the > challenges with a concrete tactical scheme. > There are other approaches that we could adopt, but, based on my > experience, they are mainly focused on specific context, with limited > scope due to the complexity of Linux Kernel and then not scalable. > But as I said, the last comment is based on my experience 😊 > > Thanks, > > > > Roberto Paccapeli > Functional Safety Manager | IOTG PMCE FSS > > D +39 050.782.0014 | M +39 339.589.2630 Via Lenin 132/p | S. > Giuliano Terme, Italy, 56017 Intel Corporation | intel.com > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Wang YuJue ??? > Sent: Tuesday, May 25, 2021 1:50 PM > To: Paoloni, Gabriele <mailto:gabriele.paoloni@...>; Qian > ChunLei 钱 > 春雷 <mailto:qianchunlei@...>; mailto:safety- > Cc: Jiang LingYan 蒋凌燕 <mailto:jianglingyan@...>; Zhang > HaiPeng 张海鹏-SW <mailto:zhanghaipeng02@...> > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab > > Thank you for your wonderful sharing, they are very interesting and > have caused my questions, > * Q > That 8.12 is very clear "Objective of the qualification of software > components is to provide evidence for their suitability for re-use in > items developed in compliance with the ISO 26262 series of standards." > The three important elements are "provide evidence", "compliance" and > "re- use", This means that if: > 1、That currently only have a QM-level (FOSS) Linux software unit, so > it is impossible to "provide evidence" that it can "compliance" the > safety requirements of the new project (may come from AoU) Or > 2、Already have a Linux software unit with safety that has been > approved by an some organization, so we can "provide evidence" that it > can "compliance" the safety requirements of the new project (also from > AoU)， > So, > in case 1 we all know that the current Linux does not use any safety > software components, so how do we talk about "reuse" with safety feature? > And in case 2 this original software shall been approved in > development according to Part6. It is also impossible to help you bypass the heavy work. > * Q > I think any formal safety review will not accept the "hybrid approach" > you introduced. This is like two 10-year-old girls are not equal to > one 20-year-old girl, or two bottles of 10% normal saline mixed > together- It will not become 20% concentration also. > Imagine that the whole process of your methodology is trying to "a > low-cost way to bypass the heavy (But necessary) work and achieve victory." > But I don’t think this can solve the safety problem. like You also > mentioned > - No dynamic objects/variables > -No implicit type conversion… > These restrictions are all because they are easy to make mistakes, so > we prohibit them unless it is proved that their application is > reasonable and controllable . I think this is reasonable， After all, > we are discussing the possibility of failure of less than 100FIT, > which is far beyond The traditional industrial Linux ability, I don't > think you can guarantee these safety benefits through your methodology. > * > Finally, I fully agree with Chris’s opinion that no matter whether the > standards are perfect or not, as developers, we must respect the > physical safety interests of the product. Any potential safety-related > vulnerabilities/failures should be fully identified, This means that > if the workload is too large to be accepted, then we should find more > efficient equivalent alternatives, rather than bypass them, because > this may harm safety interests. > > Thank you so much! > > B&R > 王玉珏 Wang Yujue > 基础软件平台 | Basic Software Platform > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Paoloni, Gabriele > Sent: Tuesday, May 25, 2021 5:30 PM > To: Qian ChunLei 钱春雷 <mailto:qianchunlei@...>; > mailto:safety-architecture@... > Subject: Re: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi QianChunlei > > WRT table6 it is something that we need to discuss (it may happen in > the development process WG sometime); my idea is to avoid enforcing it > as part8.12 is used to qualify the “SW Units”. > > Thanks > Gab > > From: mailto:safety-architecture@... <mailto:safety- > architecture@...> On Behalf Of Qian ChunLei ??? > Sent: Tuesday, May 25, 2021 7:07 AM > To: mailto:safety-architecture@... > Subject: [ELISA Safety Architecture WG] one question about Hybrid > approach > > Hi Gab: > > > Thanks for the workshop and introduction qualification approach, this > is really helpful. > > From the workshop, it looks like ELISA is using above Hybrid Approach, > I have one question, does this Hybrid Approach mean the small SW unit > didn’t need to comply the following Table6 of ISO26262 part-6? And if > so, does ISO26262 standard accept this? > > > > > > > > > 钱春雷 QianChunlei | Patrick > Q +86 15221412751 > 基础软件平台 | Basic Software Platform > 上海汽车集团股份有限公司零束软件分公司 > SAIC Motor Z-ONE Software Company > 上海市嘉定区汽车·创新港 | 安研路201号 > Auto Innovation Park | 201 Anyan Road, Jiading, Shanghai > > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > attivita' di direzione e coordinamento di INTEL CORPORATION, USA This > e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by > others is strictly prohibited. If you are not the intended recipient, > please contact the sender and delete all copies. > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. > --------------------------------------------------------------------- > INTEL CORPORATION ITALIA S.p.A. con unico socio > Sede: Milanofiori Palazzo E 4 > CAP 20094 Assago (MI) > Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e > Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. > 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad > attivita' di direzione e coordinamento di INTEL CORPORATION, USA This > e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by > others is strictly prohibited. If you are not the intended recipient, > please contact the sender and delete all copies. > 邮件免责申明 > Email Disclaimer > > 本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或 > 其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公 > 开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何 > 内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及 > 其所有复本从系统中删除，切勿使用。 > This email is for the use of the designated receivers only，and the > content is not allowed to be disclosed due to the confidential > information or other reasons. Except for the Company and the > designated receivers of this email, no one shall disclose, > disseminate, distribute, copy, print or use any part of this email or > any content contained therein. If you receive this email by mistake, > please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it. > > 网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送 > 达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公 > 司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担 > 责任。 > Network communication may contain computer viruses or other defects, > which may not be delivered to other systems accurately and / or in > time, or may be blocked by the Company or the designated receivers of this email. > The Company shall not be liable for such errors or omissions and for > any loss arising from this email. > > 本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公 > 司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 > Any contents contained in this email are only for the purpose of > business communication and reference only. Unless explicitly stated > otherwise, the Company shall not assume any legal responsibility for > the accuracy, completeness or fairness of the content contained in the email. > > 本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本 > 邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺， > 任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖 > 章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载 > 任何内容作为其向本公司主张任何权利或利益的正式依据。 > The designated receivers should pay special attention to the fact that > nothing contained in this email shall constitute an offer, invitation > or acceptance by the Company to the designated receivers of this email > and/or its affiliated business entities, and any rights and > obligations are subject to the written documents signed and sealed by > both parties. Except from the written document signed ,sealed and > confirmed by the Company, the receivers and / or its affiliated > business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- INTEL CORPORATION ITALIA S.p.A. con unico socio Sede: Milanofiori Palazzo E 4 CAP 20094 Assago (MI) Capitale Sociale Euro 104.000,00 interamente versato Partita I.V.A. e Codice Fiscale 04236760155 Repertorio Economico Amministrativo n. 997124 Registro delle Imprese di Milano nr. 183983/5281/33 Soggetta ad attivita' di direzione e coordinamento di INTEL CORPORATION, USA
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. 邮件免责申明 Email Disclaimer
本邮件仅供本邮件指定收件人使用，其所载内容可能因含有保密信息或其它原因而不得披露。除本公司及本邮件指定收件人外，任何人不得公开、传播、分发、复制、印刷或使用本邮件之任何部分或其所载之任何内容。如您误收到本邮件，请立即通知本公司，并将原始邮件、附件及其所有复本从系统中删除，切勿使用。 This email is for the use of the designated receivers only，and the content is not allowed to be disclosed due to the confidential information or other reasons. Except for the Company and the designated receivers of this email, no one shall disclose, disseminate, distribute, copy, print or use any part of this email or any content contained therein. If you receive this email by mistake, please notify the Company immediately, and delete the original email, attachments and all copies from the system. Do not use it.
网络通信可能含有计算机病毒或其它缺陷，可能无法准确和/或及时送达其它系统，亦可能受阻而不为本公司或本邮件指定收件人所知。本公司对此类错误或遗漏以及任何因使用本邮件而引致之任何损失概不承担责任。 Network communication may contain computer viruses or other defects, which may not be delivered to other systems accurately and / or in time, or may be blocked by the Company or the designated receivers of this email. The Company shall not be liable for such errors or omissions and for any loss arising from this email.
本邮件所载任何内容仅作为业务层面交流与参考，除非明确说明，本公司不对邮件所载内容之准确性、完整性或公平性等承担任何法律责任。 Any contents contained in this email are only for the purpose of business communication and reference only. Unless explicitly stated otherwise, the Company shall not assume any legal responsibility for the accuracy, completeness or fairness of the content contained in the email.
本邮件指定收件人应特别注意：本邮件所载任何内容不构成本公司对本邮件指定收件人和/或其所属商业实体的任何要约、要约邀请或承诺，任何权利义务皆以双方签字盖章的书面文件为准。除经本公司以签字盖章的书面文件确认外，收件人和/或其所属商业实体不得以本邮件所载任何内容作为其向本公司主张任何权利或利益的正式依据。 The designated receivers should pay special attention to the fact that nothing contained in this email shall constitute an offer, invitation or acceptance by the Company to the designated receivers of this email and/or its affiliated business entities, and any rights and obligations are subject to the written documents signed and sealed by both parties. Except from the written document signed ,sealed and confirmed by the Company, the receivers and / or its affiliated business entity shall not rely on anything contained in this email as the formal basis for claiming any rights or interests to the Company. --------------------------------------------------------------------- This e-mail and any attachments may contain confidential material for |
|
|
