CLIAMS:CLAIMS

1. A system for fault management in an electronic control unit (ECU) in an automotive environment, said system configured for:

integrating a Real Time Operating system 1 (RTOS 1) and a Real Time Operating system 2 (RTOS 2) to a fault thriving automotive display ECU system;
identifying occurrence of at least one fault associated with at least one process being handled by said RTOS 1 using a fault assistance module of said fault thriving automotive display ECU system;
identifying occurrence of at least one fault associated with at least one process being handled by said RTOS 2 using said fault assistance module;
performing a fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 1 using said fault assistance module;
performing a fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 2 using said fault assistance module; and
executing at least one of a plurality of functionalities associated with said RTOS 1 and RTOS 2 using said fault thriving automotive display ECU system.

2. The system as in claim 1, wherein said RTOS 1 is assigned a plurality of functionalities related to an In-Vehicle Infotainment system in said automotive environment.
3. The system as in claim 1, wherein said RTOS 2 is assigned a plurality of functionalities related to an Instrument Cluster (IC) system in said automotive environment.
4. The system as in claim 1 is further configured to integrate said RTOS 1 and RTOS 2 to said fault thriving automotive display ECU system by:

selecting at least one functionality to integrate with said RTOS 2 from said plurality of functionalities of said RTOS 1, using said fault thriving automotive display ECU system;
selecting at least one functionality to integrate with said RTOS 1 from said plurality of functionalities of said RTOS 2, using said fault thriving automotive display ECU system;
integrating said selected at least one functionality of said RTOS 1 with said RTOS 2, using said fault thriving automotive display ECU system;
integrating said selected at least one functionality of said RTOS 2 with said RTOS 1, using said fault thriving automotive display ECU system; and
integrating said RTOS 1 and RTOS 2 with a hypervisor module of said fault thriving automotive display system.

5. The system as in claim 4 is further configured to select said at least one functionality of said RTOS 1 to integrate with said RTOS 2 based on a priority level of said functionality using said fault thriving automotive display ECU system.

6. The system as in claim 4 is further configured to select said at least one functionality of said RTOS 2 to integrate with said RTOS 1 based on a priority level of said functionality using said fault thriving automotive display ECU system.

7. The system as in claim 1, wherein said fault assistance module is further configured to identify occurrence of said at least one fault associated with said at least one process being handled by said RTOS 1 based on a plurality of pre-configured data, using a fault discovery module.
8. The system as in claim 1, wherein said fault assistance module is further configured to identify occurrence of said at least one fault associated with said at least one process being handled by said RTOS 2 based on a plurality of pre-configured data using a fault discovery module.

9. The system as in claim 1, wherein said fault assistance module is further configured to perform said fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 1, by executing integrated functionalities of said RTOS 1 with said RTOS 2, using a graded functionality takeover module.

10. The system as in claim 1, wherein said fault assistance module is further configured to perform said fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 2, by executing integrated functionalities of said RTOS 2 with said RTOS 1, using a graded functionality takeover module.

11. The system as in claim 1, wherein said fault thriving automotive display ECU system is further configured to execute said plurality of functionalities associated with said RTOS 1 and RTOS 2 by:

identifying occurrence of an event corresponding to at least one of said plurality of functionalities using a trigger module;
checking criticality of said identified event using a gradual functionality takeover module;
invoking a critical code execution if said identified event relates to a critical event using said trigger module; and
invoking a normal runtime execution if said identified event relates to a non-critical event using said trigger module.

12. A method for fault management in an electronic control unit (ECU) in an automotive environment, said method comprises:
identifying occurrence of at least one fault associated with at least one process being handled by a Real Time Operating System 1 (RTOS 1);
identifying occurrence of at least one fault associated with at least one process being handled by a Real Time Operating System 2 (RTOS 2);
triggering a fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 1;
triggering a fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 2; and
executing at least one of a plurality of functionalities associated with said RTOS 1 and RTOS 2.

13. The method as in claim 12, wherein said RTOS 1 is assigned a plurality of functionalities related to an In-Vehicle Infotainment system in said automotive environment.

