Safety control for electronic control units

Abstract

A method for securing an electronic control unit (ECU). The method can include generating a granular security control adjustment authorization ticket (G-SCAAT) for securing the ECU based on a plurality of security parameters determined based on a role selected for a corresponding user. The G-SCAAT can include a security value to be used to control the ECU to operate in accordance with the security parameters.

Description

Technical Field

[0001] introduction This disclosure relates to providing security controls for electronic control units (ECUs), such as using a granular security control adjustment authorization ticket (G-SCAAT) configured to adjust the security controls of the ECU according to multiple selectable roles. Background Technology

[0002] An electronic control unit (ECU) can be considered a computer, microcontroller, or other processing element configured to provide or otherwise support one or more operations, functions, processes, etc., such as by outputting corresponding signals, data, controls, etc., to a dependent system. For example, when used in conjunction with a main unit (such as a car), various ECUs can be used as engine control modules (ECMs), telematics units (TUs), powertrain control modules (PCMs), transmission control modules (TCMs), brake control modules (BCMs), central control modules (CCMs), central timing modules (CTMs), passenger door modules (PDMs), system control modules (SCMs), airbag control modules (ACMs), battery management systems (BMSs), general electronic modules (GEMs), body control modules (BCMs), suspension control modules (SCMs), etc.

[0003] ECUs can be supplied by the vendor for installation at the OEM factory, such as by installing the ECU as part of an original equipment manufacturer (OEM) assembly line for assembling automobiles. At factory installation, the ECU is programmed with an initial set of values ​​configured to calibrate its operation according to nominal design parameters. Since the relevant calibration of the ECU is set when the ECU and / or OEM leave the factory, this initial set of values ​​can be considered factory settings or factory values. As part of the design, development, or manufacturing process, it may be necessary to program the ECU to accommodate software patches or other operational requirements, and additional programming modifications may be expected after the ECU is manufactured and / or after it is installed in the OEM. With any potential programming requirements, it is desirable to have safety controls in place to ensure that authorized individuals program the ECU and that authorized individuals program the ECU within authorized programming constraints. Summary of the Invention

[0004] One non-limiting aspect of this disclosure envisions providing security controls for an electronic control unit (ECU) or other programmable device. The security controls may be based at least in part on a Granular Security Control Adjustment Authorization Ticket (G-SCAAT), which is configured to adjust the security controls according to a plurality of security parameters. These security parameters may be set according to a plurality of roles, whereby each of these roles may differ in the programming permissions, capabilities, constraints, requirements, and / or prerequisites used to adjust the security controls. This type of role-based approach can be advantageous for setting security parameters at a granular level and thereby limiting ineffective security measures to a controllable set of constraints, which may be controlled (metered out) based on one or more roles assigned to the requesting individual or entity.

[0005] This document discloses a method for ensuring the safety of an electronic control unit (ECU). The method may include: receiving a request associated with a user requesting to program the ECU; selecting a role for the user from a plurality of available roles; and generating a Granular Safety Control Adjustment Authorization Ticket (G-SCAAT) for ensuring ECU safety based on a plurality of safety parameters determined based on the role selected for the user. The G-SCAAT may specify safety values ​​to be used to control the ECU to operate according to the safety parameters.

[0006] The method may include associating a background counter with G-SCAAT. The background counter may be configured to monotonically increase a counter value set for G-SCAAT according to a predefined schedule.

[0007] The method may include performing an authentication process at the ECU, at least in part, based on a received background counter. This authentication process may be configured to generate one of a pass / fail determination for the authenticity of the G-SCAAT.

[0008] The method may include: generating a pass / fail determination if the background counter matches an expiry counter included as part of a security value; and generating a fail / fail determination if the background counter fails to match an expiry counter.

[0009] The method may include: limiting the acceptance criteria to additionally requiring the Message Authentication Code (MAC) included as part of G-SCAAT to match the ECU MAC generated at the ECU.

[0010] This method may include transmitting a log message indicating a pass or fail determination from the ECU to a background process. The background process may be configured to generate a G-SCAAT and associate a background counter with it.

[0011] The method may include: executing a request-response strategy between the ECU and the background as at least part of an installation process configured to install G-SCAAT on the ECU.

[0012] The method may include: limiting each of the plurality of available roles to include at least one security value that is different from the security values ​​of the other roles.

[0013] The method may include: determining the security parameters to include multiple role-based parameters and multiple non-role-based parameters. Role-based parameters may have corresponding security values ​​set according to the selected role. Non-role-based parameters may have corresponding security values ​​set independently of the selected role.

[0014] The method may include: determining security parameters as one or more partitions within the memory of the ECU that can be unlocked; and assigning a module identifier (ID) to each partition as part of the security value.

[0015] The method may include: determining the safety parameters to include one or more safety control parameters; and specifying one of the safety values ​​for each safety control parameter.

[0016] The method may include: determining the security control parameters as including security programming application software parameters, security programming calibration software parameters, in-vehicle network message authentication parameters, security boot parameters, host debugging parameters, and hardware security module (HSM) or trusted zone debugging parameters.

[0017] The method may include: determining the security parameters to include one or more diagnostic unlock level parameters; and specifying one of the security values ​​for each unlock level parameter.

[0018] The method may include: determining diagnostic unlock level parameters as including service parameters, assembly plant parameters, over-the-air (OTA) download parameters, engineering parameters, remote diagnostic parameters, and / or supplier parameters.

[0019] The method may include: determining security parameters including creation count parameters, expiration count parameters, application start date identifier (NBID) parameters, hardware security module (HSM) NBID parameters, boot / software compatibility ID (BCID) parameters, security control adjustment parameters, unlock level parameters, module ID parameters, option parameters, and ignition count parameters.

[0020] The method may include: determining security parameters including ECU name parameters, ECU ID parameters, G-SCAAT signature certificate parameters, signature parameters, and message authentication code (MAC) parameters.

[0021] This document discloses a method for ensuring the safety of an electronic control unit (ECU). The method may include: selecting a profile from a plurality of available profiles for ensuring ECU safety. Each of these profiles may define a plurality of safety parameters for correspondingly ensuring ECU safety. The method may further include: generating a Granular Safety Control Adjustment Authorization Ticket (G-SCAAT) for installation on the ECU, including specifying a safety value within the G-SCAAT for each of the safety parameters defined for the selected profile. The ECU may be configured to ensure ECU safety based on the safety values ​​specified in the G-SCAAT.

