safety-architecture@lists.elisa.tech | [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name?

Home Messages Hashtags Subgroups

Date Date 1 - 20 of 21

[ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name?

John MacGregor #490 Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... toggle quoted message Show quoted text On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjournals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticle-p236.xml&;data=04%7C01%7CPeter.Brink%40ul.com%7Cb8f4938355194eaa00f608d90f1d481d%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557440700093838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=wBRt%2FRsN%2FowAOGsa%2FHhvDOMLVfzQNGgKG%2FkMfMkHFDA%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-engineering&;data=04%7C01%7CPeter.Brink%40ul.com%7Cb8f4938355194eaa00f608d90f1d481d%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557440700093838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=g970t8PG%2BYhFdrWjwrUaJVDFkkOYwpcg7eEdXJ%2BnjPs%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farchive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&;data=04%7C01%7CPeter.Brink%40ul.com%7Cb8f4938355194eaa00f608d90f1d481d%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557440700093838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=JoLk4%2B1ayQC0FIP77HfmcoAplvf%2FufQ8zVwHWOZR42s%3D&reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed-2%3Av1%3Aen&;data=04%7C01%7CPeter.Brink%40ul.com%7Cb8f4938355194eaa00f608d90f1d481d%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557440700093838%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=OQJ%2BReYoN3t7NNGlmooMbTHzYh23bw%2BqF%2Fhg9hzhivc%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
More All Messages By This Member
Gurvitz, Eli (Mobileye) #491 And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli
More All Messages By This Member
Christopher Temple #492 It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso-architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris toggle quoted message Show quoted text -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticle -p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b493608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5rMdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540ccd4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180%3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed-2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRUwVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More All Messages By This Member
John MacGregor #493 Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John toggle quoted message Show quoted text On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso-architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticle -p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b493608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5rMdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540ccd4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180%3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed-2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRUwVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More All Messages By This Member
Paoloni, Gabriele <gabriele.paoloni@...> #494 Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab toggle quoted message Show quoted text -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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.
More All Messages By This Member
Elana C #495 Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana toggle quoted message Show quoted text -----Original Message----- From: safety-architecture@... <safety-architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. -------------------------------------------------------------------- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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.
More All Messages By This Member
Paoloni, Gabriele <gabriele.paoloni@...> #496 Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab toggle quoted message Show quoted text -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. -------------------------------------------------------------------- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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.
More All Messages By This Member
John MacGregor #497 Hi At least I now have a framework to explain what's bugging me (Thanks Chris). To Elana's question: Referring to the conceptual model of an architectural description[1] which was linked in Chris' description, safety is a concern to be accounted for in an architecture. In other words, it's an aspect of the architecture. For me, it's a matter of taste if the WG chooses to concentrate on the safety architecture or the architecture in general. If the decision is explicit, I can live with it somehow or other. That being said, I'd focus on all aspects of the architecture in the WG. To Gab's question: I really don't know. But one of the fundamental confusions I see is that both the Development Process WG and the Architecture WG seem to focus on the Kernel on purpose. That is, regardless of their names, they're both the Kernel Architecture WG and the Kernel Development Process WG. As a practical matter, I find that unfortunate. At least in the short term, I think it's more likely that the accreditation route will be over the system. That is, in 26262 terms, we are more likely to be successful certifying over Part 6 in the context of an item or over Part 8 Qualification rather than Part 6 SEooC (terminology from Part 10, Clause 9, Table 4). In that case, the architecture and development processes we should be primarily concerned with are the system integrator's rather than the Kernel's. To the Architecture / Architecture Design question: I think that an architecture, as defined in Chris' reference, is far too abstract for the work the WG is doing. For me, the work is probably being done at the second-last level of abstraction: at the level of an abstract watchdog driver to cover all the possible watchdog drivers for particular watchdog hardware and software implementations. The next level up in abstraction would be at the VFS Level. As I said in the telco, as far I can tell, we're modelling a synchronous call on the driver. As we discussed in the Automotive WG, there's also the possibility of changing the watchdog file in /dev. This probably uses entirely different mechanisms and control flow. The Kernel's decision to implement both a control flow over ioct and /dev was probably a design decision in my terminology. So, for me, the Arch WG is working at the design level at the most. If we want to call that "Architecture Design" I can live with it. Cheers John [1] http://www.iso-architecture.org/ieee-1471/cm/ toggle quoted message Show quoted text On 05/05/2021 11:38, Paoloni, Gabriele wrote: Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. -------------------------------------------------------------------- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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.
More All Messages By This Member
Paoloni, Gabriele <gabriele.paoloni@...> #498 Hi John toggle quoted message Show quoted text -----Original Message----- From: John MacGregor <open.john.macgregor@...> Sent: Wednesday, May 5, 2021 12:23 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi At least I now have a framework to explain what's bugging me (Thanks Chris). To Elana's question: Referring to the conceptual model of an architectural description[1] which was linked in Chris' description, safety is a concern to be accounted for in an architecture. In other words, it's an aspect of the architecture. For me, it's a matter of taste if the WG chooses to concentrate on the safety architecture or the architecture in general. If the decision is explicit, I can live with it somehow or other. That being said, I'd focus on all aspects of the architecture in the WG. To Gab's question: I really don't know. But one of the fundamental confusions I see is that both the Development Process WG and the Architecture WG seem to focus on the Kernel on purpose. That is, regardless of their names, they're both the Kernel Architecture WG and the Kernel Development Process WG. As a practical matter, I find that unfortunate. At least in the short term, I think it's more likely that the accreditation route will be over the system. That is, in 26262 terms, we are more likely to be successful certifying over Part 6 in the context of an item or over Part 8 Qualification rather than Part 6 SEooC (terminology from Part 10, Clause 9, Table 4). I think that we are taking a hierarchical approach where in the domain specific working groups we analyze the system architecture whereas in the safety arc wg and kernel development process wg we focus on the architecture of the kernel; that is the " Software architectural design" according to the ISO26262-6. In summary I don't think that a single "architecture" name fits all the WGs and I would stick to "system architecture" for domain WGs whereas "SW Architecture" or "SW Architecture design" may be used in the safety arch and development process WGs... In that case, the architecture and development processes we should be primarily concerned with are the system integrator's rather than the Kernel's. To the Architecture / Architecture Design question: I think that an architecture, as defined in Chris' reference, is far too abstract for the work the WG is doing. For me, the work is probably being done at the second-last level of abstraction: at the level of an abstract watchdog driver to cover all the possible watchdog drivers for particular watchdog hardware and software implementations. The next level up in abstraction would be at the VFS Level. As I said in the telco, as far I can tell, we're modelling a synchronous call on the driver. As we discussed in the Automotive WG, there's also the possibility of changing the watchdog file in /dev. This probably uses entirely different mechanisms and control flow. The Kernel's decision to implement both a control flow over ioct and /dev was probably a design decision in my terminology. So, for me, the Arch WG is working at the design level at the most. If we want to call that "Architecture Design" I can live with it. I think we can revisit the WG name once we agree on the nomenclature Thanks Gab Cheers John [1] http://www.iso-architecture.org/ieee-1471/cm/ On 05/05/2021 11:38, Paoloni, Gabriele wrote: Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. -------------------------------------------------------------------- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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.
More All Messages By This Member
John MacGregor #499 Hi On 05/05/2021 15:13, Brink, Peter wrote: To several points: Elana: The automotive specification does not call out a safety architecture. It is an expectation that the architectural design (as ISO 26262 refers to it) is going to cover the entire architecture, specifically because attempting to describe the safety mechanisms out of the context of the overall architecture is useless. Gab: I am not sure why the automotive spec calls out "architectural design" instead of SW Architecture, but the descriptions in Part 6 Clause 7 matches the descriptions in the SWEBOK and the ISO 42010 at a conceptual level. I'm not sure either, but 26262 is not explicit enough. Back to my original comment that this goes beyond nomenclature. We should also keep in mind that we're not _just_ talking about 26262. I'm sure that other standards can muddy the waters further. The glossary defines architecture in terms of building blocks and a safety architecture in terms of elements while neither defining system architecture, hardware architecture nor software architecture while mentioning hardware architecture in the context of hardware architecture metrics... Part 3 Clause 5 defines the item and its elements and their interaction with the environment. It seems to be the point where architectural concerns would be addressed. Part 4 Clause 6 requires the development of a system architectural design, which is a system-level technical solution. It also delineates the fundamental split between hardware and software functionality. For me, the architecture, as defined by ISO/IEEE is defined in Part 3 Clause 5; that is, the fundamental concepts of the system and their functionality. This is where the architectural concerns would be addressed. The system architectural design is the first cut at describing how the elements will implement their functionality and is a design in the sense that it is a solution. Part 4 Clause 6 produces the system architectural design, which is presumably broken down into individual hardware and software elements. I'd guess that the resulting set of hardware elements and set of software elements would represent the hardware and software architectural designs, respectively, although the doesn't say so explicitly. The hardware and software architectures seem to have fallen through the cracks, or are they somehow a sub-product of Part 3 Clause 5? At any rate Part 7 jumps right into software architectural design, which represents the software architectural _elements_. After that there is a software unit design, which is a detail design of the software units... and then there's the implementation of the units, by the way. So, to map this to the usual architecture, design, implementation waterfall (neglecting requirements, of course), I'd say: Architecture = Part 3 Clause 5 Design = Part 4 Clause 6 + Part 6 Clause 7 + (Part 6 Clause 8) / 2 Implementation (or Development) = (Part 6 Clause 8) / 2 And "Architectural Design" is some nebulous combination of system architectural design and the software and hardware architectural designs resulting from the split into hardware and software system elements. But it's not unit detail design. Whereby, coming back to Pete's comment, Architecture (Part 3 Clause 5) is definitely separated from Architectural Design. Right? And, I say again for emphasis, the WG should avoid a terminology that is too intimately entwined with 26262. What the Architecture WG is doing and what it should be called will be left as an exercise for the reader, and, remember, a WG by any other name is still a WG. Cheers John Pete -----Original Message----- From: devel@... <devel@...> On Behalf Of Paoloni, Gabriele via lists.elisa.tech Sent: Wednesday, May 5, 2021 3:56 AM To: John MacGregor <open.john.macgregor@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi John -----Original Message----- From: John MacGregor <open.john.macgregor@...> Sent: Wednesday, May 5, 2021 12:23 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi At least I now have a framework to explain what's bugging me (Thanks Chris). To Elana's question: Referring to the conceptual model of an architectural description[1] which was linked in Chris' description, safety is a concern to be accounted for in an architecture. In other words, it's an aspect of the architecture. For me, it's a matter of taste if the WG chooses to concentrate on the safety architecture or the architecture in general. If the decision is explicit, I can live with it somehow or other. That being said, I'd focus on all aspects of the architecture in the WG. To Gab's question: I really don't know. But one of the fundamental confusions I see is that both the Development Process WG and the Architecture WG seem to focus on the Kernel on purpose. That is, regardless of their names, they're both the Kernel Architecture WG and the Kernel Development Process WG. As a practical matter, I find that unfortunate. At least in the short term, I think it's more likely that the accreditation route will be over the system. That is, in 26262 terms, we are more likely to be successful certifying over Part 6 in the context of an item or over Part 8 Qualification rather than Part 6 SEooC (terminology from Part 10, Clause 9, Table 4). I think that we are taking a hierarchical approach where in the domain specific working groups we analyze the system architecture whereas in the safety arc wg and kernel development process wg we focus on the architecture of the kernel; that is the " Software architectural design" according to the ISO26262-6. In summary I don't think that a single "architecture" name fits all the WGs and I would stick to "system architecture" for domain WGs whereas "SW Architecture" or "SW Architecture design" may be used in the safety arch and development process WGs... In that case, the architecture and development processes we should be primarily concerned with are the system integrator's rather than the Kernel's. To the Architecture / Architecture Design question: I think that an architecture, as defined in Chris' reference, is far too abstract for the work the WG is doing. For me, the work is probably being done at the second-last level of abstraction: at the level of an abstract watchdog driver to cover all the possible watchdog drivers for particular watchdog hardware and software implementations. The next level up in abstraction would be at the VFS Level. As I said in the telco, as far I can tell, we're modelling a synchronous call on the driver. As we discussed in the Automotive WG, there's also the possibility of changing the watchdog file in /dev. This probably uses entirely different mechanisms and control flow. The Kernel's decision to implement both a control flow over ioct and /dev was probably a design decision in my terminology. So, for me, the Arch WG is working at the design level at the most. If we want to call that "Architecture Design" I can live with it. I think we can revisit the WG name once we agree on the nomenclature Thanks Gab Cheers John [1] https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.i so-architecture.org%2Fieee-1471%2Fcm%2F&data=04%7C01%7CPeter.Brink %40ul.com%7Cac9e03cf943a4819679108d90fb4634b%7C701159540ccd45f087bd03b 2a3587569%7C0%7C1%7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIjo iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp ;sdata=AaRvJ3yccci1sMGnSOO9TufJIUtS%2BK6CmlQBlZKPSZM%3D&reserved=0 On 05/05/2021 11:38, Paoloni, Gabriele wrote: Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F www.iso-%2F&data=04%7C01%7CPeter.Brink%40ul.com%7Cac9e03cf943 a4819679108d90fb4634b%7C701159540ccd45f087bd03b2a3587569%7C0%7C1% 7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=% 2BLn2fkx4qbKjbH8QxXfo31Cr%2FKeLaPRsRAsOrP7S4Qw%3D&reserved=0 architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. ----------------------------------------------------------------- --- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------------------------------------------- -- 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. -------------------------------------------------------------------- - 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. --------------------------------------------------------------------- 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. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
More All Messages By This Member
Oscar Slotosch #500 Hi, ISO 26262-6 7.2 (General) states: "The software architectural design represents the software architectural elements and their interactions in a hierarchical structure. Static aspects, such as interfaces between the software components, as well as dynamic aspects, such as process sequences and timing behaviour, are described." The "granularity" goes down to the software units, which are defined as "verifyable" units, i.e. this can be single C-function (or if you have one a corresponding QKit) a complete library or "AutoSAR". Kind regards, Oscar -----Ursprüngliche Nachricht----- Von: safety-architecture@... <safety-architecture@...> Im Auftrag von John MacGregor Gesendet: Mittwoch, 5. Mai 2021 18:44 An: Brink, Peter <Peter.Brink@...>; gabriele.paoloni@...; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Betreff: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi On 05/05/2021 15:13, Brink, Peter wrote: To several points: Elana: The automotive specification does not call out a safety architecture. It is an expectation that the architectural design (as ISO 26262 refers to it) is going to cover the entire architecture, specifically because attempting to describe the safety mechanisms out of the context of the overall architecture is useless. Gab: I am not sure why the automotive spec calls out "architectural design" instead of SW Architecture, but the descriptions in Part 6 Clause 7 matches the descriptions in the SWEBOK and the ISO 42010 at a conceptual level. I'm not sure either, but 26262 is not explicit enough. Back to my original comment that this goes beyond nomenclature. We should also keep in mind that we're not _just_ talking about 26262. I'm sure that other standards can muddy the waters further. The glossary defines architecture in terms of building blocks and a safety architecture in terms of elements while neither defining system architecture, hardware architecture nor software architecture while mentioning hardware architecture in the context of hardware architecture metrics... Part 3 Clause 5 defines the item and its elements and their interaction with the environment. It seems to be the point where architectural concerns would be addressed. Part 4 Clause 6 requires the development of a system architectural design, which is a system-level technical solution. It also delineates the fundamental split between hardware and software functionality. For me, the architecture, as defined by ISO/IEEE is defined in Part 3 Clause 5; that is, the fundamental concepts of the system and their functionality. This is where the architectural concerns would be addressed. The system architectural design is the first cut at describing how the elements will implement their functionality and is a design in the sense that it is a solution. Part 4 Clause 6 produces the system architectural design, which is presumably broken down into individual hardware and software elements. I'd guess that the resulting set of hardware elements and set of software elements would represent the hardware and software architectural designs, respectively, although the doesn't say so explicitly. The hardware and software architectures seem to have fallen through the cracks, or are they somehow a sub-product of Part 3 Clause 5? At any rate Part 7 jumps right into software architectural design, which represents the software architectural _elements_. After that there is a software unit design, which is a detail design of the software units... and then there's the implementation of the units, by the way. So, to map this to the usual architecture, design, implementation waterfall (neglecting requirements, of course), I'd say: Architecture = Part 3 Clause 5 Design = Part 4 Clause 6 + Part 6 Clause 7 + (Part 6 Clause 8) / 2 Implementation (or Development) = (Part 6 Clause 8) / 2 And "Architectural Design" is some nebulous combination of system architectural design and the software and hardware architectural designs resulting from the split into hardware and software system elements. But it's not unit detail design. Whereby, coming back to Pete's comment, Architecture (Part 3 Clause 5) is definitely separated from Architectural Design. Right? And, I say again for emphasis, the WG should avoid a terminology that is too intimately entwined with 26262. What the Architecture WG is doing and what it should be called will be left as an exercise for the reader, and, remember, a WG by any other name is still a WG. Cheers John Pete -----Original Message----- From: devel@... <devel@...> On Behalf Of Paoloni, Gabriele via lists.elisa.tech Sent: Wednesday, May 5, 2021 3:56 AM To: John MacGregor <open.john.macgregor@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi John -----Original Message----- From: John MacGregor <open.john.macgregor@...> Sent: Wednesday, May 5, 2021 12:23 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi At least I now have a framework to explain what's bugging me (Thanks Chris). To Elana's question: Referring to the conceptual model of an architectural description[1] which was linked in Chris' description, safety is a concern to be accounted for in an architecture. In other words, it's an aspect of the architecture. For me, it's a matter of taste if the WG chooses to concentrate on the safety architecture or the architecture in general. If the decision is explicit, I can live with it somehow or other. That being said, I'd focus on all aspects of the architecture in the WG. To Gab's question: I really don't know. But one of the fundamental confusions I see is that both the Development Process WG and the Architecture WG seem to focus on the Kernel on purpose. That is, regardless of their names, they're both the Kernel Architecture WG and the Kernel Development Process WG. As a practical matter, I find that unfortunate. At least in the short term, I think it's more likely that the accreditation route will be over the system. That is, in 26262 terms, we are more likely to be successful certifying over Part 6 in the context of an item or over Part 8 Qualification rather than Part 6 SEooC (terminology from Part 10, Clause 9, Table 4). I think that we are taking a hierarchical approach where in the domain specific working groups we analyze the system architecture whereas in the safety arc wg and kernel development process wg we focus on the architecture of the kernel; that is the " Software architectural design" according to the ISO26262-6. In summary I don't think that a single "architecture" name fits all the WGs and I would stick to "system architecture" for domain WGs whereas "SW Architecture" or "SW Architecture design" may be used in the safety arch and development process WGs... In that case, the architecture and development processes we should be primarily concerned with are the system integrator's rather than the Kernel's. To the Architecture / Architecture Design question: I think that an architecture, as defined in Chris' reference, is far too abstract for the work the WG is doing. For me, the work is probably being done at the second-last level of abstraction: at the level of an abstract watchdog driver to cover all the possible watchdog drivers for particular watchdog hardware and software implementations. The next level up in abstraction would be at the VFS Level. As I said in the telco, as far I can tell, we're modelling a synchronous call on the driver. As we discussed in the Automotive WG, there's also the possibility of changing the watchdog file in /dev. This probably uses entirely different mechanisms and control flow. The Kernel's decision to implement both a control flow over ioct and /dev was probably a design decision in my terminology. So, for me, the Arch WG is working at the design level at the most. If we want to call that "Architecture Design" I can live with it. I think we can revisit the WG name once we agree on the nomenclature Thanks Gab Cheers John [1] https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. i so-architecture.org%2Fieee-1471%2Fcm%2F&data=04%7C01%7CPeter.Brin k %40ul.com%7Cac9e03cf943a4819679108d90fb4634b%7C701159540ccd45f087bd03 b 2a3587569%7C0%7C1%7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIj o iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am p ;sdata=AaRvJ3yccci1sMGnSOO9TufJIUtS%2BK6CmlQBlZKPSZM%3D&reserved= 0 On 05/05/2021 11:38, Paoloni, Gabriele wrote: Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F www.iso-%2F&data=04%7C01%7CPeter.Brink%40ul.com%7Cac9e03cf943 a4819679108d90fb4634b%7C701159540ccd45f087bd03b2a3587569%7C0%7C1% 7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=% 2BLn2fkx4qbKjbH8QxXfo31Cr%2FKeLaPRsRAsOrP7S4Qw%3D&reserved=0 architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjou r nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. ----------------------------------------------------------------- --- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------------------------------------------- -- 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. -------------------------------------------------------------------- - 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. --------------------------------------------------------------------- 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. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
More All Messages By This Member
John MacGregor #502 -------------------------------------- Error: I misread the spec and Part 6 Clause 7 has the System Architecture Design, not the Software Architecture Design as input. The process in that clause is responsible for producing the software architecture design. It doesn't change my conclusions much, however. My bad. Sorry for the confusion. And to those with a black-belt in ISO 26262, thanks for not calling me out on it. -------------------------------------- Hi Oscar, yes, that accounts for varying granularity, but not for varying abstraction. For example, in the context of the Sync telco, I noted that two sources[1].[2] used different terms for abstraction in the models at roughly same development phases: SPES [1] HD3 [2] Architecture model Functional Viewpoint Technologically Agnostic Design model Logical Viewpoint Unspecific Tech Aware Implementation model Technical Viewpoint Specific Tech Aware I thought of illustrating the abstractions with an example, and then of using the TellTale system. It looked like it would bloat the email thread intolerably. Considering - We want to use the 26262 approach which switches from a systems viewpoint to a purely software viewpoint and the schema I'm citing don't specifically consider that. - That being said, considering software by itself may be a no-go. Part 6 isn't purely software as it presupposes a system architecture design. The component certification routes outlined in Part 10 Clause 12 all assume a system context as well. - The Arch WG is trying to get generalities out of their analyses and Linux is designed for reuse but the standards and some of their measures and techniques only consider the development of bespoke (single) systems (with the possible exception of an SEooC). - It's a stretch to say that HD3 has anything to do with architecture - It's not clear to me what an "architectural design" is semantically (maybe there's an IEEE spec for it. I don't know. At least, Pete mentioned SWEBOK and ISO 42010.) I's guess it might be called upper-level design, but I don't know where I got that term either. - At least, ELISA shouldn't be using 26262 terminology for cross-domain considerations - This all started when we couldn't find the modelling basis for Fabrizio's FTA, and it might be that textbook definition of these terms and the development process intentions of 26262 play a secondary role for that analysis. Maybe I (we) should go off, work out what modelling, abstraction and granularity have to do with what the Arch WG is doing and let them get on with their analyses. This should all be sorted out in a document rather than an email and presented sometime, somewhere. Although it extends the idea of an ontology, I think that the ontology group (or in new-ELISA terminology committee) should be responsible for unifying our view of the system development phases and their products. I don't know where they're going to store their documents, but I'd ultimately put the document there. @Paul, what do you think? Cheers John [1] https://link.springer.com/book/10.1007/978-3-642-34614-9 [2] https://sil2.osadl.org/documents/HD3.pdf toggle quoted message Show quoted text On 05/05/2021 19:32, Oscar Slotosch wrote: Hi, ISO 26262-6 7.2 (General) states: "The software architectural design represents the software architectural elements and their interactions in a hierarchical structure. Static aspects, such as interfaces between the software components, as well as dynamic aspects, such as process sequences and timing behaviour, are described." The "granularity" goes down to the software units, which are defined as "verifyable" units, i.e. this can be single C-function (or if you have one a corresponding QKit) a complete library or "AutoSAR". Kind regards, Oscar -----Ursprüngliche Nachricht----- Von: safety-architecture@... <safety-architecture@...> Im Auftrag von John MacGregor Gesendet: Mittwoch, 5. Mai 2021 18:44 An: Brink, Peter <Peter.Brink@...>; gabriele.paoloni@...; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Betreff: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi On 05/05/2021 15:13, Brink, Peter wrote: To several points: Elana: The automotive specification does not call out a safety architecture. It is an expectation that the architectural design (as ISO 26262 refers to it) is going to cover the entire architecture, specifically because attempting to describe the safety mechanisms out of the context of the overall architecture is useless. Gab: I am not sure why the automotive spec calls out "architectural design" instead of SW Architecture, but the descriptions in Part 6 Clause 7 matches the descriptions in the SWEBOK and the ISO 42010 at a conceptual level. I'm not sure either, but 26262 is not explicit enough. Back to my original comment that this goes beyond nomenclature. We should also keep in mind that we're not _just_ talking about 26262. I'm sure that other standards can muddy the waters further. The glossary defines architecture in terms of building blocks and a safety architecture in terms of elements while neither defining system architecture, hardware architecture nor software architecture while mentioning hardware architecture in the context of hardware architecture metrics... Part 3 Clause 5 defines the item and its elements and their interaction with the environment. It seems to be the point where architectural concerns would be addressed. Part 4 Clause 6 requires the development of a system architectural design, which is a system-level technical solution. It also delineates the fundamental split between hardware and software functionality. For me, the architecture, as defined by ISO/IEEE is defined in Part 3 Clause 5; that is, the fundamental concepts of the system and their functionality. This is where the architectural concerns would be addressed. The system architectural design is the first cut at describing how the elements will implement their functionality and is a design in the sense that it is a solution. Part 4 Clause 6 produces the system architectural design, which is presumably broken down into individual hardware and software elements. I'd guess that the resulting set of hardware elements and set of software elements would represent the hardware and software architectural designs, respectively, although the doesn't say so explicitly. The hardware and software architectures seem to have fallen through the cracks, or are they somehow a sub-product of Part 3 Clause 5? At any rate Part 7 jumps right into software architectural design, which represents the software architectural _elements_. After that there is a software unit design, which is a detail design of the software units... and then there's the implementation of the units, by the way. So, to map this to the usual architecture, design, implementation waterfall (neglecting requirements, of course), I'd say: Architecture = Part 3 Clause 5 Design = Part 4 Clause 6 + Part 6 Clause 7 + (Part 6 Clause 8) / 2 Implementation (or Development) = (Part 6 Clause 8) / 2 And "Architectural Design" is some nebulous combination of system architectural design and the software and hardware architectural designs resulting from the split into hardware and software system elements. But it's not unit detail design. Whereby, coming back to Pete's comment, Architecture (Part 3 Clause 5) is definitely separated from Architectural Design. Right? And, I say again for emphasis, the WG should avoid a terminology that is too intimately entwined with 26262. What the Architecture WG is doing and what it should be called will be left as an exercise for the reader, and, remember, a WG by any other name is still a WG. Cheers John Pete -----Original Message----- From: devel@... <devel@...> On Behalf Of Paoloni, Gabriele via lists.elisa.tech Sent: Wednesday, May 5, 2021 3:56 AM To: John MacGregor <open.john.macgregor@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi John -----Original Message----- From: John MacGregor <open.john.macgregor@...> Sent: Wednesday, May 5, 2021 12:23 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Copperman, Elana (Mobileye) <elana.copperman@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi At least I now have a framework to explain what's bugging me (Thanks Chris). To Elana's question: Referring to the conceptual model of an architectural description[1] which was linked in Chris' description, safety is a concern to be accounted for in an architecture. In other words, it's an aspect of the architecture. For me, it's a matter of taste if the WG chooses to concentrate on the safety architecture or the architecture in general. If the decision is explicit, I can live with it somehow or other. That being said, I'd focus on all aspects of the architecture in the WG. To Gab's question: I really don't know. But one of the fundamental confusions I see is that both the Development Process WG and the Architecture WG seem to focus on the Kernel on purpose. That is, regardless of their names, they're both the Kernel Architecture WG and the Kernel Development Process WG. As a practical matter, I find that unfortunate. At least in the short term, I think it's more likely that the accreditation route will be over the system. That is, in 26262 terms, we are more likely to be successful certifying over Part 6 in the context of an item or over Part 8 Qualification rather than Part 6 SEooC (terminology from Part 10, Clause 9, Table 4). I think that we are taking a hierarchical approach where in the domain specific working groups we analyze the system architecture whereas in the safety arc wg and kernel development process wg we focus on the architecture of the kernel; that is the " Software architectural design" according to the ISO26262-6. In summary I don't think that a single "architecture" name fits all the WGs and I would stick to "system architecture" for domain WGs whereas "SW Architecture" or "SW Architecture design" may be used in the safety arch and development process WGs... In that case, the architecture and development processes we should be primarily concerned with are the system integrator's rather than the Kernel's. To the Architecture / Architecture Design question: I think that an architecture, as defined in Chris' reference, is far too abstract for the work the WG is doing. For me, the work is probably being done at the second-last level of abstraction: at the level of an abstract watchdog driver to cover all the possible watchdog drivers for particular watchdog hardware and software implementations. The next level up in abstraction would be at the VFS Level. As I said in the telco, as far I can tell, we're modelling a synchronous call on the driver. As we discussed in the Automotive WG, there's also the possibility of changing the watchdog file in /dev. This probably uses entirely different mechanisms and control flow. The Kernel's decision to implement both a control flow over ioct and /dev was probably a design decision in my terminology. So, for me, the Arch WG is working at the design level at the most. If we want to call that "Architecture Design" I can live with it. I think we can revisit the WG name once we agree on the nomenclature Thanks Gab Cheers John [1] https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww. i so-architecture.org%2Fieee-1471%2Fcm%2F&data=04%7C01%7CPeter.Brin k %40ul.com%7Cac9e03cf943a4819679108d90fb4634b%7C701159540ccd45f087bd03 b 2a3587569%7C0%7C1%7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIj o iMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&am p ;sdata=AaRvJ3yccci1sMGnSOO9TufJIUtS%2BK6CmlQBlZKPSZM%3D&reserved= 0 On 05/05/2021 11:38, Paoloni, Gabriele wrote: Hi Elana I would like first to clarify the name "architecture" while it is used in the current discussions that we are having about the hybrid mode. Then we can see if we need to revisit the WG name Thanks Gab -----Original Message----- From: Copperman, Elana (Mobileye) <elana.copperman@...> Sent: Wednesday, May 5, 2021 11:34 AM To: Paoloni, Gabriele <gabriele.paoloni@...>; John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: RE: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Gab, now I am confused. Isn't it safety architecture? This also matches the WG name, as well as the definitions below. Regards Elana -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of Paoloni, Gabriele Sent: Wednesday, May 5, 2021 12:32 PM To: John MacGregor <open.john.macgregor@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 https://nam12.safelinks.protection.outlook.com/?url=http%3A%2F%2F www.iso-%2F&data=04%7C01%7CPeter.Brink%40ul.com%7Cac9e03cf943 a4819679108d90fb4634b%7C701159540ccd45f087bd03b2a3587569%7C0%7C1% 7C637558089702293600%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAi LCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=% 2BLn2fkx4qbKjbH8QxXfo31Cr%2FKeLaPRsRAsOrP7S4Qw%3D&reserved=0 architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjou r nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. ----------------------------------------------------------------- --- - Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ------------------------------------------------------------------- -- 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. -------------------------------------------------------------------- - 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. --------------------------------------------------------------------- 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. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments.
More All Messages By This Member
Paul Albertella #503 Hi John, On 06/05/2021 19:00, John MacGregor wrote: This should all be sorted out in a document rather than an email and presented sometime, somewhere. Although it extends the idea of an ontology, I think that the ontology group (or in new-ELISA terminology committee) should be responsible for unifying our view of the system development phases and their products. I don't know where they're going to store their documents, but I'd ultimately put the document there. @Paul, what do you think? I agree that we need a document (or set of documents) to articulate a common model for this, which can be used to describe the various different approaches to system development that could be taken when using Linux as part of a product, and make it easier to apply. This is exactyly what I had in mind when I was talking about an ontology. Starting with architecture as a first concept and building out from there feels like a good approach. I envisaged this documentation being developed and published in a Github repo, to allow any ELISA contributor with an interest to review it provide input. However, I suggest that we start with a smaller group to discuss this and come up with some preliminary material to share for wider review, and perhaps present at the next Workshop. Perhaps we could have a kick-off call immediately following the Dev Process WG session on Thursday? I can set up the Zoom call. Regards, Paul
More All Messages By This Member
Paul Albertella #504 Hi, This is a tweaked repost of https://lists.elisa.tech/g/safety-architecture/message/503 to a wider audience, as I inadvertently replied to the Safety Architecture WG only. On 06/05/2021 19:00, John MacGregor wrote: This should all be sorted out in a document rather than an email and presented sometime, somewhere. Although it extends the idea of an ontology, I think that the ontology group (or in new-ELISA terminology committee) should be responsible for unifying our view of the system development phases and their products. I don't know where they're going to store their documents, but I'd ultimately put the document there. @Paul, what do you think? I agree that we need a document (or set of documents) to articulate a common model for this, which can be used to describe the various different approaches to system development that could be taken when using Linux as part of a product, and make it easier to apply. This is exactly what I had in mind when I was talking about an ontology. Starting with architecture as a first concept and building out from there feels like a good approach. I envisaged this documentation being developed and published in a GitHub repo, to allow any ELISA contributor with an interest to review it and provide input. However, I suggest that we start with a smaller group to discuss this and come up with some preliminary material to share for wider review, and perhaps present at the next Workshop. Perhaps we could have a kick-off call immediately following the Dev Process WG session on Thursday? I can set up the Zoom call. Regards, Paul
More All Messages By This Member
John MacGregor #505 Hi Paul I'm in for a call after the Dev Proc WG session. Others may not be although, as Thursday is Ascension Day in Germany and it's one of the few opportunities to have a 4 day weekend by taking one day's vacation. Cheers John toggle quoted message Show quoted text On 10/05/2021 10:53, Paul Albertella wrote: Hi John, On 06/05/2021 19:00, John MacGregor wrote: This should all be sorted out in a document rather than an email and presented sometime, somewhere. Although it extends the idea of an ontology, I think that the ontology group (or in new-ELISA terminology committee) should be responsible for unifying our view of the system development phases and their products. I don't know where they're going to store their documents, but I'd ultimately put the document there. @Paul, what do you think? I agree that we need a document (or set of documents) to articulate a common model for this, which can be used to describe the various different approaches to system development that could be taken when using Linux as part of a product, and make it easier to apply. This is exactyly what I had in mind when I was talking about an ontology. Starting with architecture as a first concept and building out from there feels like a good approach. I envisaged this documentation being developed and published in a Github repo, to allow any ELISA contributor with an interest to review it provide input. However, I suggest that we start with a smaller group to discuss this and come up with some preliminary material to share for wider review, and perhaps present at the next Workshop. Perhaps we could have a kick-off call immediately following the Dev Process WG session on Thursday? I can set up the Zoom call. Regards, Paul
More All Messages By This Member
Paul Albertella #506 Hi, On 10/05/2021 10:21, John MacGregor wrote: I'm in for a call after the Dev Proc WG session. Others may not be although, as Thursday is Ascension Day in Germany and it's one of the few opportunities to have a 4 day weekend by taking one day's vacation. Good point. I'm happy to have a kick-off on Wednesday instead, or alternatively we can schedule something for after the Workshop. Regards, Paul
More All Messages By This Member
John MacGregor #507 I'm booked solid on Wednesday, so I'd prefer after the workshop. toggle quoted message Show quoted text On 10/05/2021 11:34, Paul Albertella wrote: Hi, On 10/05/2021 10:21, John MacGregor wrote: I'm in for a call after the Dev Proc WG session. Others may not be although, as Thursday is Ascension Day in Germany and it's one of the few opportunities to have a 4 day weekend by taking one day's vacation. Good point. I'm happy to have a kick-off on Wednesday instead, or alternatively we can schedule something for after the Workshop. Regards, Paul
More All Messages By This Member
John MacGregor #516 Hi, I decided to take a shot at defining Linux' architecture. You'll find it at [1]. It's still very much a work in progress and I intend to flesh things out and fix a couple of boiler-plate explanations. Feel free nonetheless to put issues in the GitHub site or issue pull requests if you're particularly ambitious. Otherwise you can always send me an e-mail. Cheers John [1] https://openjohnmacgregor.github.io/ElisaPages/LinuxArchitecture.html toggle quoted message Show quoted text On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso-architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticle -p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b493608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5rMdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware-engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540ccd4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7CTWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180%3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed-2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4936080208d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C6375574529143488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRUwVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
More All Messages By This Member
John MacGregor #519 Hi Gab, I dunno. I just published my definition of Linux' architecture. It's a long way from what's being looked at in the hybrid mode. Even looking at the ioctl stuff, for me libc (as part of the system environment) and the system call interface are missing. For me, "software architectural design" is a bit of an oxymoron, like "bureaucratic efficiency" or "military intelligence". There's architecture and then there's design. But, that's probably just my problem. In an e-mail subsequent to this[1] (and the subsequent correction [2]), I established that 26262 doesn't really address where software architecture is defined. I have to admit, much to my chagrin, that I've been looking at the 2011 version of 26262 rather than the 2018 version, out of habit actually. In some points, ISO has been clearer in the later version. Note that that software architecture (in Part 6) is the software architecture of the _system_, i.e. the item, not necessarily the software architecture of an element (except, perhaps, an SEooC), or a component. I'd say that Linux is a component, although some might want to view it as an element. In the latest hybrid qualification approach presentation[3], you've discussed the unit design level of the process. Note that according to 7.4.4, the software architectural design stops where the units are merely identified. 8.4.4, on the other hand, says that the unit design should specify the units' functional behaviour and design down to the level necessary for their implementation. I'd say that, considering that in the item's context, an operating system function (superficially) is to allow access to and to manage hardware and software resources , the operating system is a unit and it's a unit at the system software architecture level. I'd also say that 8.4.4 also comprises all of the operating system's architecture, design and implementation considerations. That being said, there's probably no good reason not to apply the software architecture design requirements (7.) to a unit's architecture. The disambiguation would therefore be "software unit design". What do you think? To an extent, that resolves the abstraction / granularity conundrum. But... [4] uses the classification: requirements viewpoint, functional viewpoint, logical viewpoint and technical viewpoint, which I find to be intuitive. As I said in [2], I'd have equated them with different phases in the development process. This doesn't seem to be the case in 26262. I think that my next exercise will be to find some synthesis between part 3 and part 6 as well as the viewpoints I've outlined above. I think it should include an example based on the telltale use case. Again, it should also avoid 26262 terminology. Cheers John [1] https://lists.elisa.tech/g/safety-architecture/message/499 [2] https://lists.elisa.tech/g/safety-architecture/message/502 [3] https://drive.google.com/drive/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2WwQZTF [4] https://link.springer.com/book/10.1007/978-3-642-34614-9 toggle quoted message Show quoted text On 05/05/2021 11:32, Paoloni, Gabriele wrote: Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems* to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A-1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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.
More All Messages By This Member
Paoloni, Gabriele <gabriele.paoloni@...> #546 Hi John Sorry to come back late on this...for some reason I missed it toggle quoted message Show quoted text -----Original Message----- From: John MacGregor <open.john.macgregor@...> Sent: Tuesday, May 25, 2021 1:09 PM To: Paoloni, Gabriele <gabriele.paoloni@...>; Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Gab, I dunno. I just published my definition of Linux' architecture. It's a long way from what's being looked at in the hybrid mode. Even looking at the ioctl stuff, for me libc (as part of the system environment) and the system call interface are missing. For me, "software architectural design" is a bit of an oxymoron, like "bureaucratic efficiency" or "military intelligence". There's architecture and then there's design. But, that's probably just my problem. In an e-mail subsequent to this[1] (and the subsequent correction [2]), I established that 26262 doesn't really address where software architecture is defined. I have to admit, much to my chagrin, that I've been looking at the 2011 version of 26262 rather than the 2018 version, out of habit actually. In some points, ISO has been clearer in the later version. Note that that software architecture (in Part 6) is the software architecture of the _system_, i.e. the item, not necessarily the software architecture of an element (except, perhaps, an SEooC), or a component. I'd say that Linux is a component, although some might want to view it as an element. In my view the question is "would you consider Linux as a SW Unit (as defined in ISO26262-1-3.159) ? " If we look at the term 3.159 above we read: <<3.159 software unit atomic level software component (3.157) of the software architecture (3.1) that can be subjected to stand-alone testing (3.169)>> In my personal opinion Linux cannot be,usually, seen as an atomic level SW component, given its complexity and the amount of nominal and safety requirements allocated to it. Instead I think that there are multiple levels of SW Archictural design (part6.7) (starting from a high level system view) where also Linux needs to be decomposed. In the latest hybrid qualification approach presentation[3], you've discussed the unit design level of the process. Note that according to 7.4.4, the software architectural design stops where the units are merely identified. 8.4.4, on the other hand, says that the unit design should specify the units' functional behaviour and design down to the level necessary for their implementation. I'd say that, considering that in the item's context, an operating system function (superficially) is to allow access to and to manage hardware and software resources , the operating system is a unit and it's a unit at the system software architecture level. From my previous experience usually a SW unit is identified as a single function (in C) I'd also say that 8.4.4 also comprises all of the operating system's architecture, design and implementation considerations. That being said, there's probably no good reason not to apply the software architecture design requirements (7.) to a unit's architecture. From this statement it seems to me that we are aligned from a "common sense" point of view; i.e. Linux is complex and must be decomposed, hence 7. applies. The disambiguation would therefore be "software unit design". What do you think? Personally I don’t like it as, as said above, I am used to think of a SW unit as a single function and plus in the hybrid approach a SW Unit would be exactly a component qualified following part8.12 (plus additional design measures as needed and to be discussed); however let's discuss it, I am open to revisit the terminology if other people think that "SW Unit Design" is the right terminology to describe what I have called "SW Architectural Design" previously.... Thanks Gab To an extent, that resolves the abstraction / granularity conundrum. But... [4] uses the classification: requirements viewpoint, functional viewpoint, logical viewpoint and technical viewpoint, which I find to be intuitive. As I said in [2], I'd have equated them with different phases in the development process. This doesn't seem to be the case in 26262. I think that my next exercise will be to find some synthesis between part 3 and part 6 as well as the viewpoints I've outlined above. I think it should include an example based on the telltale use case. Again, it should also avoid 26262 terminology. Cheers John [1] https://lists.elisa.tech/g/safety-architecture/message/499 [2] https://lists.elisa.tech/g/safety-architecture/message/502 [3] https://drive.google.com/drive/folders/1BoK0PC1yYWuVtT4AuK_VW1T2U2 WwQZTF [4] https://link.springer.com/book/10.1007/978-3-642-34614-9 On 05/05/2021 11:32, Paoloni, Gabriele wrote: Hi guys WRT the discussions that we are having right now about the hybrid mode I think that the best nomenclature would be "SW Architecture" or "SW Architecture Design" and to disambiguate we could clearly refer to: ISO26262-6.7 - " Software architectural design". What do you think? Thanks Gab -----Original Message----- From: safety-architecture@... <safety- architecture@...> On Behalf Of John MacGregor Sent: Wednesday, May 5, 2021 10:30 AM To: Christopher Temple <Christopher.Temple@...>; Gurvitz, Eli (Mobileye) <eli.gurvitz@...>; Peter.Brink@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Chris The referenced definition is great - in-depth, with a discussion of the different perceptions of the term "architecture" and then again not too long. It addresses my concern that the definition must be more than just nomenclature. Note the link at the top of the page to the conceptual model. While it's more or less what I would have expected, I liked the emphasis on the facts that the model is abstract and that it should focus on documenting the concerns and decisions driving the architecture. I hope we can find more such good descriptions for other problematic terms in the realm of safety and embedded systems. Cheers John On 04/05/2021 23:11, Christopher Temple wrote: It could be a long discussion. Couldn't we work with ISO/IEC/IEEE 42010 http://www.iso- architecture.org/ieee-1471/defining-architecture.html ? It's quite close to the understandings shared below. Best regards Chris -----Original Message----- From: devel@... <devel@...> On Behalf Of Gurvitz, Eli (Mobileye) via lists.elisa.tech Sent: Dienstag, 4. Mai 2021 23:01 To: Peter.Brink@...; open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? And I'd like to add that the first 3 types of "architecture"s that Paul lists below are one and the same, phrased in different forms of technical English. So I'd like to suggest that we think of "architecture" as a set of components, their properties and the interfaces between them. Together they comprise a "system" whose purpose is to implement some specific requirements. Thanks, Eli -----Original Message----- From: devel@... <devel@...> On Behalf Of Brink, Peter via lists.elisa.tech Sent: Tuesday, May 04, 2021 20:16 To: open.john.macgregor@...; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Which is kind of the point of an architecture 😊 -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 10:14 AM To: Brink, Peter <Peter.Brink@...>; Paul Albertella <paul.albertella@...>; devel@...; safety- architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Mea Culpa, I've always been guilty of seeing the forest and forgetting a couple of trees... On 04/05/2021 19:12, Brink, Peter wrote: Not a botanist indeed, John. You left off the calyx and the corolla in your flower description. -----Original Message----- From: devel@... <devel@...> On Behalf Of John MacGregor via lists.elisa.tech Sent: Tuesday, May 4, 2021 9:54 AM To: Paul Albertella <paul.albertella@...>; devel@...; safety-architecture@... Subject: Re: [ELISA Technical Community] [ELISA Safety Architecture WG] What’s in a name? Hi Paul Great start. I'd have started with Shakespeare too! The point for me, as I said in the last Sync Telco, was the issue is not just the nomenclature. It's understanding what comprises each of the concepts and what role in the development process they serve. An architecture differs from a design which differs from an implementation at least in the level of abstraction and granularity. I'll probably have to expand on the idea in the future (and I don't have time now). But for now, I'll give a small example: The architecture of a rose is probably aligned with the attributes that make it recognisable: - a stem with thorns, branches and leaves - a flower with a certain distinctive petal form - a distinctive smell that may or may not repel enemies The design of a rose could - refine the shape and effects of the thorns, branches, leaves, petals, to support structural stability, environmental robustness, etc. - address nourishment and reproduction issues, adding roots, pistils and stamen The implementation of a rose might detail the different breeds of roses.... Hey, even botanists get it :-) [1] I'm not a botanist, and off the top of my head, I'm not sure whether the non-functional aspects (nourishment and reproduction) aren't architectural concerns, but I'm using the example as a light-hearted example of the differences in abstraction and granularity. Cheers John BTW, the _Name_ of the Rose is a vaastly different kettle of fish. [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fjour nals.ashs.org%2Fhortsci%2Fview%2Fjournals%2Fhortsci%2F54%2F2%2Farticl e - p236.xml&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b4 93608 0208d90f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C63755 74529 14338884%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoi V2luMzIiL CJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=twe4Zl9o6LJSxw5r MdDA3wv ionay%2BhN%2Fs7zGnrSK0dc%3D&reserved=0 On 04/05/2021 18:19, Paul Albertella wrote: Hi, What’s in a name? that which we call a rose By any other name would smell as sweet --- W Shakespeare "Romeo and Juliet" As John MacGregor commented on today's Safety Architecture call, our discussions are occasionally marred by misunderstandings arising from the use of terminology that seems to be unambiguous, but actually means different things to different people, or in different contexts. I believe that we can help to address this by compiling a common 'lexicon' of terms and definitions that we can use in ELISA discussions and publications, relating these to specific domains or contexts where necessary. The term 'architecture', which John picked on today, for example, has at least four distinct meanings in the context of ELISA. Here are are some definitions that may be helpful: 1) Software architecture The Software Engineering Body of Knowledge [1] includes architecture under the general heading of design, noting that "Architectural design describes how software is organized into components", while "Detailed design describes the desired behavior of these components." It adds that a software architecture can be strictly defined as "the set of structures needed to reason about the system, which comprise software elements, relations among them, and properties of both”, but notes that it can be further subdivided into 'views' (physical, logical, process, development), focusing on different aspects of the system (distribution, functionality, concurrency, implementation). 2) System architecture This has a very similar meaning to the term in the software context, but extends the scope to include the hardware components of a system. IEC 61508 defines architecture as a "specific configuration of hardware and software elements in a system". ISO 26262 [3] applies the term to both hardware/software combinations and pure software elements, defining it as a "representation of the structure of the item or element that allows identification of building blocks, their boundaries and interfaces, and includes the allocation of requirements to these building blocks". 3) Safety architecture This is more or less the same as a system architecture, but focussing only on safety. ISO 26262 [3] defines it as the "set of elements and their interaction to fulfil the safety requirements", where an element may be a system, component (hardware or software), hardware part, or software unit. 4) CPU architecture The term 'architecture' in discussions about the Linux kernel frequently has a different meaning again, referring to the underlying architecture of the processor (x86, ARM, MIPs, etc) in a target system, and the associated 'architecture-specific' components of the kernel. Regards, Paul [1] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .computer.org%2Feducation%2Fbodies-of-knowledge%2Fsoftware- engineerin g&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=NpmQyjx9wYhQDEzy8z5 s98f4p7i nt%2Fr5DqGlDlkTWAQ%3D&reserved=0 [2] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Farc hive.org%2Fdetails%2Fgov.in.is.iec.61508.4.1998&data=04%7C01%7CPe ter.Brink%40ul.com%7C1343db7da51b4936080208d90f201ff9%7C701159540cc d4 5f087bd03b2a3587569%7C0%7C0%7C637557452914348879%7CUnknown%7C TWFpbGZs b3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn 0%3 D%7C1000&sdata=3RMrJan1IqiCJ0Wv4kgXQqTAtpThyJjNhUcZckGJ180% 3D&amp ;reserved=0 [3] https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fww w .iso.org%2Fobp%2Fui%2F%23iso%3Astd%3Aiso%3A26262%3A- 1%3Aed- 2%3Av1%3Ae n&data=04%7C01%7CPeter.Brink%40ul.com%7C1343db7da51b49360802 08d90 f201ff9%7C701159540ccd45f087bd03b2a3587569%7C0%7C0%7C637557452914 3488 79%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luM zIiLCJBTi I6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=4XCPMIOfGI1ZLwmLRU wVf4fjET7 FtlQZYxGd%2FESASoU%3D&reserved=0 This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. This e-mail may contain privileged or confidential information. If you are not the intended recipient: (1) you may not disclose, use, distribute, copy or rely upon this message or attachment(s); and (2) please notify the sender by reply e-mail, and then delete this message and its attachment(s). Underwriters Laboratories Inc. and its affiliates disclaim all liability for any errors, omissions, corruption or virus in this message or any attachments. --------------------------------------------------------------------- Intel Israel (74) Limited 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. IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. --------------------------------------------------------------------- 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. --------------------------------------------------------------------- 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.
More All Messages By This Member

1 - 20 of 21

Previous Topic Next Topic

Home Hashtags Subgroups Terms