FORM 2
THE PATENTS ACT 1970
[39 OF 1970]
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
[See section 10; rule 13]
Title: "ARCHITECTURE FOR INFOTAINMENT SYSTEM AND METHOD OF COMMUNICATION AMONG APPLICATION MODULES IN INFOTAINMENT THE SYSTEM"
Name and Address of the Applicant:
TATA MOTORS LIMITED, Bombay House, 24 Homi Mody Street, Hutatma Chowk, Mumbai -400001, Maharashtra , India
Nationality: IN
The following specification particularly describes the invention and the manner in which it is to be performed.

TECHNICAL FIELD
Embodiments of the present disclosure relates to the field of entertainment system of a vehicle. More particularly, embodiments of the disclosure relate to architecture for an infotainment system and a method of communication among application modules in the infotainment system.
BACKGROUND
Infotainment system is information-based media content or programming that includes entertainment content in an effort to enhance popularity with audiences and consumers. Generally, infotainment systems are used for providing information to the user.
Vehicles are typically equipped with an infotainment system capable of receiving infotainment media, such as radio signals, music files stored on a compact disc, music files stored on an MP3 device, music and video files stored on a digital video disc, and navigational information including map files and radio frequency signals provided by a global positioning system (GPS). Many of these infotainment systems are capable of receiving and processing multiple forms of infotainment media. For instance, a vehicle infotainment system might include any combination of a radio receiver for receiving broadcast radio signals, a satellite radio receiver for receiving satellite radio signals, a compact disc player, a digital video disc player and an MP3 port for linking to an MP3 storage device. The infotainment system provides the user with in-vehicle infotainment derived from these infotainment media. The field of in-vehicle infotainment systems covers a wide variety of digital applications, including internal connectivity, entertainment, external communications, navigation services, and radio.
Layered architecture for the infotainment system provides modularity, flexibility and portability of the application modules and the hardware used in the infotainment system.
STATEMENT OF THE INVENTION
Accordingly the embodiments of the present disclosure provides architecture for infotainment system, having one or more Electronic Control Unit (ECU) nodes, comprising an information input manager module to receive and process inputs from user through Human Machine interface (HM1) and to forward the inputs as commands to respective application manager module, the

application manager module forwards the commands to respective application slave module for execution, the application slave module executes the commands and reports changes in the application to the user through the HMT, the changes are displayed in the application display view module configured in the HMI, a resource master module configured to allocate resources for the active applications in the infotainment system, a power master module configured to' provide overall power management of the infotainment system, a network master module configured to manage information of the application slave module, it also provides a method of communication among applications in the infotainment system, said method comprising acts of sending messages from the applications present in the ECU node of the infotainment system to a transport layer, wherein the transport layer checks for application block ID and instance ID attached with the messages, transmitting the messages to recipient application by the transport layer, if the recipient application is present in the same ECU node as the sender application, and transmitting the messages on Communication Area Network (CAN) by attaching CAN message ID by the transport layer if the recipient application resides on different ECU node other than the sender ECU node.
SUMMARY OF THE INVENTION
This section provides a general summary of the disclosure, and is not a comprehensive disclosure of its full scope or all of its features.
Additional features and advantages are realized through the techniques of the present disclosure. Other embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed disclosure.
In one embodiment, the present disclosure provides architecture for the infotainment system. The infotainment system comprises of plurality of applications which reside in the ECU node of the infotainment system. The ECU nodes communicate over CAN communication bus. The architecture provides an information input manager module which is configured to receive and process inputs from user through HMI and to forward the inputs as commands to respective application manager module. The application manager module, forwards the commands to respective application slave module, contains operational functionality of an application and maintains state machine for the application. The application slave module executes the