[0022] The method may include associating a background counter with the G-SCAAT. The background counter may be configured to monotonically increase a counter value set for the G-SCAAT according to a predefined schedule. The method may further include performing an authentication process after the G-SCAAT is installed on the ECU. The authentication process may include the ECU generating one of a pass / fail judgment for the authenticity of the G-SCAAT, depending on whether the background counter matches an expiration counter included as part of a safety value. The method may further include transmitting a log message indicating a pass or fail judgment from the ECU to the background.

[0023] The method may include: defining each of the plurality of available profiles as having at least one security value that differs from the security values ​​for other roles; and determining the security parameters to include a plurality of role-based parameters and a plurality of non-role-based parameters. Role-based parameters may have corresponding security values ​​set according to the role of the user associated with the selected profile. Non-role-based parameters may have corresponding security values ​​set independently of the selected role.

[0024] This document discloses a method for ensuring the safety of an electronic control unit (ECU). The method may include: generating a granular safety control adjustment authorization ticket (G-SCAAT) for installation on the ECU. The G-SCAAT may specify one or more safety values ​​for each of a plurality of safety parameters. The method may further include: transmitting the G-SCAAT from a background process to the ECU as part of an installation procedure. The ECU may be configured to ensure ECU safety based on the safety values ​​specified in the G-SCAAT. The method may further include: in response to the ECU performing an authentication process for authenticating the safety values ​​after the G-SCAAT is installed, transmitting a log message from the ECU to a background process. The log message may identify one of a pass / fail decision for the authentication process.

[0025] This invention includes at least the following technical solutions: Option 1. A method for ensuring the safety of an electronic control unit (ECU), the method comprising: Receive a request associated with a user who requests to program the ECU; Select a role for the user from among multiple available roles; and Generating a Granular Security Control Adjustment Authorization Ticket (G-SCAAT) to ensure the safety of the ECU based on multiple security parameters, including specifying security values ​​within the G-SCAAT to be used to control the ECU to operate according to the security parameters, the multiple security parameters being determined based on the role selected for the user.

[0026] Option 2. According to the method of Option 1, the method further includes: associating a background counter with the G-SCAAT, the background counter being configured to monotonically increase according to a predefined progress of a counter value set for the G-SCAAT.

[0027] Option 3. According to the method of Option 2, the method further includes: performing an authentication process at the ECU based at least in part on receiving the background counter, the authentication process being configured to generate one of a pass / fail judgment for the authenticity of the G-SCAAT.

[0028] Option 4. According to the method of Option 3, the method further includes: generating the pass / fail determination if the background counter matches an expiration counter included as part of the security value; and generating the fail / fail determination if the background counter fails to match the expiration counter.

[0029] Option 5. According to the method of Option 4, the method further includes: limiting the qualification determination to additionally requiring that the Message Authentication Code (MAC) included as part of the G-SCAAT matches the ECUMAC generated at the ECU.

[0030] Option 6. According to the method of Option 3, the method further includes: transmitting a log message indicating the pass or fail determination from the ECU to a background, the background being configured to generate the G-SCAAT and associate the background counter with it.

[0031] Option 7. The method according to Option 6, the method further comprising: executing a request-response strategy between the ECU and the background as at least part of an installation process configured to install the G-SCAAT on the ECU.

[0032] Option 8. According to the method of Option 1, the method further includes: defining each of the plurality of available roles as including at least one security value that is different from the security values ​​of the other roles.

[0033] Solution 9. According to the method of Solution 1, the method further includes: determining the security parameters to include a plurality of role-based parameters and a plurality of non-role-based parameters, wherein the role-based parameters have a corresponding security value set according to the selected role among the security values, and the non-role-based parameters have a corresponding security value set independently of the selected role among the security values.

[0034] Option 10. According to the method of Option 1, the method further includes: determining the security parameter as one or more unlockable partitions within the memory of the ECU; and assigning a module identifier (ID) to each partition as part of the security value.

[0035] Option 11. According to the method of Option 1, the method further includes: determining the security parameter to include one or more security control parameters; and specifying one of the security values ​​for each security control parameter.

[0036] Option 12. According to the method described in Option 11, the method further includes: determining the security control parameters to include security programming application software parameters, security programming calibration software parameters, in-vehicle network message authentication parameters, security boot parameters, host debugging parameters, and hardware security module (HSM) or trusted zone debugging parameters.

[0037] Option 13. According to the method of Option 1, the method further includes: determining the security parameter to include one or more diagnostic unlock level parameters; and specifying one of the security values ​​for each unlock level parameter.

[0038] Option 14. According to the method of Option 13, the method further includes: determining the diagnostic unlock level parameters to include service parameters, assembly plant parameters, over-the-air (OTA) download parameters, engineering parameters, remote diagnostic parameters, and / or supplier parameters.

[0039] Option 15. According to the method described in Option 1, the method further includes: determining the security parameters as including creation count parameters, expiration count parameters, application start date identifier (NBID) parameters, hardware security module (HSM) NBID parameters, boot / software compatibility ID (BCID) parameters, security control adjustment parameters, unlock level parameters, module ID parameters, option parameters, and ignition count parameters.

[0040] Option 16. According to the method of Option 15, the method further includes: determining the security parameters to include ECU name parameters, ECU ID parameters, G-SCAAT signature certificate parameters, signature parameters, and message authentication code (MAC) parameters.

[0041] Option 17. A method for ensuring the safety of an electronic control unit (ECU), the method comprising: Select a configuration file from a plurality of available configuration files to ensure the safety of the ECU, each of the configuration files defining a plurality of safety parameters for correspondingly ensuring the safety of the ECU; and A granular safety control adjustment authorization ticket (G-SCAAT) is generated for installation on the ECU, including a specified safety value in the G-SCAAT for each of the safety parameters defined for a selected profile, the ECU being configured to ensure the ECU's safety based on the safety value specified in the G-SCAAT.

[0042] Option 18. The method according to Option 17, wherein the method further comprises: Associate a background counter with the G-SCAAT, the background counter being configured to monotonically increase a counter value set for the G-SCAAT according to a predetermined schedule; After the G-SCAAT is installed on the ECU, an authentication process is performed, the authentication process including: depending on whether the background counter matches an expiration counter included as part of the safety value, the ECU generates one of a pass / fail determination for the authenticity of the G-SCAAT; and The log message indicating the pass or fail determination is transmitted from the ECU to the background.

