Open jhdalek55 opened 3 years ago
Hi,
Aftermarket suppliers also manufacture new ECUs that add entirely new features to specific vehicle models that were never offered by the OEMs. Garages (including OEM dealers) regularly install aftermarket ECUs (such as radiators), when the OEM has stopped producing them. It's a fallacy that all aftermarket parts are deficient relative to OEM "official" parts. Older vehicles depend heavily on aftermarket parts.
And the newly strengthened Massachusetts Right-to-Repair law complicates both the distribution of ECU firmware updates and the attendant functional safety and cybersecurity issues.
Cheers,
Ira McDonald (Musician / Software Architect)
Chair - SAE Trust Anchors and Authentication TF Co-Chair - TCG Trusted Mobility Solutions WG
Co-Chair - TCG Metadata Access Protocol SG
Chair - Linux Foundation Open Printing WGSecretary - IEEE-ISTO Printer Working GroupCo-Chair - IEEE-ISTO PWG Internet Printing Protocol WGIETF Designated Expert - IPP & Printer MIBBlue Roof Music / High North Inchttp://sites.google.com/site/blueroofmusic http://sites.google.com/site/blueroofmusichttp://sites.google.com/site/highnorthinc http://sites.google.com/site/highnorthincmailto: blueroofmusic@gmail.com blueroofmusic@gmail.com(permanent) PO Box 221 Grand Marais, MI 49839 906-494-2434
On Mon, Dec 21, 2020 at 9:35 PM Lois Anne DeLong notifications@github.com wrote:
First introduced at our industry workshop in May, this issue opens discussion on the complicated topic of how the use of aftermarket equipment and services impacts security systems. Aftermarket companies refurbish and reuse equipment following end-of-life support from OEMs. This means introducing ECUs to a vehicle that the OEM has no control over. In addition, because aftermarket suppliers may not have access to the original design, they often reverse engineer the parts to figure out how it works. Such an approach perhaps keeps these suppliers from being able to glean all relevant design information about the ECU.
This is admittedly a broad topic. When introduced at the workshop, several specific points were raised that could each be broken into separate issues:
- How do we deal with aftermarket ECUs that do not have their own Primary? Can they leverage an OEMs Director repository?
- If an aftermarket ECU does have its own Primary, is each capable of controlling a mutually exclusive set of
- Could ownership of Director be delegated to a third party or owner?
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/uptane/uptane-standard/issues/200, or unsubscribe https://github.com/notifications/unsubscribe-auth/AE33UO4LTSUNSHKMSKGBHRDSWAAWJANCNFSM4VFAIRSA .
Thanks for opening up this discussion, @iramcdonald
Can someone with the right privileges flag the milestone for this issue. Let's make it 2.0.0 for now.
At our 3/16 meeting,, it was suggested that we add a mention of these issues to the Deployment pages for our V.1.2.0.
At our 4/13 meeting, it was agreed we should add an "Emerging Issues" page to Deployment Best Practices that would address topics like this one where no definitive solution is on the horizon. PR # 104 opened a file for this page and @jhdalek55 will draft some initial text. In addition to this issue, the text will address Issues #162, #201, and Issue #86 on the Deployment pages.
At our 8/3 meeting, the suggested action was "some text about this issue may be added to the Deployment pages. This will focus only on the problems and will not put forward any solutions." If we are adding this text, we need a volunteer to draft such text.
I can probably cobble together a rough draft for this, based on what we included in the first whitepaper, as long as several people agree to review the content. I'll try to get this done later in the week.
Addressed in part by Deployment PR #116
Since this issue cannot be resolved at this time, can we make a new label, perhaps PENDING, for issues like this for which cannot say when they answered? I would prefer we did not leave issues like this (#162 #198) labeled "2.0.0" on the repo as it gives the appearance that we did not completed these on-time. Failing that can we leave it posted without a version label at all?
Information added to Deployment via PR #116, which was merged on 12/17. Issue remains open however as we monitor pending developments.
During the 10/11 Uptane Standards meeting, we affirmed that while we cannot propose a solution till V.3.0.0 at the earliest (as this would be a major change and possibly a breaking one), we should review the existing text on this topic in the Deployment Best Practices to ensure it is sufficiently clear and current. The current text can be found at https://github.com/uptane/deployment-considerations/blob/master/exceptional_operations.md#aftermarket-ecus
[At the 1/31/22 Uptane Standards meeting, we agreed to tentatively mark this for 2.2.0. The whitepaper on this topic is scheduled to be released at the end of the year and can serve as a precursor to whatever changes are to be integrated here. Can someone change the milestone?
@mnm678 or @trishankatdatadog ---I can't change version numbers on the Standard. Can someone milestone this for V.2.2.0
First introduced at our industry workshop in May, this issue opens discussion on the complicated topic of how the use of aftermarket equipment and services impacts security systems. Aftermarket companies refurbish and reuse equipment following end-of-life support from OEMs. This means introducing ECUs to a vehicle that the OEM has no control over. In addition, because aftermarket suppliers may not have access to the original design, they often reverse engineer the parts to figure out how it works. Such an approach perhaps keeps these suppliers from being able to glean all relevant design information about the ECU.
This is admittedly a broad topic. When introduced at the workshop, several specific points were raised that could each be broken into separate issues:
I'm opening up this issue so we can begin a dialogue on these and other issues.