commands and reports to the user through the HMI. The application display view module configured in the HMI displays information based on the state change of the application.
In one embodiment, the architecture provides a resource master module which is configured to allocate resources for the active applications in the infotainment system.
In one embodiment, the architecture provides a power master module which is configured to provide overall power management like voltage monitoring, initialization and shut down of the infotainment system.
In one embodiment, the architecture provides a network master module which is configured to manage information of the application slave module, about their current application status.
In one embodiment, the present disclosure provides a method of communication among application in the infotainment system. The applications transmit the messages to the transport layer. When the transport layer receives the message from the CAN communication bus, it checks for the application block ID and the instance ID in the message for the target application. If the target application resides in the same ECU node as of the transmitter application, then the message is routed internally to the corresponding target application. If the target application is residing in a different ECU node of the infotainment system, then CAN message ID of the destination node is attached with the message and transmitted on the CAN network.
The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects. embodiments, and features will become apparent by reference to the drawings and the following detailed description.
BRIEF DESCRIPTION OF THE DRAWINGS
The novel features and characteristics of the disclosure are set forth in the appended claims. The embodiments of the disclosure itself, however, as well as a preferred mode of use, further objectives and advantages thereof, will best be understood by reference to the following detailed description of an illustrative embodiment when read in conjunction with the accompanying

drawings. One or more embodiments are now described, by way of example only, with reference to the accompanying drawings and in which:
Fig.l is an exemplary block diagram which illustrates architecture for infotainment system.
Fig. 2 is an exemplary block diagram which illustrates layered architecture of master node of the infotainment system.
Fig. 3 is an exemplary block diagram which illustrates layered architecture of slave node of the infotainment system.
Fig.4 shows an exemplary flow diagram of HMI development.
Fig.5 shows a flow diagram illustrating operation flow from application display view module to the HMI.
Figs. 6 and 7 diagrammatically illustrates message format of a single and a multi-frame message transmitted on CAN bus.
Fig. 8 shows principle structure of the infotainment system protocol in the application layer.
Fig. 9 is an exemplary block diagram which illustrates communication among applications in the infotainment system.
The figures depict embodiments of the disclosure for purposes of illustration only. One skilled in the art will readily recognize from the following description that alternative embodiments of the structures and methods illustrated herein may be employed without departing from the principles of the disclosure described herein.
DETAILED DESCRIPTION
The foregoing has outlined rather broadly the features and technical advantages of the present disclosure in order that the detailed description of the disclosure that follows may be better understood. Additional features and advantages of the disclosure will be described hereinafter which form the subject of the claims of the disclosure. The novel features which are believed to

be characteristic of the disclosure, both as to its organization and method of operation, together with further objects and advantages will be better understood from the following description when considered in connection with the accompanying figures. It is to be expressly understood, however, that each of the figures is provided for the purpose of illustration and description only and is not intended as a definition of the limits of the present disclosure.
In an exemplary embodiment, the present disclosure provides architecture for infotainment system and a method of communication among applications present in the infotainment system.
The infotainment system is information based media content or programming that also includes entertainment content, which comprises one or more ECU nodes communicating over a Controller Area Network (CAN) communication bus. ECU is a generic term for any embedded system that controls one or more of electrical systems or subsystems in a motor-vehicle. Infotainment applications includes but are not limited to AMFM application, media player (CD, DVD, and USB) application, Bluetooth application, and Navigation application which reside in the ECU nodes.
The layered architecture is defined for each of the ECU node to provide modularity, flexibility and portability of the application present in the ECU nodes.
Fig.l is an exemplary block diagram which illustrates layered architecture for the infotainment system. The infotainment system comprises of plurality of applications including but not limiting to AMFM application, media player (CD, DVD, and USB) application, bluetooth application, and navigation application wherein the applications reside in the ECU node of the infotainment system.
In one aspect of the disclosure, the architecture provides plurality of modules selected from a group comprising an information input manager module, an application manager module, an application display view module, a resource master module, a power master module, a network master module and a slave application module.
The information input manager module receives and process inputs from user through Human Machine Interface (HM1) and forwards the inputs as commands to the respective application