[0043] Option 19. The method according to Option 17, the method further comprising: defining each of the plurality of available profiles as including at least one security value that is different from the security values ​​of other roles; and determining the security parameters to include a plurality of role-based parameters and a plurality of non-role-based parameters, the role-based parameters having corresponding security values ​​set according to the roles of the user associated with the selected profile, and the non-role-based parameters having corresponding security values ​​set independently of the selected roles.

[0044] Option 20. A method for ensuring the safety of an electronic control unit (ECU), the method comprising: Generate a Granular Safety Control Adjustment Authorization Ticket (G-SCAAT) for installation on the ECU, wherein the G-SCAAT specifies one or more safety values ​​for each of a plurality of safety parameters; The G-SCAAT is transmitted from the background to the ECU as part of the installation process, and the ECU is configured to ensure ECU safety according to the safety value specified in the G-SCAAT; and In response to the ECU performing an authentication process for verifying the safety value after the G-SCAAT is installed, a log message is transmitted from the ECU to the background, the log message identifying one of a pass / fail judgment for the authentication process.

[0045] When understood in conjunction with the accompanying drawings, the above features and advantages of this teaching, together with other features and advantages, will readily become apparent from the following detailed description of the modes of implementation of this teaching. It should be understood that even though the following drawings and embodiments may be described separately, their individual features may be combined into additional embodiments. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0047] Figure 1 This is a diagram of a system configured to provide safety control for an electronic control unit (ECU) according to a non-limiting aspect of this disclosure.

[0048] Figure 2 A diagram of an ECU according to a non-limiting aspect of this disclosure is shown.

[0049] Figure 3 A diagram of G-SCAAT according to a non-limiting aspect of this disclosure is illustrated.

[0050] Figure 4 The illustration shows a flowchart of a method for ensuring ECU safety according to a non-limiting aspect of this disclosure. Detailed Implementation

[0051] Specific embodiments of this disclosure are disclosed herein as needed; however, it will be understood that the disclosed embodiments are merely exemplary embodiments of this disclosure and may be implemented in various and alternative forms. The drawings are not necessarily drawn to scale; some features may be exaggerated or minimized to show detail of particular components. Therefore, the specific structural and functional details disclosed herein should not be construed as limiting, but merely as a representative basis for teaching those skilled in the art to employ this disclosure in various ways.

[0052] Figure 1 This is a diagram of a system 10 configured to provide safety control for an electronic control unit (ECU) or other programmable device 12, according to a non-limiting aspect of this disclosure. For illustrative purposes, system 10 is primarily described with respect to ensuring the safety of the ECU 12 when it is included in a vehicle (host device), as this disclosure fully contemplates its use and application in ensuring the safety of devices other than the ECU 12 and ECU 12 included in a host device other than a vehicle. System 10 can operate via an interaction between programming tool 14, a background 16, and the ECU 12, whereby each cooperates to implement a method for controlling the diagnostic safety capabilities of the ECU 12 according to the methodology described herein. Each may include a processor configured to execute non-transitory instructions stored in included memory to implement the various operations, functions, and activities described herein, and similarly, each may include suitable interfaces, connections, communication capabilities, etc., required to implement the processes and operations contemplated herein.

[0053] The back-end 16 can be considered a trusted entity, such as one under the control or guidance of the original equipment manufacturer (OEM) of the main unit or another entity, whose task is to validate the soft part used for updates and / or generate granular safety control adjustment authorization tickets (G-SCAAT) 20 to facilitate safety controls. The back-end 16 may include a database 22 capable of storing G-SCAAT 20, soft parts, software installations, etc., and cross-referencing these with ECU identifiers (IDs), enabling the back-end 16 to effectively maintain the latest version of each G-SCAAT 20 authorized for each ECU 12. Each G-SCAAT 20 may include an ECU ID, module ID, part number, etc., or otherwise associated with these to coordinate its use with documents, datasets, or other content containing software, code, programming, etc. G-SCAAT 20 can be programmed into ECU 12, where corresponding files or structures can be transferred to ECU 12 and acted upon by ECU 12 to facilitate the safety controls envisioned herein. The backend 16 may include other interfaces of the portal 24 (e.g., a website) configured to receive request messages from purchasers or other individuals and, based on these (e.g., according to included credentials), select roles and / or other constraints to qualify G-SCAAT 20 and assign it to the user making the request.

[0054] Programming tool 14 can interact with backend 16 to enable secure control of ECU 12 according to the permissions, qualifications, and other constraints defined in the corresponding one of G-SCAAT 20. Programming tool 14 can correspond to a device capable of interacting with ECU 12. For example, programming tool 14 can correspond to a standalone tester capable of connecting to a network or directly to ECU 12; for example, in the case of a vehicle, the tester can connect to a vehicle network communicating with ECU 12, and / or the tester can be directly plugged into a socket or interface of ECU 12. Alternatively, instead of a standalone tester, programming tool 14 can be included within a module or another ECU; for example, one ECU can act as a programming tool for another ECU. Programming tool 14 can also be located remotely from the device containing ECU 12 to facilitate over-the-air (OTA) updates. Programming tool 14 may include a user interface or human-machine interface (HMI) to facilitate interaction with an administrator when needed to input information and commands related to user-dependent aspects of facilitating updates.

[0055] Programming tool 14 can be a general-purpose tool or non-ECU 12 or host device specific, as it may require loading information, files, and other data onto it. In addition to programming ECU 12, the programming tool may further support protocol capabilities to manipulate additional aspects of ECU memory and functionality. Backend 16 may, for example, provide programming tool 14 with utility files that reference G-SCAAT 20 and / or other information to be loaded or otherwise programmed onto ECU 12. Utility file 28 may reference copies of software, calibration tables, codes, etc., associated with the G-SCAAT 20 and / or other datasets to be provided to ECU 12 to facilitate the implementation of the safety controls envisioned herein. Utility file 28 may be stored on programming tool 14 or otherwise provided to the programming tool, such as from backend 16 via wired or wireless communication. One aspect of this disclosure envisions programming tool 14 used by a vehicle technician or owner when working on a host device. Of course, it may not be desirable to have a separate programming tool 14 or a pre-loaded programming tool 14 (especially with the increase in wireless communication range) so that some or all of the interactions described herein can occur directly between the background 16 and the ECU 12 via wired or wireless signaling.