14. The method as in claim 12, wherein said RTOS 2 is assigned a plurality of functionalities related to an Instrument Cluster (IC) system in said automotive environment.

15. The method as in claim 12, wherein occurrence of said at least one fault associated with said at least one process being handled by said RTOS 1 is identified based on a plurality of pre-configured data.

16. The method as in claim 12, wherein occurrence of said at least one fault associated with said at least one process being handled by said RTOS 2 is identified based on a plurality of pre-configured data.

17. The method as in claim 12, wherein performing said fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 1 further comprises initializing at least one of a plurality of integrated functionalities of said RTOS 1 using said RTOS 2.

18. The method as in claim 12, wherein performing said fault recovery process upon identifying occurrence of said at least one fault with said at least one process being handled by said RTOS 2 further comprises initializing at least one of a plurality of integrated functionalities of said RTOS 2 using said RTOS 1.

19. The method as in claim 12, wherein executing said plurality of functionalities associated with said RTOS 1 and RTOS 2 further comprises:

identifying occurrence of an event corresponding to at least one of said plurality of functionalities;
checking criticality of said identified event;
invoking a critical code execution if said identified event relates to a critical event; and
invoking a normal runtime execution if said identified event relates to a non-critical event.

Dated: 26th August, 2013 Signature
Vikram Pratap Singh Thakur
,TagSPECI:FORM 2
The Patent Act 1970
(39 of 1970)
&
The Patent Rules, 2005
COMPLETE SPECIFICATION
(SEE SECTION 10 AND RULE 13)

TITLE OF THE INVENTION
METHOD AND SYSTEM FOR CREATING FAULT THRIVING
AUTOMOTIVE DISPLAY ECU
APPLICANTS:
Name : HCL Technologies Limited
Nationality : Indian
Address : HCL Technologies Ltd., 50-53 Greams
Road, Chennai – 600006, Tamil Nadu, India

The following Specification particularly describes and ascertains the nature of this invention and the manner in which it is to be performed:
TECHNICAL FIELD
[001] The embodiments herein relate to embedded virtualization and, more particularly, to create fault thriving automotive display Electronic Circuit Unit (ECU) based on concept of graded functionality takeover.

BACKGROUND
[002] In recent years, virtualization has become an important technology in embedded systems. Virtualization technology provides an environment that enables the sharing of hardware resources (CPUs, memory, I/O) on a single computer system, allowing multiple operating systems to simultaneously share the system. In other words, embedded virtualization creates a partitioned environment in which two Operating Systems and the applications on them run on a single platform as if they were running on two separate platforms. Further, using ‘embedded hypervisors’ implements a different kind of abstraction with different capabilities than other platforms. These hypervisors can capable of providing good efficiency, security and isolation among different runtime environments.
[003] Further, in some of the existing systems, the applications that are running in a runtime environment may stop working due to faults encountered at the different levels of the runtime environment. This becomes more dangerous when some critical applications like emergency call, breakdown assistance, display warnings, Speedo gage and so on stopped working suddenly. In some cases, even the applications are running correctly, they are not initiated at desired time. For example, in a vehicle like car, rear view camera needs to be up and running within a few seconds from the moment of ignition. Executing such critical applications with time delay may results in damage. In other cases, some applications need to be stopped depending on the criticality of the situation. For example, under reasonably low battery conditions, heavy In-Vehicle Infotainment functions such as video, audio should be stopped automatically while enabling only critical functions like reverse camera display, emergency call.

