GB2559218A

GB2559218A - A modular safety software architecture for electrified-powertrain control systems

Info

Publication number: GB2559218A
Application number: GB1713458.6A
Authority: GB
Inventors: Potluri Chandrasekhar; Dolpp Alexander
Original assignee: Daimler AG
Current assignee: Mercedes Benz Group AG
Priority date: 2017-08-22
Filing date: 2017-08-22
Publication date: 2018-08-01
Also published as: GB201713458D0

Abstract

A modular software 400 includes an external communication layer 401 to perform external communication to and from a vehicle network, level 1 functions and hardware. An application layer 403 contains safety algorithms and software functions, where each function is assigned an Automotive Safety Integrity Level (ASIL) rating for level 2 and level 3 safety monitoring. An input/output (I/0) layer 402 provides an interface between a plurality of rings in the level 2/level 3 safety monitoring functions and the communication layer. The I/O layer encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications. The application layer also includes functional safety algorithm rings to monitor torque inaccuracies to prevent unintended acceleration or deceleration, high voltage battery monitoring, inverter temperature diagnostics and other hardware, sensor or software related diagnostics. Arbitration and error reporting layers are also provided.

Description

(54) Title of the Invention: A modular safety software architecture for electrified-powertrain control systems Abstract Title: A modular safety software architecture for electrified powertrain control systems (57) A modular software 400 includes an external communication layer 401 to perform external communication to and from a vehicle network, level 1 functions and hardware. An application layer 403 contains safety algorithms and software functions, where each function is assigned an Automotive Safety Integrity Level (ASIL) rating for level 2 and level 3 safety monitoring. An input/output (I/O) layer 402 provides an interface between a plurality of rings in the level 2/level 3 safety monitoring functions and the communication layer. The I/O layer encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications. The application layer also includes functional safety algorithm rings to monitor torque inaccuracies to prevent unintended acceleration or deceleration, high voltage battery monitoring, inverter temperature diagnostics and other hardware, sensor or software related diagnostics. Arbitration and error reporting layers are also provided.

ASILA/B

ASSL C/D

External Communiction Layer (401)