[0056] Figure 2A diagram of an ECU 12 according to a non-limiting aspect of the present disclosure is illustrated. The ECU 12 may include an interface 40 configured to facilitate the exchange of signals, messages, etc., with a programming tool 14, a backend 16, and / or dependent systems. Interface 40 may include corresponding features configured to facilitate accompanying communications, including components sufficient to facilitate wired and / or wireless exchange. The ECU 12 may include a processor 42 configured to control the ECU 12 based on the execution of non-transitory instructions stored on the included computer-readable storage medium. For illustrative and non-limiting purposes, the storage medium is shown divided into a normal area 48 and a secure area 50. The normal area 48 may correspond to volatile and / or non-volatile memory configured to allow updating, erasing, or otherwise manipulating data stored thereon, optionally depending on whether the corresponding actor satisfies certain security protocols. Security zone 50 can run firmware and support data storage, which can be configured such that data stored thereon in volatile and / or non-volatile memory can be permanent and / or effectively cannot be directly changed from external functions or sources.

[0057] One non-limiting aspect of this disclosure envisions an ECU 12 including a bootloader, boot manager, bootloader, control program, or other construct 54 to facilitate loading the ECU 12 or otherwise preparing the ECU 12 for operation. The bootloader 54 may be configured to execute upon power-on or other initialization of the ECU 12 to instantiate application software stored in application memory 58. The application software may be configured to control the operation of the ECU 12. The bootloader 54 may include control software and / or other control logic configured to facilitate the instantiation of the application software, calibration software, and / or to perform other contemplated or required operations to achieve the safety controls described herein. Therefore, the bootloader 54 is presented in a non-limiting manner to represent the functional features of the ECU 12 configured to facilitate the operation envisioned herein. The bootloader 54 can be considered to operate separately from the application software in the sense that it can be used to facilitate the implementation of the safety control operations conceived herein and other operations required to guide the control of ECU 12 according to commands from the application software.

[0058] The application software can be configured to facilitate the implementation of control-dependent systems, the execution of calculations, or other processes assigned to the ECU 12. The ECU 12 can be configured to perform various controls (particularly when included in a vehicle), thereby facilitating the management of the ECU 12 by generating corresponding controls based on algorithms, programming, logic, etc., included in the application software. The application software can be stored in a series of memory partitions on normal memory, which can be individually identified by one or more module IDs configured to logically identify associated memory clusters. These module IDs (i.e., the portion of normal memory including the application software) can be used to represent the application memory portion 58 of the memory, or a portion of normal memory actively configured to facilitate the implementation of the application software. A non-limiting aspect of this disclosure envisions at least some ECU operations performed under the guidance of the application software being at least partially based on calibration data.

[0059] Calibration data can be stored as multiple values ​​in calibration memory 60, which are set for corresponding calibration parameters associated with various aspects of the application software (i.e., associated with values ​​used for different calculations, logic, control, etc., to be performed using ECU 12). One or more of the calibration parameters can be calibrable in the sense that the value used to define its effect can be adjusted from one value to another to induce an effect on the application software. The calibration data can accordingly be defined as multiple calibration parameters having one or more calibrable values. Calibration data (or more specifically, values ​​used to represent their effect) can take various forms and be provided according to various structures, such as in tabular, alphanumeric character, programming / language, etc.

[0060] One non-limiting aspect of this disclosure envisions enabling a purchaser, owner, or another entity (such as an OTA server in the background) to program the ECU 12 according to the security controls described herein. Such security controls (i.e., changing programmed data, values, etc., from one value to another) may require programming, encoding, or otherwise rewriting a portion of memory containing previously stored values. Programming can be facilitated using a bootloader 54 or control software associated with the bootloader 54. For illustrative purposes, the bootloader 54 may be configured to control the addition and removal of data from memory 44 according to a security protocol associated with the relevant memory and subsequently initialize the ECU 12 to take appropriate actions.

[0061] The bootloader 54 may require an authenticity check before allowing changes to data, calibrable values, etc., stored in memory 44. This authenticity check may correspond to a verification process, thereby requiring verification of the digital signatures of the data, software, etc., to be added / changed before they are allowed to be stored on ECU 12. The authenticity check may require the entire set of code, software, data, etc., to be digitally signed and verified before they are allowed to be stored on ECU 12. In the case of changes to application software and / or calibration data, the authenticity check may require digital signing of these changes, but the entire set of code that depends on them must also be digitally signed and verified, for example, by compiling after each change.

[0062] Repeated signing and verification of such ECU updates can be cumbersome and time-consuming, especially during the development, testing, or troubleshooting of updates intended for use with ECU 12. Authentication checks may require administrators to perform a laborious process of generating and then verifying digital signatures for each expected change, no matter how small. These processes are particularly burdensome when administrators may be required to repeatedly test different combinations of values ​​before reaching the appropriate combination. One non-limiting aspect of this disclosure envisions a bootloader 54 configured to perform bypass operations to circumvent authenticity checks in certain circumstances.

[0063] When implemented, bypass operation can correspond to the following: bootloader 54 allows selectable partitions or portions of the memory to be programmed, altered, adjusted, etc., without requiring digital signatures and / or verification of these changes, the memory, partitions, or corresponding software, files, etc. Bypass operation can instead be used to allow users to make changes to certain portions of memory 44 without requiring corresponding digital signatures of the affected software or code. This can be beneficial in allowing operators to perform trial and test processes, thereby incrementally changing and testing calibration parameters without the need for more cumbersome authenticity checks, while also avoiding the risks associated with signing software not intended for production use. Bypass operation allows bootloader 54 to interact with programming tool 14 to receive calibrable values ​​or otherwise adjust calibration data, and subsequently encode those values ​​into memory to trigger corresponding changes in the operation of application software. Bootloader 54 can be configured to compile or otherwise process calibration values ​​stored in calibration memory and subsequently instruct application software to begin processing.

[0064] The tunable implementation memory 72 may be separately identifiable from and include multiple calibration parameters, which are identical to the calibration parameters included in the calibration memory 60. Calibration data in each of the tunable implementation memory 72 and the calibration memory 60 can be initially programmed using the same factory calibration values. In this respect, the tunable implementation memory 72 may at least initially be considered a backup or copy of the calibration memory 60. The calibration memory 60 and the tunable implementation memory 72 may be constructed in this manner during the manufacture of the ECU 12. The calibration memory 60 and the tunable implementation memory 72 may thus be matched when the ECU 12 leaves the factory of the ECU OEM and / or the host device OEM. Safety controls may be implemented to change one or more corresponding adjustable values ​​in the tunable implementation memory 72 with the programming tool 14. Corresponding memory access may be limited to the module ID specified in G-SCAAT 20; that is, a partition of the tunable implementation memory 72 may be identified within G-SCAAT 20 for each permitted / eligible adjustable calibration module ID.