SUMMARY
[004] In view of the foregoing, an embodiment herein provides a system for fault management in an electronic control unit (ECU) in an automotive environment. The system is configured for integrating a Real Time Operating system 1 (RTOS 1) and a Real Time Operating system 2 (RTOS 2) to a fault thriving automotive display ECU system. Further, the system identifies occurrence of at least one fault associated with at least one process being handled by the RTOS 1 of the fault thriving automotive display ECU system and occurrence of at least one fault associated with at least one process being handled by the RTOS 2 using a fault assistance module. Further, a fault recovery process is performed upon identifying occurrence of the at least one fault with the at least one process being handled by the RTOS 1 or else upon identifying occurrence of the at least one fault with the at least one process being handled by the RTOS 2, using the fault assistance module. Further, the system executes at least one of a plurality of functionalities associated with the RTOS 1 and RTOS 2 using the fault thriving automotive display ECU system.
[005] Embodiments further disclose a method for fault management in an electronic control unit (ECU) in an automotive environment, the method comprises identifying occurrence of at least one fault associated with at least one process being handled by a Real Time Operating System 1 (RTOS 1). Further occurrence of at least one fault associated with at least one process being handled by a Real Time Operating System 2 (RTOS 2) is identified. Furthermore, a fault recovery process is triggered upon identifying occurrence of the at least one fault with the at least one process being handled by the RTOS 1 or else upon identifying occurrence of the at least one fault with the at least one process being handled by the RTOS 2. Further, at least one of a plurality of functionalities associated with the RTOS 1 and RTOS 2 are executed.
[006] These and other aspects of the embodiments herein will be better appreciated and understood when considered in conjunction with the following description and the accompanying drawings.

BRIEF DESCRIPTION OF THE FIGURES
[007] The embodiments herein will be better understood from the following detailed description with reference to the drawings, in which:
[008] FIG. 1 illustrates a block diagram of Fault thriving automotive display ECU system environment, as disclosed in the embodiments herein;
[009] FIG. 2 illustrates a block diagram that shows various components of the Fault thriving automotive display ECU system, as disclosed in the embodiments herein;
[0010] FIG. 3 illustrates a block diagram that shows various components of a Fault assistance module, as disclosed in the embodiments herein;
[0011] FIG. 4 is a flow diagram which shows various steps involved in the process of integrating In-Vehicle Infotainment (IVI) and Instrument Cluster (IC) sub-systems with Fault thriving automotive display ECU system, as disclosed in the embodiments herein; and
[0012] FIG. 5 is a flow diagram which shows various steps involved in the process of Fault thriving automotive display ECU system behavior during run time, as disclosed in the embodiments herein.