manager module. The HMI includes but not limiting to High Line Display Front (HLDF) interface, touch screen interface and Integrated Control Panel-(ICP) interface. A person skilled in the art would understand that any other type of the HMI can be used for the infotainment system. The application manager module forwards the commands to the respective application slave module. The application manager modules are AMFM application manager module, media player application manager module, navigation application manager module and BPM application manager module. The application manager module contains operational functionality of the application and also maintains state machine for the application like start of an application and process of an application. The application slave module executes the commands from the user and reports the state of the application to the user through the HMI. The application display view module displays information based on the state change of the application. The application display view module displays information based on the state change of the application. The application slave modules are Audio Modulation Frequency Modulation (AMFM) slave, Bluetooth Phone Module (BPM) slave, media player slave and Navigation slave.
In one embodiment, the applications residing in the ECU nodes communicate over CAN communication bus.
The architecture further comprises of the resource master module configured to allocate audio/video resources for different applications in the infotainment system. It is referred as a connection master in the infotainment system. The resource master prioritizes the request for common resources. It bases its decision on which applications are active, the priority of the active applications and the workload for the driver. It has also the responsibility to try to recover the system to its previous state after an abnormal shutdown/reset or normal start-up. The resource master module allocates audio resource for the active sources in the infotainment system and coordinates different audio sources. Also, the resource master module allocates display resource for the active sources in the infotainment system and coordinates different video or display sources.
The power master module does overall power management for the infotainment system like voltage monitoring, initialization and shut down of the system. It controls infotainment power

relay and system reset condition. Power master module also broadcast power status to network master module which then starts the infotainment system initialization.
The network master module controls the infotainment system state and administrates the central infotainment registry. Network master module monitors the network for certain events and continuously manages incoming information from slave nodes about their current application block status. The Network master module distributes the system state by broadcasting system status messages. Network master module also manages infotainment initialization and shutdown in a controlled manner. Application blocks are not allowed to communicate with each other without network master module authorization.
In one embodiment, the infotainment system network is configured in the infotainment architecture in three states: i.e system ready, system not ready and system changed (due to node/object re-configuration).
In one embodiment, there is a central registry in the network master containing logical address of the respective application blocks of each node. The network master generates this central registry during the initialization of the infotainment network and continues to administer it until the network is shutdown. The main purpose of the central registry is used to when the network master checks the system configuration i.e. which application is alive and when the application is searching for communication partner. System initialization is not complete until central registry is build and broadcasted to every block in network.
Upon start-up when the infotainment node (ECU node) completes its initialization, the network master scans the system. The scanning operation is done periodically once infotainment system is fully operational network master to broadcast health of the network (i.e. status of the central registry). However until the network is ready, none of the node/block is allowed to send any application messages or communicate with each other. During normal operation the network master continuously updates the network states by checking the network heart beat. If any changes to the network state, then it shall broadcast this node slave and update central registry accordingly to reflect true status of system.

In one embodiment, during normal operation of the network master, either one or more slave application within the ECU node becomes non responsive or one or more physical node become non responsive. If one of the above conditions occurs then network master updates central registry and broadcast the network state by setting missing application's bit field to false. Upon reading network state HMI in turn inhibit the missing application. Abrupt system reset or shutdown is not allowed in the infotainment architecture.
In one embodiment, if the ECU nodes recognize that it's input for the signal is off then it shall also switch off the output. Due to this reason message transfer will be halted in the network. Network master will notice error on communication halt in the network. If this condition ever arises then infotainment system will carry out following functions:
1. If network master notices a communication halt in the network then it shall retries to obtain heart beat signal of the non responsive node or block.
2. If after retries there is no response from node slave then network master shall instruct power master to shutdown the network by setting network state to reset.
3. Power master broadcast that every block needs to prepare for controlled shutdown. HMI in turn decode this inform user by displaying necessary data in HMI display. Once this is done system make a controlled shutdown.
In one embodiment, the ECU node acts as either master node or slave node.
Fig.2 and Fig.3 are exemplary block diagrams which illustrates layered architecture for the master node and the slavenode.
The master node and the slave node consist of application layer, abstract layer, network master, CAN transport layer, OS/Scheduler, plurality of drivers and ECU target hardware. The application layer is the top layer of the OSI model. This layer handles issue like network transparency, resource allocation and problem partitioning. The application layer is concerned with user's view of network and provides services for an application program to ensure that effective communication with another application program in a network is possible.