[0065] The bootloader 54 may be configured to facilitate an adjustable verification process for determining whether an adjustable value input to the adjustable implementation memory 72 is valid or invalid. If within the limits specified in the adjustable constraint memory 74, the adjustable value may be determined to be valid; otherwise, it may be determined to be invalid. The adjustable constraint memory 74 may be separately identifiable from the calibration memory 60 and the adjustable implementation memory 72. The adjustable constraint memory 74 may be configured during the manufacture of the ECU 12 such that the limits therein may be selected by the OEM of the main unit based on maximum values ​​or ranges deemed suitable for the operation of the ECU 12. These limits may deviate from the nominal or media calibration values ​​included in the calibration memory 60. Thus, these limits may be set based on the OEM's overall understanding of how much adjustment can be made appropriately while still taking into account the corresponding effects on the main unit and / or other dependent systems.

[0066] Figure 3A diagram of G-SCAAT 20 according to a non-limiting aspect of this disclosure is illustrated. G-SCAAT 20 can be loaded and installed on ECU 12, optionally after unlocking or other security measures. Once stored in secure memory, G-SCAAT 20 can cooperate with bootloader 54 to enable instantiation of ECU 12 and application software at startup and otherwise control of ECU 12 from power-on until the application software begins. G-SCAAT 20 can be a static file, such as a static file constructed from plain text and encrypted constructs, and bootloader 54 can be configured to automatically process the plain text and these encrypted constructs whenever ECU 12 is powered on. This can occur in response to the host device and / or ECU 12 transitioning from one state to another accordingly, for example, this may coincide with the ignition event of the vehicle. G-SCAAT 20 can be configured, at least in this way, to adjust the operation of bootloader 54 whenever G-SCAAT 20 is installed on ECU 12.

[0067] Optionally, bootloader 54 may check the signature of G-SCAAT 20 or perform another type of verification on G-SCAAT 20 before installing or otherwise acting on information stored therein. Optionally, bootloader 54 may also include logic or other measures to determine whether to launch the application software based on the influence of G-SCAAT 20 or whether G-SCAAT 20 should be ignored instead and executed without its influence, such as according to previously defined factory settings. Further security measures (such as requiring backend 16 to provide additional authentication data and / or using Message Authentication Code (MAC)) may also be utilized alone and / or in combination with seed-based request-response mechanisms to facilitate unlocking ECU 12 for installation of G-SCAAT 20.

[0068] One non-limiting aspect of this disclosure envisions G-SCAAT 20 being configured to have multiple security parameters, whereby the values ​​selected for some of these security parameters can be individually customized based on the role, profile, or other construct assigned to its intended user, entity, etc., for illustrative purposes; roles, profiles, or other constructs are collectively, but not limited to, referred to as roles. Optionally, security parameters can be distinguished as role-based parameters and non-role-based parameters. Role-based parameters may correspond to security values ​​selected based on the identity of the user or other entity associated with the selected role, and conversely, non-role-based parameters may correspond to security values ​​selected independently of identity; for example, non-role-based parameters may be selected based on an ECU, an encrypted construct generated from G-SCAAT, a counter, a non-user identifier, etc.

[0069] G-SCAAT 20 is shown to include a plurality of security parameters 78, which have an exemplary list of lengths (bytes) 79 for corresponding security values. The plurality of non-role-based parameters may include a module ID parameter 80, and an ECU name parameter 82, an ECU ID parameter 84, an ECU ID extension parameter 86, a G-SCAAT signature certificate parameter 88, a signature parameter 90, and / or a MAC parameter 92. The module ID parameter 80 may correspond to a value set to uniquely identify G-SCAAT 20 relative to other G-SCAAT 20s. The ECU name parameter 82 may correspond to a value set to uniquely identify the name of an ECU 12 to be used with G-SCAAT 20. The ECU ID parameter 84 may correspond to a value set to uniquely identify an ECU 12 relative to other ECU 12s; that is, the ECU name 82 may be common to multiple ECUs 12, while the ECU ID 84 may be unique. The ECU ID extension parameter 86 can be configured to ensure the uniqueness of an ECU identified as associated with a specific G-SCAAT 20. The G-SCAAT signature certificate parameter 88 can correspond to a microcertificate, which may optionally include padding bytes generated by encrypting the entire G-SCAAT 20. The signature parameter 90 can correspond to a digital signature generated to verify the authenticity of the G-SCAAT 20. The MAC parameter 92 can correspond to a hash or other variable generated for encrypting the identification of the G-SCAAT 20.

[0070] Role-based parameters can correspond to security parameters selected based on variables that depend on the role assigned to a specific user. G-SCAAT 20 is shown to include multiple such role-based parameters, which may include a creation count parameter 96, an expiration count 98, an application start date ID (NBID) parameter 100, a hardware security module (HSM) NBID parameter 102, a boot / software compatibility ID (BCID) parameter 104, a security control parameter 106, an unlock level parameter 108, a module ID parameter 110, an option parameter 112, and / or an erase ignition parameter 114. The application NBID parameter 100 may be a digital reference or counter stored on G-SCAAT 20 at generation time for comparison with the application NBID stored on ECU 12 and / or requested by ECU 12 from the background 16. This may help ensure that the application software on ECU 12 matches the application software intended to be manipulated using G-SCAAT 20. HSM parameter 102 can be a counter of a similar type and is used to ensure that the HSM on ECU 12 matches the HMS intended to be manipulated using G-SCAAT 20. BCID parameter 104 can also be a counter of a similar type and is used to ensure that the boot / software on ECU 12 matches the boot / software intended to be manipulated using G-SCAAT 20. Module ID parameter 110 can be used to identify programmable partitions or clusters within memory 44, i.e., to define the programmable portions of memory 44 within G-SCAAT 20. Option parameter 112 can be used to schedule the duration of use of G-SCAAT 20. Option parameter 112 can be set to: a first value, which limits G-SCAAT 20 to a single installation / use; a second value, which erases and disables G-SCAAT 20 when the Manufacturing Enable Counter (MEC) is equal to zero (vehicle manufacturing complete); and a third value, which disables G-SCAAT 20 when the MEC is greater than zero (vehicle manufacturing is true), where the MEC is a safety construct that additionally participates in post-vehicle manufacturing safety methods when irreversibly set to zero. Erase ignition parameter 114 can be used to erase G-SCAAT 20 after a specific number of ignition cycles have occurred.