DETAILED DESCRIPTION OF INVENTION
[0013] The embodiments herein and the various features and advantageous details thereof are explained more fully with reference to the non-limiting embodiments that are illustrated in the accompanying drawings and detailed in the following description. Descriptions of well-known components and processing techniques are omitted so as to not unnecessarily obscure the embodiments herein. The examples used herein are intended merely to facilitate an understanding of ways in which the embodiments herein may be practiced and to further enable those of skill in the art to practice the embodiments herein. Accordingly, the examples should not be construed as limiting the scope of the embodiments herein.
[0014] The embodiments herein disclose a Fault thriving automotive display ECU system by using graded functionality take over based on functional criticality in fault conditions. Referring now to the drawings, and more particularly to FIGS. 1 through 5, where similar reference characters denote corresponding features consistently throughout the figures, there are shown embodiments.
[0015] FIG. 1 illustrates a block diagram of Fault thriving automotive display ECU system environment, as disclosed in the embodiments herein. The system environment comprises of In-Vehicle Infotainment (IVI) system 101, Instrument Cluster 102 and a Fault thriving automotive display ECU system 103. The IVI system 101 represents integrated in-vehicle entertainment and information systems present in the vehicles such as cars. The features of IVI system may include but not limited to rear-seat entertainment, navigation system, radio/ CD player, location based services, internet connectivity and so on. The Instrument cluster 102 (also known as dashboard or instrument panel) is a combination of an instrument panel and a display device which is used to provide information/ alerts related to speed of the vehicle, fuel level, and any vehicle fault condition and so on. The Fault thriving automotive display ECU system 103 is an automotive environment where the IVI system and Instrument Cluster functionalities can be driven from a single ECU using of multiple runtime environments. The Fault thriving automotive display ECU system 103 further uses a hypervisor to create two different run time environments which are safe and secure from each other. Furthermore, the Fault thriving automotive display ECU system 103 is capable of sending/receiving messages from Controller Area Network (CAN) and Media Oriented System Transport (MOST).
[0016] FIG. 2 illustrates a block diagram that shows various components of Fault thriving automotive display ECU system, as disclosed in the embodiments herein. The system comprises of a virtual runtime environment 201, a hypervisor module 202, a fault assistance module 203 and a critical code booting module 204. The virtual runtime environment 201 is an application framework which is capable of supporting multiple runtime environments or multiple Run Time Operating Systems (RTOS 1, RTOS 2). Further, a bottom layer of the application framework is a RTOS layer which contains operating systems that belong to IVI system 101 and Instrument cluster 102. Consider that IVI functionalities are assigned to and are being handled by RTOS 1 and IC functionalities are assigned to and are being handled by RTOS 2. The RTOS 1 may contain a suitable Operating System (OS) such as a QNX or Win CE or Linux which supports the IVI system functionalities. Similarly, the RTOS 2 may contain a suitable OS such as an OSEK or AUTOSAR or uITRON which supports the Instrument Cluster functionalities. The bottom layer of RTOS module 201 further provides other necessary functionalities such as scheduler, memory access and so on. Further, peripheral drivers in a second layer of the application framework provides required Application Program Interfaces (APIs) to access devices such as E2PROM, Flash, ADIO, PWM, Audio chipset and so on. Further, a plurality of peripheral managers/device managers present in the second layer of the application framework provides a logical abstraction of components of the Fault thriving automotive display ECU system. The peripheral managers/device managers further provides means to share components across multiple run time environments effectively i.e. same component may be used for different functions. Furthermore, a third layer of the application framework comprises of middleware frameworks which include Audio, Video, Imaging middleware for IVI system and also a Human Machine Interface (HMI) backbone software that helps to provide suitable interfaces for the user to interact with the Fault thriving automotive display ECU system 103. The interfaces may vary significantly between the two runtime environments (RTOS 1 and RTOS 2) as both the runtime environments are intended for different applications i.e., the runtime environment RTOS1 is intended for multimedia application (IVI system) whereas the runtime environment RTOS2 is intended other for real time instrumentation display and diagnostics applications related to IC. Further, a fourth layer of the application framework is an application layer which comprises of suitable interfaces to facilitate user interaction with the system for various control and coordination purposes. In an embodiment, dedicated interfaces may be provided to interact with each application in the system. In another embodiment, multiple applications may be controlled using same interface. Furthermore, the communication between the two runtime environments for sharing data can be made through a combination of virtual Ethernet, virtual pipe and message queue.
[0017] The Hypervisor module 202 provides an abstraction layer which creates and manages virtual machines of isolated environments in which guest operating systems run. The guest operating system refers to an operating system which runs in a virtual machine environment. Further, the abstraction layer is maintained at a level higher than the guest operating systems, which enables partition boundaries, enforces system security, and ensures isolation between different run time environments.
[0018] The fault assistance module 203 performs various operations such as fault discovery, gradual fault recovery and gradual functionality takeover required for fault assistance in the Fault thriving automotive display ECU system environment.
[0019] The critical code booting module 204 contains one or more driver software that is required for the execution of critical functions. In an embodiment, ‘critical functions’ may refer to the functions which are having high priority when compared to other functions and which requires instant response. A few examples of the critical functions in a vehicle are:
• Turning up of Controller Area Network (CAN) such as wakeup and response to incoming and outgoing messages, sleep
• Turning up of Local Interconnect Network (LAN)
• Display control
• Running rear view camera and so on.
[0020] In a preferred embodiment, codes for execution related to high priority events (critical code) are added to the critical code booting module 204 whereas codes related to events having low priority are associated with drivers in RTOS 1 and RTOS 2; depending on which RTOS is handling that particular event. In another embodiment, the term “event” may refer to occurrence of fault with any process associated with any functionality being handled by the integrated system.
[0021] FIG. 3 illustrates a block diagram that shows various components of a Fault assistance module, as disclosed in the embodiments herein. The Fault assistance module 203 further comprises of a fault discovery module 301, a gradual fault recovery module 302, a gradual functionality takeover module 303, a hardware module 304, a trigger module 305 and a memory module 306.
[0022] The fault discovery module 301 is capable of detecting occurrence of fault associated with functionalities of different run time environments (RTOS 1 and RTOS 2 in this scenario) in the fault thriving automotive display ECU system by monitoring and checking functionalities associated with RTOS 1 and RTOS 2 on a regular basis.
[0023] The gradual fault recovery module 302 performs recovery measures whenever occurrence of a fault is identified by the fault discovery module 301. In an embodiment, the recovery means corresponding to occurrence of each event may be defined and preconfigured in a database associated with the memory module 306. The gradual fault recovery module 302 selects proper recovery measures corresponding to each occurred event from the database. In a preferred embodiment, the gradual fault recovery module 302 executes recovery means depending on priority level of the process involved. For example, consider that the fault discovery module 301 identified occurrence of faults involving processes “X” and “Y”. Now, the gradual fault recovery module 302 checks priority of the processes/functionalities X and Y and executes recovery measures corresponding to process of higher priority (say “X”). Further, the gradual fault recovery module 302 executes recovery measures corresponding to process of lower priority (say “Y”).
[0024] In another embodiment, gradual fault recovery module 302, depending on the level of priority of the process involved, prepares a list of methods (recovery measures) that are to be used for recovering the faults using database which is associated with memory module 306. Furthermore, number of iterations required for performing selected recovery measures may also be decided based on priority level of the process involved. For example, if a fault (corresponding to high priority event) was identified, gradual fault recovery module 302 prepares corresponding list of recovery measures and executes them to rectify the faults. If this attempt was not successful, gradual fault recovery module 302 again executes the methods as the process has high priority. .
[0025] The gradual functionality takeover module 303 manages the virtual runtime environment 201 by assigning the functionalities of one runtime environment to another when internal disturbances/faults occur in the fault thriving automotive display ECU system 103. For example, if the fault discovery module 301 identify that RTOS 1 is malfunctioning, then the gradual functionality takeover module 303 may assign functionalities of RTOS 1 to RTOS 2; thereby ensuring that fault of the RTOS 1 does not affect performance of the system.
[0026] The hardware module 304 of fault assistance module 203 comprises of hardware components such as multi-core (4 core or above) with a separate 3D graphics engine, 2D graphics engine, vector graphics engine, hardware audio codec & video codec, separate camera image processing unit, separate display and camera interface along with general blocks for various peripherals such as analog/digital Input Output, flash and so on; which are used to support functionality of the fault thriving automotive display ECU system . Further, hardware module 304 run the software processes that are associated with IVI system 101, IC 102, fault discovery module 301, gradual fault recovery module 302, gradual functionality takeover module 303 that present in fault thriving automotive display ECU system environment.
[0027] FIG. 4 is a flow diagram which shows various steps involved in the process of integrating In-Vehicle Infotainment (IVI) and Instrument Cluster (IC) sub-systems in Fault thriving automotive display ECU system, as disclosed in the embodiments herein. IVI and IC are two sub-systems of the Fault thriving automotive display ECU system. Initially, a first modular software (first software) is constructed (402) for IVI system 101 using RTOS1 of virtual runtime environment 201. The first modular software is constructed to handle processes or functions being supported/ functionalities being handled by the IVI system 101 such as but not limited to emergency calls, breakdown assistance, display, emails and messages, traffic alerts, and navigation. Further, the constructed first modular software is integrated and tested on RTOS1 of virtual runtime environment 201 to check compatibility of the first software with the RTOS 1. If the first software is not functioning properly with the RTOS 1, then the system may provide options for the user to modify the first software to make it compatible with the RTOS 1. If the first software passes the compatibility test i.e. if the first software is found to be compatible with the RTOS 1, then the system prioritizes (404) a few selected Instrument Cluster software processes in the RTOS 1. In an embodiment, prioritization involves assigning priority to various processes associated with different run time environments depending on criticality of the events. Further, information on priority assigned to each process may be stored as a priority matrix in the database associated with the memory module 306. For example, priority matrix for Instrument Cluster software may be depicted as given below:
• Sending and receiving CAN messages (Highest criticality -> priority) - Process A1
• Sending and receiving Gateway messages - Process A2
• Display warning – highest priority - Process A3
• Speedo gage - Process A4
• RPM gage - Process A5
• Engine Temp Gage - Process A6
• Oil level gage - Process A7
• Fuel gage - Process A8
• Critical telltales – Process A9
• Display – message centre - Process A10
• Non critical telltales - Process A11
• Display configurations/engine modes (Lowest criticality->priority) - Process A12
[0028] The depicted priority matrix which is defined for Instrument Cluster software in RTOS1 indicates that the process A1 (i.e. sending and receiving CAN messages) has given highest priority. Further, the priority can be assigned based on the criticality of the process. As the process of sending and receiving CAN messages is very important, it is given highest priority. Similarly, process A2 i.e., sending and receiving gateway messages is given second priority, display warnings as third priority and so on. After prioritizing, the Instrument Cluster software is integrated (404) on RTOS1 by providing provisions for selective running of prioritized Instrument Cluster software on RTOS1. The term “Selective running” refers to a process wherein if multiple events occur simultaneously, the system picks and executes them in the order of priority. Finally, the prioritized Instrument Cluster software is integrated and tested (406) with IVI software of RTOS1 for its proper functioning. This is done to ensure that when RTOS 2 (which handles IVI functionality) fails, RTOS 1 can act as a backup to execute functionalities of RTOS 1.
[0029] Similarly, a second modular software is constructed (408) for the Instrument Cluster 102 using the RTOS2 of the virtual runtime environment 201. The second modular software is constructed to handle processes that are supported/functionalities being handled by the Instrument cluster 102 such as but not limited to sending and receiving CAN messages/gateway messages, display warnings, and speed gage. Further, the second software is integrated to and is tested on the RTOS2 so as to check compatibility of the second software with the RTOS 2. If the second software is not functioning properly with the RTOS 2, then the system may provide options for the user to modify the first software to make it compatible with the RTOS 2. If the second software passes the compatibility test i.e. if the first software is found to be compatible with the RTOS 2, then the system prioritizes (410) a few selected IVI software processes in the RTOS 1. In an embodiment, prioritization involves assigning priority to various processes associated with different run time environments depending on criticality of the events. Further, information on priority assigned to each process may be stored as a priority matrix in the database associated with the memory module 306. For example, priority matrix for IVI software may depicted as given below:
• Emergency call - Highest criticality – Process B1 (A1 has highest criticality hence highest priority)
• Breakdown assistance – Process B2
• Display – Process B3
• Other telematics services – Process B4
• Voice enabled functionalities - Process B5
• Emails & messages - Process B6
• Traffic Alerts - Process B7
• Navigation - Process B8
• Audio - Process B9
• Video/pictures - Lowest criticality - Process B10
[0030] The matrix depicted above, which is defined for IVI software in RTOS2, indicates that process B1 (i.e., emergency call) has the highest priority because it has highest criticality. Similarly, process B2 (i.e., breakdown assistance) is of second priority, display is given third priority and so on. After prioritizing, the IVI software is integrated (410) on RTOS2 by providing provisions for selective running of prioritized IVI software. Finally, the prioritized IVI software is integrated and tested (412) with Instrument Cluster software of RTOS2 for its proper functioning. After constructing the first modular software and the second modular software in the virtual runtime environment 201, both IVI and IC sub-systems are integrated (414) with the hypervisor module 202. Further, the integrated system handles functionalities of related to both runtime environments (IVI system 101 and Instrument cluster 102) that are present in virtual runtime environment 201.
[0031] For the processes or functions which are considered as most critical, corresponding code is added (416) directly to the critical code booting module 204 of fault thriving automotive display ECU system 103. Finally, integrated software is tested over both virtual runtime environments (i.e., IVI and IC sub-systems) for its proper functioning. The various actions in method 400 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 4 may be omitted.
[0032] FIG. 5 is a flow diagram which shows various steps involved in the process of Fault thriving automotive display ECU system behavior during run time, as disclosed in the embodiments herein. Initially, when ignition ON, the Fault thriving automotive display ECU system 103 is booted (502) with integrated dual runtime environments (both IVI and IC sub-systems). Booting may involve initializing the integrated system functionalities. In an embodiment, the term ‘booting’ refers to an initial set of operations that the fault thriving automotive display ECU system performs upon initializing the system. After booting, the Fault thriving automotive display ECU system 103 starts running (504) the integrated dual runtime environments i.e., RTOS1 and RTOS2 of virtual runtime environment 201.
[0033] Now, the fault discovery module 301 of fault assistance module 203 checks the virtual runtime environment 201 for faults over RTOS1 (506) and RTOS 2 (514). The fault discovery module 301 may use a plurality of preconfigured data from the memory module 306 in order to identify faults over RTOS1 and RTOS 2. For example, the fault discovery module 301 may invoke all functionalities of the operating systems RTOS 1 and RTOS 2 as soon as the integrated system is initialized by fetching and using parameters required to initialize each functionality, from the memory module 302. Further, the fault discovery module 301 fetches responses corresponding to each invoked function and analyzes it for fault detection. If at least one fault is identified with RTOS 1, then the gradual functionality takeover module 303 assigns (510) selected processes set of IVI system 101 from RTOS 1 to RTOS2 of virtual runtime environment 201 using the trigger module 305. Further, the RTOS2 executes assigned functionalities of RTOS 1 along with own functionalities.
[0034] Further, if at least one fault is identified with RTOS 2, then the gradual functionality takeover module 303 assigns (518) selected processes set of IC system 102 from RTOS 2 to RTOS 1 of virtual runtime environment 201 using the trigger module 305. Further, the RTOS 1 executes assigned functionalities of RTOS 2 along with own functionalities.
[0035] Furthermore, if no faults are identified in any of the virtual runtime environments RTOS 1 and RTOS 2, the operating systems executes own functionalities without performing any takeover.
[0036] Further, when an event occurs in the fault thriving automotive display ECU environment, the trigger module 305 identifies (512) the occurred event and notifies the gradual fault recovery module 302. In an embodiment, the events are classified as high priority events and low priority events based on criticality of the event. The high priority events require immediate response i.e. recovery measures corresponding to each high priority event is to be executed without any time delay. So codes related to recovery means of the high priority events (i.e. critical code) are stored in the critical code booting module 204. Events having high priority level are considered as critical events. Upon identifying an event, the gradual fault recovery module 302 identifies priority of the occurred event using information stored in the database and checks (520) whether the occurred event is a critical event or not.
[0037] Further, in a preferred embodiment, when occurrence of a high priority event (i.e. critical event) is detected, a critical code execution is invoked (522) by the trigger module 305. The critical code execution involves execution of corresponding codes by bypassing hypervisor module 202; thereby ensuring instant response. However, a primary scheduler in the hypervisor module 202 may be used to run a hypervisor thread and to execute one of the available virtual runtimes along with some of critical functions; which is required for execution of a selected critical code.
[0038] As the execution of processes or functions is performed directly through primary scheduler without involving hypervisor module (bypassing normal runtime execution), the time taken to execute these processes is very less when compared with normal runtime execution. Further, bypassing of hypervisor module 202 ensures predictability of processes or functions that are being executed, as the code of critical events is executed quickly and consistently over the application layer. For example, as the process of wake-up/responding to incoming CAN messages & sending outgoing wake-up/response messages is critical, this software is made to reside directly over the critical code booting module 204 which uses only the primary scheduler of hypervisor module 202. Further, these tasks are added to the primary scheduler ensuring that the virtual runtimes are completely bypassed. In another example, a rear view camera needs to be up and should run in first few seconds, so the camera driver (CSI or LVDS or equivalent) and display application is added as a critical event to the critical code booting module 204 which uses only the primary scheduler of hypervisor module 202.
[0039] Further, if the identified event is of low priority (i.e. a non critical event), a normal run time execution is invoked (524) by the trigger module 305. In an embodiment ‘normal runtime execution’ involves execution of processes or functions through a four layer application framework which is designed above hypervisor layer. The various actions in method 500 may be performed in the order presented, in a different order or simultaneously. Further, in some embodiments, some actions listed in FIG. 5 may be omitted.
[0040] Given below is an example for the gradual priority takeover process. Consider that the prioritized IVI process matrix which is integrated with virtual runtime environment 201. During the failure of IVI runtime environment i.e., RTOS1, runtime environment2 i.e., RTOS2 executes the processes of RTOS1 as per priority given. The following steps may define the execution process of IVI critical processes in RTOS2:
1. Run Instrument Cluster software as it is
2. Run RTOS2 (processB1)
3. If successful, proceed to B2, next in the list
4. If unsuccessful, retry
5. Check for systemic or random failure
6. If systemic, continue with IC SW alone
7. If random, If unsuccessful for 3 times, proceed to next in the list - B2
8. Keep continuing from step 3
[0041] In an embodiment, the fault thriving automotive display ECU system 103 take advantage of both functionalities and can enable or disable the functionalities based on the order of criticality assigned. For example, under reasonably low battery condition, heavy IVI functions can be stopped (such as video or audio play) and only critical functions such as reverse camera display, emergency call features can be enabled. Further, remote diagnosis can be provided by taking out diagnostic warnings and issues from Instrument Cluster 102 and pass on to the IVI system 101 to provide to backend server using 3G telephony.
[0042] The embodiments disclosed herein can be implemented through at least one software program running on at least one hardware device and performing network management functions to control the network elements. The network elements shown in Fig. 1 to Fig. 3 include blocks which can be at least one of a hardware device, or a combination of hardware device and software module.
[0043] The embodiment disclosed herein specifies a system for creating fault thriving automotive display ECU. The mechanism allows graded functionality takeover based on functional criticality in fault condition providing a system thereof. Therefore, it is understood that the scope of the protection is extended to such a program and in addition to a computer readable means having a message therein, such computer readable storage means contain program code means for implementation of one or more steps of the method, when the program runs on a server or mobile device or HW PCB board or any suitable programmable device. The method is implemented in a preferred embodiment through or together with a software program written in e.g. Very high speed integrated circuit Hardware Description Language (VHDL) or C/C++ or another programming language, or implemented by one or more VHDL or several software modules being executed on at least one hardware device. The hardware device can be any kind of device which can be programmed including e.g. any kind of computer like a server or a personal computer, or the like, or any combination thereof, e.g. one processor and two FPGAs. The device may also include means which could be e.g. hardware means like e.g. an ASIC, or a combination of hardware and software means, e.g. an ASIC and an FPGA or Multi-core processor board and SW, or at least one microprocessor and at least one memory with software modules located therein. Thus, the means are at least one hardware means and/or at least one software means. The method embodiments described herein could be implemented in pure hardware or partly in hardware and partly in software. The device may also include only software means. Alternatively, the invention may be implemented on different hardware devices, e.g. using a plurality of CPUs.
[0044] The foregoing description of the specific embodiments will so fully reveal the general nature of the embodiments herein that others can, by applying current knowledge, readily modify and/or adapt for various applications such specific embodiments without departing from the generic concept, and, therefore, such adaptations and modifications should and are intended to be comprehended within the meaning and range of equivalents of the disclosed embodiments. It is to be understood that the phraseology or terminology employed herein is for the purpose of description and not of limitation. Therefore, while the embodiments herein have been described in terms of preferred embodiments, those skilled in the art will recognize that the embodiments herein can be practiced with modification within the spirit and scope of the claims as described herein.