In one embodiment, the application layer of the master node includes but are not limited to information input manager module, resource master module, power master module, audio manager module, entertainment manager module, entertainment application module, BPM application manager module and its corresponding display view module, navigation manager module and its corresponding display view module, audio and general application module and its corresponding display view module, and embedded wizard manager module.
The information input manager module receives and process signals from the HMI and forwards them to the respective application interface. The user can request for any infotainment application through the HMI and the information input manager module will forward the requested application to the respective application interface. The resource master module handles the audio/video resource allocation for different applications. The power master module does overall power management like voltage monitoring, initialization and shut down of the system. Audio manager module encompasses the functionality that controls an audio amplifier and entertainment manager module activates and deactivates all the application on request from the user. It also keeps track of the current activated application. The entertainment application module controls state machine of the application like start of an application, process of an application and its corresponding display view module displays the information based on state change of the application.
The audio and general application display view module maintains common data of all the display view modules, and the embedded wizard manager module communicates with the display view modules and controls the video output of the master node. The embedded wizard manager module is generated by embedded wizard authoring tool.
In one embodiment, the abstract layer of the master node consists of HLDF (High Line Display Front) interface, touch screen interface, Integrated Control Panel (ICP) interface which controls the transfer of touch data from the user to the hardware interface drivers, to control the data entry display.
In one embodiment, network master of the master node handles infotainment node network management. Network management refers to the activities, methods, procedures, and tools that pertain to the operation, administration, maintenance, and provisioning of networked systems.

Heart beat program in the network master provides a basis for verifying the availability of resources on one or more systems within a cluster. A cluster within the context of the heartbeat is defined as two computers notionally providing the same service.
In one embodiment, the application layer of the slave node consists of AMFM slave which communicates with the AMFM application manager module for tuner functionality, media player slave which communicates with the media player application manager module for CD, DVD, USB functionality, BPM slave which communicates with the BPM application manager module for Bluetooth hands free functionality, and navigation slave which communicates with navigation application manager module for integrating navigation in the infotainment system.
in one embodiment, abstract layer of the slave node provides AMFM interface for the AMFM slave to communicate with the AMFM application manager module, CD/DVD/USB interface for the media player slave to communicate with the media player application manager module, BPM interface for the BPM slave to communicate with the BPM application manager module and navigation interface for the navigation slave to communicate with the navigation application manager module
In one embodiment, the CAN transport layer provides services for, segmentation of data in transmit direction if the application being sent to the other node in the infotainment system is very large, reassembling of data in receive direction, control of data flow, detection of errors in segmentation sessions and transmit cancellation of the application.
In one embodiment, OS/Scheduler performs task of scheduling. Scheduling is the process of deciding how to commit resources between varieties of possible tasks. Time can be specified or floating as part of a sequence of events. For example in a car Infotainment system the user may want to listen to FM for few minutes and then he may switch to media player. The Scheduler assigns definite intervals of time for the specific tasks to be performed for the user. The scheduler itself is a loop that calls one of the other processes eath time it executes.
In one embodiment, drivers such as Inter Integrated Circuit (I2C), Universal Asynchronous Receiver/Transmitter (UART), and General Purpose Input/output (GPIO) are used to

communicate with display controller, touch Screen interface, ICP interface and IRM interface respectively through the bus or communication subsystems to which the hardware connects.
In one embodiment, the ECU target hardware is used for hardware platform. A hardware platform is the choice of hardware, PC or workstation, for the development of the infotainment system.
Fig.4 shows an exemplary flow diagram of the HMI development.
In one embodiment, the present disclosure provides architecture for the development of the HMI for the infotainment system and integration of the HMI with the applications of the infotainment system.
In one embodiment, the architecture defines the communication interface between HMI and the application. The architecture defined makes the HMI decoupled from the applications and facilitates various operations including but not limiting to parallel development of the HMI and core application, easy integration of newly developed HMI with application, and use of authoring tool for the HMI development.
The Infotainment system has different applications such as Tuner, CD, USB, Bluetooth, Navigation etc. These applications have explicit HMI display requirements. Based on the functionality of these applications, the screen flow and screen content are defined. The screen flow defines the transition between the screens in the system, whereas the content of each screen is specified as object list. Object list for a screen contains screen name, list of soft buttons along with the description for example button ID, button description and list of data holders, icons, images etc. In one embodiment an authoring Tool for example embedded wizard is used for developing the screens. Authoring tool uses images from designer sketches, screen object list, animation data, and its scripting language to develop the screen. The authoring tool generates the code for the developed screens. The Authoring tool is capable of generating the code for different hardware platforms and operating systems.
The developed application code interacts with the generated HMr code through API calls. Each application module in the application has different modules. In one embodiment the application module includes but not limited to application manager module that contains the operational