[0071] Security control parameter 106, shown in the illustration (callout), includes a variety of additionally selectable role-based security parameters, having optional bit positions 118 for setting specific security controls. These security controls may include secure programming application software parameters 120, secure programming calibration software parameters 122, in-vehicle network message authentication parameters 124, secure boot parameters 126, host debugging parameters 128, and / or HSM / trust zone debugging parameters 130. Secure programming application software parameter 120 can be set to disable the bootloader 54, eliminating the need for secure programming signature checks on the signed application code 58 software component. Secure programming calibration software parameter 122 can be set to disable secure programming signature checks on the bootloader 54 for signed calibration software components (including calibration memory ID). In-vehicle network message authentication parameter 124 can be set to disable encrypted MAC (Message Authentication Code) checks for in-vehicle network communications. This MAC can be used to protect data in motion by using MAC tags attached to frames that are specified to require authenticity and integrity checks on data received by ECU 12. This can be done to mitigate security risks and generally facilitates development testing. Security boot parameter 126 can be set to disable security boot checks, which, unlike the security programming used to verify soft parts (e.g., calibration and application software) during programming, can be used to verify soft parts on each ECU 12 during power-up. Host debug parameter 128 can be set to enable the user to diagnostically query and manipulate normal memory and firmware to allow debug ports (e.g., Joint Test Action Group port (JTAG - IEEE Standard 1149.1-1990)) to be unlocked to establish an active debug session. HSM / Trust Zone debug parameter 130 can be set to enable the user to diagnostically query and manipulate secure zone 50 memory and firmware.

[0072] Unlock level parameter 108, shown in illustration number (callout), includes a variety of additionally selectable role-based security parameters that can be used to lock / unlock diagnostics and other controllable functions to generate roles for unlocking optional service identifiers (SIDs) within the Unified Diagnostic Services (UDS), such as the International Organization for Standardization's UDS standard entitled ISO 14229-1 Road vehicles - Unified diagnostic services (UDS), which is hereby incorporated herein by reference in its entirety. Unlock level parameter 108 may include, for example, service parameter 136, assembly plant parameter 138, OTA parameter 140, engineering parameter 142, remote diagnostic parameter 144, and / or supplier parameter 146. Service parameter 136 can be set to unlock diagnostic levels opened with SID 0x01 (request seed ECU programming) and SID 0x11 (request seed extended refresh). Assembly plant parameter 138 can be set to unlock diagnostic levels opened with SID 0x03 (request seed assembly plant programming) and 0x13 (request seed extended refresh factory programming). OTA parameter 140 can be set to unlock the diagnostic levels opened with SID 0x05 (Request Seed OTA Refresh) and 0x15 (Request Seed Extended Refresh OTA). While parameter 142 can be set to unlock the diagnostic level opened with SID 0x09 (Request Seed Project), remote diagnostic parameter 144 can be set to unlock the diagnostic level opened with SID 0x0B (Request Seed Remote Diagnostics). Vendor parameter 146 can be set to unlock the diagnostic level opened with SID 0x0D (Seed Vendor Secure Access).

[0073] The combination of values ​​included in G-SCAAT 20 can be selected based on the role assigned to a specific user. The user may be required to provide identification, trust credentials, authorization from a supervisor / OEM, or other information associated with generating an assessment of the use reasoning regarding the programmed ECU 12. This information can be parsed to identify the appropriate role among the available roles for the user. This process can be performed by a network administrator and / or automatically based on information provided electronically; for example, the user may provide trust credentials or other information to a website or portal associated with the backend 16, whereby the backend 16 can automatically process the corresponding information to select an appropriate role for the user and subsequently populate the system with values ​​associated with the selected role, such as setting values, flags, variables, etc., within G-SCAAT 20 to match the qualifications and permissions assigned to the corresponding role. Following this disclosure, at least in this manner, a granular approach is envisioned for specifically locking / unlocking other features available on the CU 12 or otherwise enabling secure control over said other features based on the values ​​of multiple security parameters set within G-SCAAT 20.

[0074] A role can correspond to an administrator role. An administrator role can be a highly trusted, sensitive, and restricted role, for which the ability to assign non-administrator roles to individual users exists. An administrator role can effectively designate an individual to act as a gatekeeper to allow user access to the backend16 to generate G-SCAAT20, enabling the administrator role to be used to approve user roles, where each user role is assigned a different time period, such as a one-time use or a duration of its role.

[0075] Another role can correspond to a role in an engineering software class, which can optionally be subdivided into definable classes or sub-roles, for example, classes 1 to n. Software roles can be helpful to a large number of developers across a wide range of ECU 12 types (PCM, ECM, TCM, CGM, TCU, EBCM, Amp, Radio, etc.) and ECU types, as they limit the number of individuals capable of generating G-SCAAT 20 for any given ECU 12, and then further limit the various security controls that each user is empowered to disable to support their roles in development, manufacturing, or service. For a given ECU type, there are bootloader developers, base software developers (software that extracts application code from processor hardware), application code developers, calibration engineers, diagnostic engineers, cybersecurity engineers, DREs (design release engineers with officially released production-ready ECU types), manufacturing engineers, hardware engineers, quality engineers, and service engineers. Thus, using the granular controls described herein, role-based security relationships can be finely managed and adjusted to provide minimal privileges to a given user.

[0076] Another role may correspond to the Agent User role, which can optionally be subdivided into qualifyable classes or sub-roles, such as classes 1 to n. The Agent User role can be used to enable regulation, such as for aftermarket regulation. This role will be empowered to support enterprise processes and access the necessary infrastructure to generate G-SCAATs for one or more ECU types, and will be able to use module ID parameter 110, creation counter parameter 96, and erase ignition cycle parameter 114 to support the generation of regulation demonstration G-SCAATs using IGN or creation counter timing mechanisms or time-independent fully paid G-SCAATs.