tcan tx; LwpiaH	TTTTTTTTTT” {CIO get; ' ¢401 bV	7777777777' ' L1 RX ; ' (401c) ;	7777777777 ; li tx ; ' ¢401 d) ;	7777T77777· ;cio set; < (,401 e) '	n-rrrrrrrrrrrrr\ OS Scheduled (401ft.	7777777777; ;can rx; 0(401,9)/
I/O Layer (402)

;:ξ::πξξ:

Fault Entry (40b) FQFR (405a)

At least one drawing originally filed was informal and the print reproduced here is taken from a later filed formal copy.

06 18

(Prior Art)

06 18

Funktionai Savety (F) (301) ASIL (A/8/C/D) (302) Description (303) Ring (3304)

ASILA/B mams

ASIL C/D

06 18

External Communiction Layer (401)

;can Tx; ( (401a) ( t / ; / / / / t > i /\	77VT777777; ;cio GEt ' (401b) ; zzy/z/zz///	πτπττττττ, ( L1 RX , '' (401c) ( //>/////#//	rrrrrrrrrrr,	πΤΤΤΤΎΤΤΤΤ, ;cio set; t (401 e) . / n i / / u i / /	OS Scheduler : (401n ; ΖΖ/ΖΛΖ/Ζ/Ζ'Ζ/ΖΖΖ	JCAN RX/ (/WPA?)//
; L1 TX > (401d)	7

oc on oo 90c on «90 900 001 <x	900 aai oo 900 aai oo no aoc	00 00 001 00 100 30( 001100 101	„ „ „ „	ao	αοοοοχχοαιοοοοοαιοο	9OC aoi oo 9OC aoc oo oc aoc oo oc aoc	aooaaacaaoaxxaaioax

I/O Layer (402)

; Arbitration Layer (404) _s

Fault Entry (405)

FGFR (405a)

18

06 18

Fig.6f

A Modular Safety Software Architecture for ElectrifiedPowertrain Control Systems [0001] PREAMBLE TO THE DESCRIPTION:

[0002] The following specification particularly describes the invention and the manner in which it is to be performed:

[0003] Technical field of the invention [0004] The present invention relates to modular safety software architecture for electrified-powertrain control systems.

[0005] Background of the invention [0006] Conventional safety architecture for electrified-powertrain control systems has different automotive safety integrity levels (ASIL’s) as per ISO26262. Therefore, creating modular and portable safety architecture for different electrified-powertrain configurations poses several challenges because of different ASIL levels, hardware-software coupling and hardware dependencies. In general, the safety monitoring architecture of the powertrain control system (as shown in FIG 1) comprises three levels of monitoring. The level one controller function (101) is configured to receive input signals (102) from multiple sensors and actuators to execute control functions for the electrified powertrain system. Here, the controller function (101) upon receiving the input signals is configured to monitor all the open-loop and closed-loop control functions of the electric motor, diagnostic functions for sensors, actuators and the vehicles On-Board Diagnostic (OBD) system. The level two monitoring function analyses defective sequences identified in the first level of monitoring and triggers a failure specific recovery mode for the identified defective sequence after a de-bounce time. The level three monitoring function comprises a software/hardware monitoring function of the microcontroller in a monitoring module independent from the main microcontroller and software monitoring of the monitor module by the main microcontroller. Both components are connected via a duplex (both ways) question/answer monitoring communication protocol.

[0007] Further, the most important functional elements of any electrifiedpowertrain control systems include torque security, high voltage safety, thermal safety, and provide technical counter measures for hazards that are caused by electric motor output torque, high voltage and high temperature.

[0008] The functional safety architecture (200) of the existing electrifiedpowertrain control system (as shown in FIG 2) comprises a controller area network receive signals (CAN RX) (201) function, controller area network transmit signals (CAN TX) (203), Level 1 Transmit signals (TX) (205), Level 1 Receive Signals (RX) (202), and Basic Software functions to perform external communications to and from the level 2 and level 3 monitoring functions. Here level 1 transmit signals (LI TX) (205) and level 1 receive signals (LI RX) (202) functions are used to perform a two way data transfer between the level 1 monitoring functions, level 2 monitoring functions and level 3 monitoring functions. Further, the complex input/output (CIO) function provides data transfer between the level 2, level 3 monitoring functions and hardware/software input/output present in the powertrain control system.

[0009] The functional safety architecture (200) as disclosed in FIG 2 comprises a data transfer ring (DATR) (207) that acts as an interface ring between the level 1 control functions and level 2 control functions. The functional safety system further comprises a torque security input ring (TSIR) (208) function that handles the Level 1 (LI) function inputs that were placed in shared RAM, and saves them to Level 2 (L2) function RAM. The safety architecture (200) also comprises a torque security monitoring ring (TSMR) (209) function to analyze defective sequences identified in the first level of monitoring, and a torque security torque ring (TSTR) (211) application module performs calculations yielding several torque values and then compares the various torques obtained from the Level 1 torque command control functions. Further, a torque security arbitration ring (TSAR) (213) application module arbitrates the reaction to error status. Similarly, a torque security CAN ring (TSKR) (215) performs CAN message packaging for safety related CAN signals.

[0010] The functional safety system further comprises a high voltage safety ring (HVSR) (210) function to provide safety logic for the high voltage (HV) battery protection and a thermal safety ring to perform inverter temperature diagnostics.

[0011] However, the existing functional safety architecture does not have standardized interfaces between hardware, software and between the modules/rings, which makes it labor intensive and time consuming for being ported to different electrified powertrain configurations. Further, a single function/ring present in the existing architecture has multiple ratings as a TSIR (208) function has ASIL ratings A/B and C/D. The software functions are not well encapsulated and have functional dependencies on other modules i.e. most of the modules have control and signal flow dependencies from other rings, hardware and external communication resulting in significant development and testing, time and cost, because the software modules have to be implemented and tested again and again for different electrified powertrain configurations. Also, due to the hardwaresoftware coupling, it takes a significant amount of development and testing effort to modify or add any safety features for the next generation safety software within the same electrified-powertrain configuration.

[0012] For instance, the WIPO patent document WO2012163656A1 (referred herein as ‘656) discloses security architecture, a battery and a motor vehicle having a corresponding battery which allows combining battery packs of a lower security integrity level into a battery system having a higher security integrity level. The security architecture as disclosed in ‘656 allows switching between an AS1L-B mode, ASIL-C mode or ASIL-D mode in a battery system having at least two different battery modules.

[0013] Hence, there exists a need to provide modular and portable software architecture for electrified-powertrain control systems so as to detect any random software and hardware failures in the electrified powertrain systems.

[0014] Summary of the invention [0015] The present invention overcomes the drawbacks of the prior art by providing a modular and portable software architecture for electrified-powertrain control systems. For this purpose, the modular software architecture comprises an external communication layer to perform external communication to and from a vehicle network, level 1 functions and hardware, an application layer comprising safety algorithms and functions for level 2 and level 3 safety monitoring and an input/output (I/O) layer that acts as an interface between the plurality of rings present in the level 2/level 3 safety monitoring functions and the external communication layer.

[0016] In accordance to one embodiment of the present invention, the modular software architecture also comprises an arbitration layer to arbitrate the reaction to an error status identified by the level 2 and level 3 safety functions and a fault entry layer to perform error entry and reporting for all level 2 and Level 3 safety monitoring functions.

[0017] Thus, the I/O layer of the present invention encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications. The modules in the safety architecture of the present invention has self-contained software component, often interchangeable, with well-defined standard interfaces and minimal dependencies with other modules so as to support different electrified powertrain configurations.

[0018] Brief description of the drawings:

[0019] The foregoing and other features of embodiments will become more apparent from the following detailed description of embodiments when read in conjunction with the accompanying drawings. In the drawings, like reference numerals refer to like elements.

[0020] FIG 1 illustrates a safety monitoring architecture of a conventional powertrain control system.

[0021] FIG 2 illustrates functional safety architecture of the existing powertrain control system, in accordance to one or more embodiment of the invention.

[0022] FIG 3 illustrates the naming convention of the modular safety architecture in accordance to one or more embodiment of the present invention.

[0023] FIG 4 illustrates modular safety architecture for an electrified-powertrain control system, in accordance to one or more embodiment of the present invention.

[0024] FIG 5 illustrates the process for configuring the modular software safety architecture for different electrified-powertrain configurations.

[0025] FIG 6a, FIG 6b, FIG 6c, FIG 6d, FIG 6e and FIG 6f illustrates the features of the modular safety architecture for electrified-powertrain control systems.

[0026] Detailed description of the invention:

[0027] Reference will now be made in detail to the description of the present subject matter, one or more examples of which are shown in figures. Each example is provided to explain the subject matter and not a limitation. Various changes and modifications obvious to one skilled in the art to which the invention pertains are deemed to be within the spirit, scope and contemplation of the invention.

[0028] While the present invention has been described with respect to certain embodiments, it will be apparent to those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.

[0029] The objective of the present invention is to make the software safety architecture portable and re-usable for different electrified-powertrain configurations while maintaining ASIL modularity. FIG 3 illustrates the naming convention of the modular safety architecture in accordance to one or more embodiments of the present invention. In accordance to an embodiment of the present invention, the plurality of software modules/rings/functions present in the level 2 and level 3 monitoring functions have a four-letter name. Here, the first letter of the ring represents the functionality of the ring (301), the second letter of the ring refers to the ASIL rating (302) of the ring followed by the ring description (303), and the last letter refers to the software module as the ring (304). For instance, the ring functionality may include the F - Function; Q - QM, N - Network, H Hardware, P - Process, A - Algorithm, V - high-Voltage, O - Over-heating, D Diagnostics, S - Sensor and E - Error-monitoring.

[0030] The present invention relates to modular software architecture for electrified-powertrain control system. The modular safety architecture of the present invention mainly comprises an application layer that contains safety algorithms and functions for level 2 and level 3 safety monitoring. It also comprises an input/output (EO) layer that acts as an interface between plurality of rings present in the level 2/level 3 safety monitoring functions and an external communication layer to perform external communication to and from a vehicle network, level 1 functions and hardware. Here, the EO layer encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications.

[0031] FIG 4 illustrates modular safety architecture for the electrified-powertrain control systems, in accordance to one or more embodiment of the present invention. The modular safety architecture (400) of the present invention comprises an external communication layer (401) to perform external communication to and from the vehicle network, level 1 functions and the hardware. For this purpose, the external communication layer (401) comprises controller area network receive signals (CAN RX) (401g) function, controller area network transmits signals (CAN TX) (401a), Level 1 Transmit signals (LI TX) (401d) and Level 1 Receive Signals (LI RX) (401c) to perform external communication to and from the vehicle network and level 1 functions. The external communication layer (401) also comprises complex input/output (CIO) GET function (401b), complex input/output (CIO) SET function (401e) to perform external communication to and from hardware/software input/output present in to the modular safety architecture of the powertrain control system. The external communication layer (401) also has an operating system (OS) scheduler (401f) to perform safety function calls from the operating system.

[0032] The modular safety architecture (400) also comprises an input/output (EO) layer (402) that acts as an interface between level 2/level 3 functions and the external communication layer (401). Thus, the I/O layer (402) encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications. Further, the EO layer (402) contains algorithms for monitoring and validating, data update rates and signal integrity for all Level 2 and Level 3 monitoring functions.

[0033] For this purpose, the input/output (EO) layer (402) comprises a functional safety functional ring (FSFR) to internally handle the software function calls so that the functional safety functional ring (FSFR) serves as a one point of contact with the external OS scheduler. The EO layer (402) uses a functional safety functional ring (FSFR) to perform bi-directional data transfer interface for level 1 communications between LI RX (401c)/Ll TX (401d). Here, the LI RX and TX signals which are used by ASIL-C modules or rings are grouped and processed in FCQR (402g), whereas LI RX and TX signals which are used by ASIL-B modules is in FBQR (402f).

[0034] The functional safety network ring (FXNR) handles CAN RX and CAN TX communication between the Level 2, Level 3 monitoring function and the vehicle communication network. Here, CAN RX & TX signals which are used by ASIL-C modules or rings are grouped and processed in FCNR (402c), whereas CAN RX and TX signals used by ASIL-A modules is in FANR (402b).

[0035] The functional safety hardware ring (FXHR) facilitates bi-directional data transfer between level 2, level 3 monitoring functions and hardware/software interface components. Here all CIO GET signals which are used by ASIC-modules are grouped and processed in FCHR ring (402e), whereas CIO SET signals that is sent to the hardware with ASIL-B rating is in FBHR (402d).

[0036] The functional safety process ring (FXPR) has algorithms for identifying latent faults in the hardware and also contains Level 2 and Level 3 program flow check algorithms for handling the hardware monitoring module question/answer process. The FSPR further comprises FDPR (402h) with latent fault identification algorithms to identify latent fault in the hardware and FBPR (402a) with program flow check algorithm for handling the hardware monitoring module question/answer process.

[0037] The modular safety architecture (400) further comprises an application layer (403) where the actual level 2 and level 3 monitoring happens. For this purpose, the application layer (403) comprises safety algorithms and functions for level 2 and level 3 monitoring. The modular safety architecture (400) comprises a functional safety algorithm ring (FXAR) for torque path monitoring. For this purpose, the FXAR ring contains algorithms to make independent calculations based on the input from the hardware to detect any torque inaccuracies, thereby preventing unintended acceleration or deceleration scenarios. The functions inside this ring calculate the torque output, based on the magnetic flux and DC power from the battery (primary and redundant torque calculation) along with the recuperation torque with the intent to detect Level 1 (torque controller function) torque inaccuracies. The algorithms implemented in the FXAR ring not only achieve functional safety of the vehicle but also have the capability to turn-off Level 1 comfort features (like anti-jerk) in case of torque inaccuracies.

[0038] The FXAR ring further comprises FCAR (403b) to calculate the achieved, primary and redundant torque values and an FBAR (403a) ring comprises torque calculation algorithms for performing torque calculations. Here all the signals from FCHR (402e), FCNR (402c), and FCQR (402g) which are required for calculating the achieved, primary and redundant torque values are in FCAR (403b) whereas signals from FBHR, FBNR and FBQR are used for torque calculation algorithms in FBAR (403a).

[0039] The application layer (403) comprises a functional safety high voltage ring (FXVR) to handle specific high voltage redundancy check algorithms to ensure that the voltage from the high voltage battery is within the normal operation range to command torque. The FXVR ring further comprises an FCVR (403d) ring to calculate the primary and redundant high voltage values and an FBVR (403c) ring comprises a high voltage battery algorithm. Here, all the signals from FCHR (402e), FCNR (402c), and FCQR (402g) which are required for calculating and comparing the primary and redundant high voltage values are handled by FCVR (403d) whereas signals from FBHR (402d), FBNR and FBQR (402f) are handled by FBVR (403c).

[0040] The application layer (403) comprises functional safety over a heating ring FXOR for inverter temperature diagnostics. The FXOR ring further comprises an FCOR ring to calculate redundant temperature comparisons and an FBOR ring used to run an inverter temperature algorithm.

[0041] The application layer (403) comprises a functional safety diagnostic ring (FXDR) to handle specific diagnostic functions which are independent of the hardware. For this purpose, the FXDR comprises an FCDR (403g) ring to receive signals from FCVR (403d), FCOR, FCAR (403b), FCNR (402c), and FCQR (402g) to perform diagnostic functions and an FBDR (403f) ring to receive signals from FBVR (403c), FBOR, FBAR (403a), FBNR, and FBQR (402f) so as to perform diagnostic functions independent of the hardware.

[0042] The application layer (403) further comprises a functional safety sensor ring FXSR to handle specific hardware/sensor related diagnostic algorithms. The functional safety sensor ring FXSR further comprises an FCSR (403i) ring to receive signals from FCHR (402e), FCNR (402c), and FCQR (402g) for performing sensor related diagnostic functions. The FXSR also comprises an FBSR (403h) ring to receive signals from FBHR (402d), FBNR and FBQR (402f) for performing sensor related diagnostic functions.

[0043] The modular safety architecture (400) also comprises an arbitration layer (404) wherein the arbitration layer (404) further comprises a plurality of rings to arbitrate the reaction to an Error Status. The rings in this layer have functionalities of monitoring Level 2 error statuses, activation of the error reaction monitor, monitoring of power stages and determining Level 2 error reactions.

[0044] The arbitration layer (404) further comprises a functional safety error monitoring ring LXER ring to handle specific error reaction monitoring and commands to the power hardware. The LXER module further comprises an LCER ring (404b) to receive signals from LCAR (403b), LCDR (403g), LCSR (403i) and hardware signals received by LCHR (402e) to arbitrate the reaction to an Error Status. The FXER module also comprises an FBER ring (404a) to receive signals from FBHR (402d), FBAR (403a), FBSR (403h) and FBDR (403f) to arbitrate the reaction to an Error Status.

[0045] The modular safety architecture (400) also comprises a fault entry layer (405) to perform error entry and reporting for all level 2 and Level 3 monitoring functions. For this purpose, the fault entry layer (405) comprises a functional safety fault ring (FQFR) (405a) to perform error entry and reporting for all the level 2 and level 3 monitoring functions present in the application layer (403). Thus, the function falls under quality management and it is represented by ‘Q’ in the ring name FQFR (405a).

[0046] In accordance to one or more embodiment of the present invention, in order to prevent data loss the data write operation into the memory location by the software functions is allowed only if the memory location is assigned to the functions that have the AS IL rating similar or above that of the software function performing a Data Write. For instance, an ASIL-C function may write into any of the memory locations allocated to AS IL - C, B, and A functions and may not perform a Data Write into the memory location assigned for ASIL-D.

[0047] FIG 5 illustrates the process for configuring the modular software safety architecture for different electrified-powertrain configurations. At step 501, a Hazard and Risk Assessment (HARA) for each individual powertrain configuration and then the ASIL rating for individual safety functions is determined. Based on the determined ASIL ratings pertaining to the specific electrified powertrain configuration, software modules are selected. Based on the chosen modules or rings the I/O layer for external communication along with the function call scheduler (FDFR) is configured for that specific configuration at step 502 and 503. Further, the architecture’s FO layer provides bi-directional communication, the internal flow dependencies may also result in FO configuration changes based on the signals that need to be received and sent to and from the vehicle networks, Level 1 functions and the hardware, therefore the interlayer signal flow dependencies is analyzed at step 504 and the FO layer for internal communication interfaces is configured at step 505. Finally, the scheduler ring (FDFR) is configured based on the OS scheduler functions at step 506 and the ASIL rating of the powertrain configuration.

[0048] The modular safety architecture (400) comprises an input/output (FO) layer (402) that acts as an interface between the level 2/level 3 functions and the external communication layer (401). The FO layer (402) encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications. Further, the modular safety architecture (400) of the present invention comprises functions/modules/rings partitioned in a manner taking into account the logical grouping of safety functions, while maintaining the safety monitoring hierarchy within the controller. Thus, the modules in the safety architecture (400) of the present invention have self-contained software components, often interchangeable, with well-defined standard interfaces and minimal dependencies with other modules so as to support different electrifiedpowertrain configurations as illustrated in FIG 6a. One module can evolve over time and modules can be replaced without impacting the other modules, which features the modular safety software architecture’s plug-in capabilities as shown in FIG 6b and FIG 6c.

[0049] FIG 6b shows the substitutability of the architecture where a software component or ring (FBQR) (402f) is being replaced by another ring with a higher ASIF rating i.e. FDQR. Here, FBQR (402f) ring which groups and process FI RX and TX signals used by automotive safety integrity level (ASIF-B) modules is replaced by FDQR ring so as to group and process FI RX and TX signals used by ASIF-D modules.

[0050] FIG 6c shows the extensibility of the architecture where a functional safety process ring (FXPR) is being added for feature addition or update.

[0051] Multiple modules can be assembled into different products to support various electrified powertrain configurations as shown in FIG 6d, FIG 6e and FIG 6f. Here, FIG 6e, FIG 6f shows the extensibility of the architecture were multiple modules such as functional safety algorithm ring (FXAR), functional safety diagnostic ring (FXDR) and functional safety sensor ring (FXSR) are added to various electrified powertrain configurations.

[0052] Thus, software modules or rings only have to be implemented and tested once throughout the development cycle for multiple generations, thereby significantly reducing the development and testing time, cost and effort. The I/O layer (402) of the modular safety architecture (400) has signal dependencies because of the interface to external communication, which makes the configuration changes to be handled locally without impacting the rings in the other layers. Also, the signals and diagnostics pertaining to the hardware/sensors are handled separately in the rings FXHR and FXSR. Therefore, any changes to the sensor hardware will be contained within those respective rings without having an impact on other software modules. The modular safety architecture can be integrated into any hardware configuration as a software library. Therefore, it provides one supplier for safety software and better control of safety software and core control functions.

[0053] Thus, the modules in the safety architecture (400) of the present invention has self-contained software component with minimal dependencies with other modules so as to support different electrified powertrain configurations. Further, one module can evolve over time and modules can be replaced without impacting the other modules. Also, multiple modules can be assembled to support different electrified powertrain configurations and only have to be implemented and tested once, throughout the product development cycle for multiple generations, thereby saving product development cost, time and effort. Therefore, the present SAFE Powertrain features IS026262 safety software portability, modularity and reusability for different electrified powertrain configurations.

[0054] While the present invention has been described with respect to certain embodiments, it will be apparent to those skilled in the art that various changes and modification may be made without departing from the scope of the invention as defined in the following claims.

[0055] Claims:

Claims

We claim:

1. A modular software architecture (400) for a powertrain control system 5 comprising:

a) an external communication layer (401) to perform external communication to and from a vehicle network, level 1 functions and hardware;

b) an input/output (I/O) layer (402) that acts as an interface between

10 plurality of rings present in the level 2/level 3 safety monitoring functions and the external communication layer (401);

c) an application layer (403) comprising safety algorithms and functions for level 2 and level 3 safety monitoring, wherein the application layer (403) further comprises:

15 - a functional safety algorithm ring (FXAR) for torque path monitoring, wherein the FXAR ring contains algorithms to make independent calculations based on the input from the hardware to detect any torque inaccuracies, thereby preventing unintended acceleration or deceleration scenarios;

20 - a functional safety high voltage ring (FXVR) to handle specific high voltage redundancy check algorithms to ensure that the voltage from the high voltage battery is within the normal operation range to command torque;

- a functional safety over (heating) ring (FXOR) for inverter

25 temperature diagnostics;

- a functional safety diagnostic ring (FXDR) to handle specific diagnostic function which is independent of the hardware;

- a functional safety sensor ring (FXSR) to handle specific hardware/sensor related diagnostic algorithms;

d) an arbitration layer (404) to arbitrate the reaction to an Error Status, wherein the arbitration layer (404) identified by the level 2 and level 3 safety functions; and

e) a fault entry layer (405) to perform error entry and reporting for all level 2 and Level 3 safety monitoring functions.