functionality of the application and maintains the state machine for the application, and application display module that contains the display functionality based on the state of the application.
In one embodiment, the application display module provides the information to be displayed on the screen based on the state of the application. Further, the application display module interacts with the HMI through the defined HMI APIs. The APIs defined are
1) StartSplash -To start/stop the initial start up animation.
2) ChangeView - For changing the screen
3) UpdateData-For changing/publishing the data for a data holder
4) HighlightButton - For highlighting/un-highlighting a touch button in the screen
5) HalaButton - For haloing/un-haloing a touch button in the screen
6) ButtonEnable - For enabling/disabling a touch button in the screen
7) SetAudioBalance - For set the slider position for visual slider in the screen
In the Infotainment system, the display is divided into different areas and each area is considered as a video sink. Video sinks considered for the infotainment system are:
a) BG - is the whole display area, considered as back ground video sink
b) FG1 - is an area over BG, considered as foreground 1 video sink, which can be of any size
c) FG2 - is an area over FG1, considered as foreground 2 video sink or a popup, which can be of any size
d) FG3 - is an area in the screen, considered as status bar.
Embodiments of the disclosure are explained with the help of below example. However, these examples should not be construed as limitations on the scope of the disclosure.

The AMFM Display module uses the API UpdateData (DataHolderlD, Data) of the generated HMI code, for updating data in the published screen on display. When UpdateData API is called, HMI manager updates the screen with the data acquired from the AMFM Display module for the data holder specified by the DataHolderlD.
Let the DataHolderlD be AMFM_D4 which is used for displaying the current tuned frequency. The current displayed data is "101.00". When the user tunes to a new frequency "101.10", the display screen should be updated with the new frequency. AMFM Display module calls the API UpdateData (AMFM_D4,"101.10") of the HMI code. Now the HMI manager updates the screen with "101.10" for the data holder AMFM_D4 on the Display.
Referring now to Figure 5, illustrates communication between application display modules and API's of the HMI. The application display module checks for the state change in the application. If there is a state change in the application, then application display module calls the various available APIs of HMI for updating the display, based on the current state of the application. When the APIs are called by the application display module, HMI code publishes/updates the display screen accordingly.
In one embodiment, clear interfaces between the application and HMI are defined so that the parallel development of HMI and applications helps in improving the time line of the project.
In one embodiment, easy integration of the newly developed HMI with the application is achieved by defining communication interface between the HMI and core application, and changing only input and display module in application as per the new HMI design.
In one embodiment, any authoring tool can be used for the development for the HMI graphics and animation. The authoring tool facilitates the code generation for different platforms. allowing the use of same developed HMI on different hardware platforms.
In another aspect of the disclosure, a method of communication among the applications present in the infotainment system is disclosed.
Fig. 6 and 7 diagrammatically illustrates the message format of a single and a multi-frame message transmitted on the CAN bus.

The infotainment system applications includes but not limiting to AMFM application, media player (CD, DVD, and USB) application, bluetooth application, and navigation application wherein the applications reside in the ECU node of the infotainment system. The ECU nodes communicate over the CAN communication bus. The infotainment application communicates with each other by sending the messages.
In one embodiment, the application layer defines the DATA field of the standard CAN message format. The standard CAN message format is:

SOF MID RTR CONTROL DATA CRC ACK EOF
Where, SOF is Start of the Frame. MID is Message Identifier which is either II or 29 bits long depending on the chosen mode. RTR is Remote Transmission Request, RTR = 0; which is DOMINANT in data frame; RTR = 1; which is RECESSIVE in remote frame. CONTROL field specifies the number of bytes of data to follow (0-8). DATA is Data Field; CRC field contains a fifteen bit cyclic redundancy check code. ACK is Acknowledge field an empty slot which will be filled by the receiving node on successful reception. EOF is End of Frame.
In one embodiment, Fig.8 shows principle structure of the infotainment system protocol in the application layer.
The maximum data length of DATA field is 256 bytes. The application layer defines the DATA field of the standard CAN message format in which a message on the CAN serial bus contains 8 bytes at a time which is a single frame message. If the message contains longer than 8 bytes then the protocol will be divided into several CAN messages and then sent to the infotainment bus (CAN) which is a multi-frame message.
Message Transmission ID byte stands for a CAN message Id in the network (shall be a length of 8 bits). It precedes the protocol and does not need to be interpreted on the application level. If an application receives a protocol, the message Transmission ID contains the logical node communication address of the sender to receiver. The infotainment system uses fixed message