[0077] Another role may correspond to the warranty role, which can optionally be subdivided into definable classes or sub-roles, such as classes 1 to n. The warranty analysis role is used to provide a time component to the programming of ECU 12, such as the duration of G-SCAAT validity (IGN cycles, 1 time, creation count, MEC value, etc.) to allow ECU 12 to be reprogrammed for warranty purposes without the need for security tickets or other unlocking measures (which have potentially ambiguous durations or potentially provide unlocking capabilities greater than needed to resolve warranty issues). The warranty role can be used to generate a G-SCAAT 20 with a limited duration, optionally restricted to individual ECU 12, after which G-SCAAT 20 can be automatically invalidated. This ability to automatically invalidate and restrict use with a specific ECU 12 helps avoid the scrap costs historically incurred when ECU 12 had to be scrapped due to damage caused by security tickets or other unlocking measures during warranty repairs, as the scope of such events was limited to a specific duration and / or an identifiable number of ECUs 12.

[0078] Figure 4 A flowchart illustrating a method for ensuring the security of ECU 12 according to a non-limiting aspect of this disclosure is shown. Block 162 relates to a G-SCAAT generation process for generating G-SCAAT 20. This generation process may include a background process 16 receiving a request associated with a user who requests G-SCAAT 20 for purposes such as ensuring the security of ECU 12 or programming ECU 12. This request message may be received via portal 24 and / or via other communications, such as email, telephone, etc., from an authorized supervisor. Optionally, the request message may include trust credentials and / or other identifying information, such as the name and ID of the ECU 12 intended for use with the requested G-SCAAT 20. The generation process may include an allocation phase, whereby the background process 16 selects a role, profile, etc., for the user from a plurality of available roles, profiles, etc. The role may be based on predefined authorizations associated with the requester's identity, such as in a lookup table and / or algorithm. Optionally, the requesting entity may be required to provide a questionnaire or complete other information for processing, optionally according to a predefined calculation process, to identify one or more suitable roles.

[0079] Block 164 relates to the installation process associated with installing G-SCAAT 20 on ECU 12, such as utilizing a request-response process, for example, the request SID 0x27 and response SID 0x67 of the UDS protocol. The request-response process may include background 16 providing ECU 12 with a background counter for G-SCAAT 20. Optionally, the installation process may include transitioning G-SCAAT 20 from the normal zone 48 to the safe zone 50, which can be used to prevent alteration after installation.

[0080] Block 166 relates to performing a certification process after installing G-SCAAT 20. This certification process includes processing a background counter and the ECU generating either a pass / fail judgment for the authenticity of G-SCAAT 20, depending on whether the background counter matches a counter included as part of G-SCAAT 20. The background counter may be a monotonically increasing counter that has been stored in the background since the creation of G-SCAAT 20 and / or since the installation of G-SCAAT 20 on ECU 12. When ECU 12 is unlocked, an expiration count 98 within G-SCAAT 20 can be compared with the background counter provided to ECU 12. If the expiration count 98 fails to exceed the received / certified background counter, G-SCAAT 20 may be considered invalid. Bootloader 54 may rely on the creation count 96 included in G-SCAAT 20 to evaluate the validity of G-SCAAT 20. Creation count 96 can be used in this way to prevent G-SCAAT 20 from being reinstalled on ECU 12 from which it has previously been erased. Creation count 96 can be compared accordingly with a creation count stored in ECU 12, which can be a value set from the last valid G-SCAAT 20 installed. Thus, the value in G-SCAAT 20 may need to be greater than the value stored in ECU 12 for G-SCAAT 20 to be considered valid.

[0081] The authentication process (optionally a separate logging or tracking process) may occur after successful or unsuccessful authentication of the G-SCAAT 20. The logging process may include generating a log message indicating a pass or fail determination, and optionally storing the log message in the security zone 50 each time the G-SCAAT is authenticated and / or installed. The tracking process may include background 16 requesting or ECU 12 automatically transmitting the log message. The tracking process may include performing security incident and event monitoring to detect unauthorized activities, such as using the G-SCAAT 20 in situations different from those specified in the security parameters.

[0082] The terms “comprising,” “including,” and “having” are inclusive and therefore specify the presence of the stated features, steps, operations, elements, or components, but do not exclude the presence or addition of one or more other features, steps, operations, elements, or components. The order of steps, processes, and operations may be changed where possible, and additional or alternative steps may be employed. As used herein, the term “or” includes any and all combinations of the associated listed items. The term “any one of” is understood to include any possible combination of the referenced items, including “any one” of the referenced items. “A,” “an,” “the,” “at least one,” and “one or more” are used interchangeably to indicate the presence of at least one item. Multiple such items may be present unless the context explicitly indicates otherwise. Unless otherwise expressly or clearly indicated by the context (including the appended claims), all numerical values ​​of parameters (e.g., quantities or conditions) will be understood to be modified in all cases by the term “about,” regardless of whether “about” actually precedes the numerical value. A component “constructed” to perform a specified function is capable of performing that specified function without modification, rather than merely having the potential to perform that specified function after further modification. In other words, when explicitly constructed to perform a specified function, the described hardware is specifically selected, created, implemented, utilized, programmed, and / or designed for the purpose of performing that specified function.

[0083] While various embodiments have been described, the description is intended to be exemplary and not restrictive, and it will be apparent to those skilled in the art that many other embodiments and implementations are possible within the scope of these embodiments. Unless specifically limited, any feature of any embodiment may be used in combination with or in place of any other feature or element in any other embodiment. Therefore, these embodiments are not limited except as limited by the appended claims and their equivalents. Moreover, various modifications and variations are possible within the scope of the appended claims. Although several modes for implementing many aspects of this teaching have been described in detail, those skilled in the art to which this teaching relates will recognize various alternative aspects for practicing this teaching within the scope of the appended claims. It is intended that all matters included in the above description or illustrated in the drawings should be construed as illustrating and demonstrating the full range of alternative embodiments that will be apparent to those skilled in the art, which are implied by the inclusion, structurally and / or functionally equivalent to the inclusion, or otherwise based on the inclusion, and are not limited to the embodiments explicitly depicted and / or described.

Claims

1. A method for ensuring the safety of an electronic control unit (ECU), the method comprising: Receive a request associated with a user who requests to program the electronic control unit; Select a role for the user from among several available roles; as well as Generating a granular security control adjustment authorization ticket (G-SCAAT) to ensure the security of the electronic control unit (ECU) based on multiple security parameters includes specifying security values ​​within the granular security control adjustment authorization ticket to be used to control the ECU to operate according to the security parameters. The multiple security parameters are determined based on a role selected for the user. The granular security control adjustment authorization ticket is configured to adjust the security control of the ECU according to multiple selectable roles, each of which may differ in programming permissions, capabilities, constraints, requirements, and / or prerequisites for adjusting the security control.