2. The modular software architecture (400) as claimed in claim 1, wherein the EO layer (402) encapsulates the modules present in the level 2 and level 3 functions to be independent from the external communications.

3. The modular software architecture (400) as claimed in claim 1, wherein the external communication layer (401) comprises:

- controller area network receives signals (CAN RX) (401g) function, controller area network transmits signals (CAN TX) (401a), Level 1 Transmit signals (LI TX) (401d) and Level 1 Receive Signals (LI RX) (401e) to perform external communication to and from the vehicle network and level 1 functions; and

- complex input/output (CIO) GET function (401b), complex input/output (CIO) SET function (401e) to perform external communication to and from hardware/software input/output interfaces.

4. The modular software architecture (400) as claimed in claim 1, wherein the LO layer (402) further comprises:

a) a functional safety functional ring (FSFR) to internally handle the software function calls so that the functional safety functional ring (FSFR) serves as a one point of contact with the external OS scheduler, wherein the FSFR ring further comprises:

- a FCQR (402g) ring to group and process LI RX and TX signals which are used by ASIL-C modules and a FBQR (402f) ring to group and process LI RX and TX signals used by automotive safety integrity level (ASIL-B) modules;

b) a functional safety network ring (FXNR) to handle CAN RX and CAN TX communication between the Level 2, Level 3 monitoring function and the vehicle communication network, wherein the FXNR ring further comprises:

- a FCNR (402c) ring to group and process CAN RX & TX signals which are used by ASIL-C modules or rings; and

- a FANR (402b) ring to group and process CAN RX and TX signals used by ASIL-A modules;

c) a functional safety hardware ring (FSHR) to facilitate bi-directional data transfer between level 2, level 3 monitoring functions and hardware/software interface components, wherein the FSHR ring further comprises:

- a FCHR ring (402e) to group and process CIO GET signals which are used by ASIC-modules; and

- FBHR (402d) to group and process hardware CIO SET signals that is sent to the hardware with ASIL-B rating;

d) a functional safety process ring (FXPR) to identify latent faults in the hardware and also contains Level 2 and Level 3 program flow check algorithms for handling the hardware monitoring module, wherein the FSPR further comprises:

- a FDPR (402h) ring with latent fault identification algorithms to identify latent fault in the hardware; and

- a FBPR (402a) ring with program flow check algorithm for handling the hardware monitoring module.

5. The modular software architecture (400) as claimed in claim 1, wherein the application layer (403) further comprises:

a) a functional safety algorithm ring (FXAR) that comprises algorithms to make independent calculations based on the input from the hardware to detect any torque inaccuracies, thereby preventing unintended acceleration or deceleration scenarios, wherein the FXAR ring further comprises:

- a FCAR (403b) ring to calculate the achieved, primary and redundant torque values, wherein the FCAR (403b) ring is configured to receive signals from the FCHR (402e), FCNR (402c), and FCQR (402g); and

- a FBAR (403a) ring uses torque calculation algorithms for torque calculation;

b) a functional safety high voltage ring (FXVR) to handle specific high voltage redundancy check algorithms to ensure that the voltage from the high voltage battery is within the normal operation range to command torque, wherein the FXVR ring further comprises:

a FCVR (403d) ring to calculate the primary and redundant high voltage values, wherein the FCVR (403d) ring receives signals from FCHR (402e), FCNR (402c), and FCQR (402g) for calculating and comparing the primary and redundant high voltage values; and a FB VR (403c) ring receives signals from FBHR (402d), FBNR and FBQR (402f) to calculate high voltage values;

c) a functional safety over (heating) ring (FXOR) for inverter temperature diagnostics, wherein the FXOR ring further comprises a FCOR ring to calculate redundant temperature comparisons and a FBOR ring to inverter temperature algorithm;

d) a functional safety diagnostic ring (FXDR) to handle specific diagnostic function which is independent of the hardware, wherein the FXDR ring further comprises:

- a FCDR (403g) ring to receive signals from FCVR (403d), FCOR, FCAR (403b), FCNR (402c), and FCQR (402g) to perform diagnostic functions; and

- a FBDR (403f) ring to receive signals from FBVR (403c), FBOR, FBAR (403a) and FBQR (402f) so as to perform diagnostic functions independent of the hardware; and

e) a functional safety sensor ring (FXSR) to handle specific hardware/sensor related diagnostic algorithms, wherein the FXSR also comprises:

- a FCSR (403i) ring to receive signals from FCHR (402e),

5 FCNR (402c), and FCQR (402g) for performing sensor related diagnostic functions; and

- a FBSR (403h) ring to receive signals from FBHR (402d), FBNR and FBQR (402f) for performing sensor related diagnostic functions.

Intellectual

Property

Office

Application No: GB1713458.6 Examiner: Mr Tony Walbeoff