Transmission ID in the communication network which are not allocated upon start-up. This is to ensure a quick infotainment initialization and communication process.
Message segment information byte indicates whether the message sent by an application to another application in the infotainment system is a single frame message or a multi-frame message. If the message is single frame then Segment Information (SI) an upper nibble which takes 4 bits will be 0 or else it will be 1. SF_DL a lower nibble takes 4 bits which indicates the number of bytes in the message if message is single frame message. Data length byte indicates the length of the data bytes in a multi-frame message and Block counter byte indicates the frame number of the multi-frame message. Source application block ID byte indicates the application block ID of the message sender. Application block ID is the identifier of a special application block within each block. Every application block with a certain application block ID shall contain certain specific operation, application block ID is a length of 8 bits. Destination application Block ID byte contains the application block ID of the message receiver.
Source_Destination_Instance ID byte indicates the instance of source and destination application software module. An infotainment application can have several variants like an AMP application with or without head phone socket. These variants will be dictated by vehicle program management. Therefore in order to address the several variants, application block ID shall be complemented with Instance ID which is a 4 bit length number. Applications in the infotainment system are uniquely identified with application block ID.
Instance ID byte address several variants of the infotainment system. There may be a case where an infotainment block has several variants e.g. amplifier application may be with or without head phone socket. These variants will be dictated by vehicle program management. Therefore in order to address the several variants, application block ID is complemented with instance identification which is a 4 bit length number. Any infotainment shall be flexible enough to communicate with any application block ID with any instance ID. If there is no variant existing for a node, then default instance ID will be 0x01.
FunctionCommandCode byte represents the function that needs to be carried out by an infotainment application like Scan (), Seek CD Track Up (), Load CD Disc () can be defined as

an operation. OperationType byte indicates the operation that needs to be performed for given FunctionCommandCode like Get, Set, result, Error. Parameters byte indicates the data bytes to be transmitted from the sender to the receiver application software module. Operation type error is reported only to the application manger that has sent the instruction. On error, an error code shall be reported in the DATA field (DATA [0]). Additional information, if any shall be reported in the DATA field area as well i.e. DATA [0]. Errors are only transmitted to the application manager from slave. Once an error is reported by the slave node, application manager shall process and take the system to a defined state.
Fig. 9 is an exemplary block diagram which illustrates communication among application modules in the infotainment system.
In an embodiment, for example, the applications APP 1, APp 2 and APP3 residing at ECU 1 wants to send MSG1, MSG2 and MSG3 to the applications APp 1 APP2 APP3 residing at ECU 3 respectively and application APP4, APP5, APP6 residing at ECU 2 wants to send the MSG4, MSG5 and MSG6 to the APP4, APP5, APP6 residing at ECU 3 respectively.
In order to carry out aforesaid message transmission, the Application layer registers the application modules like APP1, APP2, APP3 APP4, APP5, and APP6 of ECU1 and ECU2 with the transport layer for the communication of the messages in the infotainment system. Each application will specify the priority at which the message has to be transmitted. Each ECU node will-have two buffers for the message transmission, one for high priority and one for low priority messages. Transport layer will send the high priority messagges followed by the low priority messages on the communication bus. All the messages with low priority will be sent with message identifier OxXXXX and high priority messages wil| be sent with message identifier OxYYYY. The Broadcast messages which go to all application modules in the infotainment system will be sent with message identifier OxZZZZ. The communicating applications like APP1, APP2, APP3, APP4, APP5, APP6 residing at ECU 3 which intend to receive the messages should register their message reception buffers along with the expected message identifiers, Application block ID, and instance ID with the transport layer.
In one embodiment, when the messages MSG1, MSG2, MSG3; MSG4, MSG5. MSG6. are received from the application for transmitting, transport layer will check if the communicating