2. The method according to claim 1, further comprising: A background counter is associated with the granularity security control adjustment authorization ticket, the background counter being configured to monotonically increase according to a predefined schedule by a counter value set for the granularity security control adjustment authorization ticket.

3. The method according to claim 2, wherein the method further comprises: An authentication process is performed at the electronic control unit at least in part based on the receipt of the background counter. The authentication process is configured to generate one of a pass / fail determination and a fail / unfail determination for the authenticity of the authorization ticket adjusted for the granular security control.

4. The method according to claim 3, wherein the method further comprises: If the background counter matches an expiration counter that is included as part of the security value, the qualification determination is generated; And if the background counter fails to match the expiration counter, the non-compliance determination is generated.

5. The method according to claim 4, further comprising: The qualification criteria are further limited to requiring that the Message Authentication Code (MAC) included as part of the granular security control adjustment authorization ticket matches the Electronic Control Unit Message Authentication Code generated at the Electronic Control Unit.

6. The method according to claim 3, wherein the method further comprises: The log message indicating the pass or fail determination is transmitted from the electronic control unit to the background, which is configured to generate the granular security control adjustment authorization ticket and associate the background counter with it.

7. The method according to claim 6, wherein the method further comprises: A request-response strategy is executed between the electronic control unit and the backend as at least part of an installation process configured to install the granular security control adjustment authorization ticket on the electronic control unit.

8. The method according to claim 1, wherein the method further comprises: Each of the plurality of available roles is defined as having at least one security value that differs from the security values ​​of the other roles.

9. The method according to claim 1, wherein the method further comprises: The security parameters are defined as including multiple role-based parameters and multiple non-role-based parameters. The role-based parameters have a corresponding security value set according to the selected role, and the non-role-based parameters have a corresponding security value set independently of the selected role.

10. The method according to claim 1, wherein the method further comprises: The security parameters are defined as one or more partitions within the memory of the electronic control unit that can be unlocked; And assign a module identifier (ID) to each partition as part of the security value.

11. The method according to claim 1, wherein the method further comprises: The safety parameters are defined to include one or more safety control parameters; And specify one of the security values ​​for each security control parameter.

12. The method according to claim 11, wherein the method further comprises: The safety control parameters are defined as including safety programming application software parameters, safety programming calibration software parameters, in-vehicle network message authentication parameters, safety boot parameters, host debugging parameters, and hardware security module (HSM) or trusted zone debugging parameters.

13. The method according to claim 1, wherein the method further comprises: The security parameters are defined to include one or more diagnostic unlocking level parameters; And specify one of the security values ​​for each unlock level parameter.

14. The method of claim 13, further comprising: The diagnostic unlock level parameters are defined as including service parameters, assembly plant parameters, over-the-air (OTA) download parameters, engineering parameters, remote diagnostic parameters, and / or supplier parameters.

15. The method according to claim 1, further comprising: The security parameters are defined as including creation count parameters, expiration count parameters, application start date identifier (NBID) parameters, hardware security module (HSM) start date identifier parameters, boot / software compatibility identifier (BCID) parameters, security control adjustment parameters, unlock level parameters, module identifier parameters, option parameters, and ignition count parameters.

16. The method of claim 15, further comprising: The security parameters are defined as including the electronic control unit name parameter, the electronic control unit identifier parameter, the granular security control adjustment authorization ticket signature certificate parameter, the signature parameter, and the message authentication code parameter.

17. A method for ensuring the safety of an electronic control unit, the method comprising: Select a configuration file from a plurality of available configuration files to ensure the security of the electronic control unit, each of the configuration files defining a plurality of security parameters for correspondingly ensuring the security of the electronic control unit; as well as Generate a granular security control adjustment authorization ticket for installation on the electronic control unit, including a specified security value within the granular security control adjustment authorization ticket for each of the security parameters defined for a selected configuration file, the electronic control unit being configured to ensure the security of the electronic control unit according to the security values ​​specified in the granular security control adjustment authorization ticket, wherein the granular security control adjustment authorization ticket is configured to adjust the security control of the electronic control unit according to a plurality of selectable roles, each of which may differ in programming permissions, capabilities, constraints, requirements and / or prerequisites for adjusting the security control.

18. The method of claim 17, further comprising: Associate a background counter with the granularity security control adjustment authorization ticket, the background counter being configured to monotonically increase the counter value set for the granularity security control adjustment authorization ticket according to a predefined schedule; After the granular security control adjustment authorization ticket is installed on the electronic control unit, an authentication process is performed, the authentication process including: depending on whether the background counter matches an expiration counter included as part of the security value, the electronic control unit generates one of a pass / fail judgment and a fail / unfail judgment for the authenticity of the granular security control adjustment authorization ticket; as well as The log message indicating the pass or fail determination is transmitted from the electronic control unit to the background.

19. The method of claim 17, further comprising: Each of the multiple available configuration files is limited to include at least one security value that is different from the security values ​​of other roles; The security parameters are defined as including multiple role-based parameters and multiple non-role-based parameters, wherein the role-based parameters have corresponding security values ​​set according to the roles of the users associated with the selected profile, and the non-role-based parameters have corresponding security values ​​set independently of the selected roles.

20. A method for ensuring the safety of an electronic control unit, the method comprising: Generate a granular security control adjustment authorization ticket for installation on the electronic control unit, the granular security control adjustment authorization ticket specifying one or more security values ​​for each of a plurality of security parameters, wherein the granular security control adjustment authorization ticket is configured to adjust the security control of the electronic control unit according to a plurality of selectable roles, each of which may differ in programming permissions, capabilities, constraints, requirements and / or prerequisites for adjusting the security control; The granular security control adjustment authorization ticket is transmitted from the background to the electronic control unit (ECU) as part of the installation process. The ECU is configured to ensure its security based on the security value specified in the granular security control adjustment authorization ticket. In response to the electronic control unit performing an authentication process for authenticating the security value after installing the granular security control adjustment authorization ticket, a log message is transmitted from the electronic control unit to the background, the log message identifying one of a pass / fail judgment for the authentication process.

Images