applications APP1, APP2, APP3, APP4, APP5, APP6 residing at ECU 3 which intends to receive the messages is present in the registry. If the entry for the intended recipient is found in the registry then it copies the message to the reception buffer for that intended recipient. If the intended recipient is not found in the registry then the transport layer will transmit the message on the communication bus along with the appropriate Message identifier as per the priority of the message which is specified by the communicating application.
In one embodiment, when the message is received from the application for transmitting, transport layer will check if the intended recipient's application block ID is OxFF and instance ID is OxF. If so, then the transport layer will copy this message in all the reception buffers mentioned in the registry, where the priority matches with the priority specified by the communication. When the transport layer receives the message from the communication bus, it checks for the application block ID and the instance ID in the message for the target application. If the target application resides in the same ECU node as of the transmitter application, then the message is routed internally to the corresponding target application. If the target application is residing in a different ECU node of the infotainment system, then CAN message ID of the destination node is attached with the message and transmitted on the CAN network. Hence the CAN ID 0x102 is attached with the MSG1 for the destination node ECU 3 and CAN ID 0x103 is attached with MSG4 for the destination node ECU3.
The foregoing description of the embodiments of the disclosure has been presented for the purpose of illustration; it is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Persons skilled in the relevant art can appreciate that many modifications and variations are possible in light of the above disclosure.
Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

We claim:
1. An architecture for infotainment system, comprising:
an information input manager module configured to receive and process inputs from user through Human Machine Interface (HMI) and to forward the inputs as commands to respective application manager module;
the application manager module configured to forward the commands to respective application slave module for execution, wherein the application slave module executes the commands and reports to the user through the HMI;
an application display view module associated with the HMI being adopted to display information based on state change of the application;
a resource master module configured to allocate resources for active applications in the infotainment system;
a power master module configured to provide overall power management; and
a network master module configured to manage information of the application slave module, about their current application status.
2. The architecture as claimed in claim J, wherein the HMI is selected from a group comprising High Line Display Front (HLDF) interface, touch screen interface and Integrated Control Panel (ICP) interface.
3. The architecture as claimed in claim 1, wherein the applications residing in the ECU node communicate over Communication Area Network (CAN) communication bus, said applications are selected from a group comprising AMFM application, media player application, Navigation application and Bluetooth application.
4. The architecture as claimed in claim 1, wherein the application manager module are selected from a group comprising AMFM application manager module, media player application manager module, Bluetooth Phone Module (BPM) application manager module and Navigation application manager module.

5. The architecture as claimed in claim 1, wherein the application slave module are selected from a group comprising AMFM slave which communicates with the AMFM application manager module through AMFM interface for tuner functionality, media player slave which communicates with the media player application manager module through at least one of CD interface, DVD interface, USB interface, and AUX interface for providing media functionality, BPM slave which communicates with the BPM application manager module through BPM interface for Bluetooth functionality, and navigation slave which communicates with the navigation application manager module through navigation interface for integrating navigation in the infotainment system.
6. The architecture as claimed in claim 1, wherein the power management functions are selected from a group comprising voltage monitoring, initialization and shut down of the infotainment system.
7. The architecture as claimed in claim 1 further comprises
an entertainment manager module configured to activate and deactivate application on request from the user, wherein the entertainment manager module keeps track of the current active application;
an audio and general application display view module configured to maintain common data of all the application display view modules;
plurality of drivers selected from at least one of Inter Integrated Circuit (I2C), Universal Asynchronous Receiver/Transmitter (UART), General Purpose Input/output (GPIO) and Communication Area network (CAN) configured to communicate with the applications of the infotainment system; and
an OS scheduler configured to perform task scheduling for each of the application in the infotainment system.
8. A method of communication between plurality of applications in an infotainment system
comprising acts of:
sending messages from the application present in ECU node of the infotainment system to a transport layer, wherein the transport layer checks for application block ID and instance ID attached with the messages;

transmitting the messages to recipient application present in the same ECU node as the sender application by the transport layer, when the recipient application is present in the same ECU node as the sender application; and
transmitting the messages on Communication Area Network (CAN) by appending CAN message ID by the transport layer, when the recipient application resides on different ECU node other than the sender ECU node.
9. The method as claimed in claim 8, wherein the transport layer of each of the ECU node has list of message identifiers for transmitting the messages on the CAN.
10. The method as claimed in claim 8, wherein the applications intending to receive messages registers their message reception buffers along with the message identifiers, application block ID. instance ID, and message priority with the transport layer.
11. Architecture for infotainment system, a method of communication among applications in the infotainment system as described above in the accompanying drawings.