CN109474912B

CN109474912B - Vehicle-mounted gateway system and monitoring method and device of vehicle-mounted subsystem

Info

Publication number: CN109474912B
Application number: CN201810315454.6A
Authority: CN
Inventors: 徐匡一
Original assignee: Southwest University
Current assignee: Southwest University
Priority date: 2018-04-10
Filing date: 2018-04-10
Publication date: 2022-02-18
Anticipated expiration: 2038-04-10
Also published as: CN109474912A

Abstract

The application discloses a vehicle-mounted gateway system and a monitoring method and device of vehicle-mounted subsystems. The vehicle-mounted gateway system includes: a central controller and a switching fabric; the central controller is configured to: enabling the third vehicle-mounted subsystem to use the resources of the first vehicle-mounted subsystem; and enabling the third onboard subsystem to use data from the second onboard subsystem; the switch fabric is configured to: the central controller is interconnected with the plurality of on-board subsystems and communicates at least a unified control command to at least one of the plurality of on-board subsystems. Therefore, a central control system framework surrounding various subsystems is constructed, unified management of the vehicle-mounted subsystems is realized, and the problem that the vehicle-mounted system is difficult to control, manage, maintain and upgrade at present is solved.

Description

Vehicle-mounted gateway system and monitoring method and device of vehicle-mounted subsystem

Technical Field

This application claims priority from a foreign application entitled "apparatus and method for monitoring and controlling an onboard gateway system for an onboard subsystem" filed by the U.S. patent and trademark office, application number US15/478, 248, 11/4/2017, which is incorporated herein by reference in its entirety.

Background

Just as mobile phones have become personal information centers no longer just ordinary communication devices, the in-vehicle electronic devices will also become information platforms that include Advanced Driver Assistance Systems (ADAS), navigation, communication and entertainment. However, this fundamental transition requires a technical architecture that relies on the modification and redesign of the onboard system, which is otherwise not able to support the above-described functionality with existing technical architectures.

Currently, the ADAS, communication and entertainment systems of a vehicle are typically found in isolation in separate devices and subsystems, and each is built separately without consideration of the other subsystems, which results in duplication of functionality, increased cost, and difficulty in controlling, managing, maintaining, and upgrading the entire on-board system. Accordingly, there is a need to reconstruct the corresponding central control system architecture around the system including ADAS, navigation, communications and entertainment, and on-board gateways.

Disclosure of Invention

In view of this, the present application provides a vehicle-mounted gateway system, and a monitoring method and apparatus for a vehicle-mounted subsystem, which are used to perform unified management on the vehicle-mounted subsystem, so as to solve the problem that the vehicle-mounted system is difficult to control, manage, maintain and upgrade at present.

In order to achieve the above object, the following solutions are proposed:

an in-vehicle gateway system for monitoring and controlling a plurality of in-vehicle subsystems within a vehicle, the plurality of in-vehicle subsystems including at least a first, a second and a third in-vehicle subsystem, the in-vehicle gateway system comprising:

a central controller and a switching fabric;

the central controller is configured to:

enabling the third vehicle-mounted subsystem to use resources of the first vehicle-mounted subsystem;

and enabling the third on-board subsystem to use data from the second vehicle-mounted subsystem;

the switch fabric is configured to:

interconnecting the central controller with the plurality of on-board subsystems and communicating at least a unified control command to at least one of the plurality of on-board subsystems.

Optionally, further comprising a plurality of optional external connectors, wherein:

the external connector is used to support the addition of new onboard subsystems and associated equipment;

one of the plurality of onboard subsystems includes a set of associated onboard devices and an interface between the central controller and the set of associated onboard devices, and the third onboard subsystem is a newly added onboard subsystem.

Optionally, the central controller is configured to:

generating and issuing a unified control command to monitor or control at least one of the plurality of on-board subsystems, the unified control command comprising a control command structure common to the plurality of on-board subsystems;

and filtering, fusing, and combining multiple types of pre-processed or post-processed data from the plurality of on-board subsystems, the pre-processed or post-processed data including data from a plurality of sensors.

Optionally, the plurality of vehicle-mounted subsystems include a networking subsystem, an infotainment subsystem, an advanced driver assistance and navigation subsystem, an internet of things subsystem, a sensor gateway subsystem, a communication and security subsystem, an information technology peripheral subsystem, and a storage subsystem, wherein:

the plurality of vehicle-mounted devices comprise vehicle-to-vehicle LTE, direct short-range communication devices and sensors;

the sensors at least comprise radar, laser radar, camera, ultrasonic sensor and infrared sensor.

Optionally, each of the plurality of onboard subsystems is configured to:

converting a local data format of the on-board subsystem to a common data format to cause data to be transmitted to the central controller, or other on-board subsystems of the plurality of on-board subsystems;

and converting the common data format or the unified control command into the local data format or the local control command format to cause the data or the unified control command to be transmitted to one or more vehicle-mounted devices.

Optionally, the method further includes:

a drive train controller comprising at least one of an Ethernet-T1 interface, an Ethernet interface, and a local interface and configured to control one of a gasoline vehicle, an electric vehicle, and a hybrid vehicle via control commands from the central controller or from an authorized mobile device;

wherein the central controller further comprises:

a touch screen for a driver to input control commands and display information from the plurality of in-vehicle subsystems;

a policy-based decision module configured to generate the unified control command based on a predefined policy and a plurality of input data from one or more sensors.

Optionally, the switch fabric includes one or more of a CAN data bus, a CAN-FD data bus, a LIN data bus, an ethernet, an AVB data bus, a low latency ethernet, and a pair of ethernets.

Optionally, the switching fabric in a one-to-one active and standby redundancy configuration is configured to monitor link states of the switching fabric and associated communication links and initiate a handover once the switching fabric identifies a fault condition in one of the active switching units or the associated communication links of the switching fabric.

Optionally, the system further includes a virtualization module, wherein:

the virtualization module is configured to represent an in-vehicle device as a virtual entity and provide a set of services to the central controller and the plurality of in-vehicle subsystems;

the set of services includes data services, configuration services, management services, diagnostic services, security services, and cloud services.

Optionally, the data service includes:

storing and forwarding telemetry data collected by at least one or more on-board devices;

publishing the telemetry data to a remote server;

and parsing and encapsulating the telemetry data into ethernet packets to be transmitted to the central controller and one of the plurality of on-board subsystems.

Optionally, the configuration service includes a management configuration file;

the cloud service comprises communicating with a remote cloud server and publishing or subscribing to requests from or responses to a remote resource management entity;

the management service includes deploying, upgrading, and configuring software components of the plurality of in-vehicle subsystems based at least in part on the cloud service and the configuration service;

the diagnostic service includes verifying hardware connections and software features of the vehicle gateway system, the software features including database operation verification and cloud server event verification;

the security services include providing protection against hacking, theft, DDoS, and counterfeiting, message encryption and authentication for secure connections, and support for pseudonym stacks for privacy protection.

A monitoring method of a vehicle-mounted subsystem is applied to the vehicle-mounted gateway system, and comprises the following steps:

enabling a third of the plurality of on-board subsystems to use resources of a first of the plurality of on-board subsystems;

enabling the third of the plurality of on-board subsystems to use data generated by a second of the plurality of on-board subsystems, wherein the third of the plurality of on-board subsystems is a newly added on-board subsystem;

generating, by a central controller, a unified control command in response to an input from a driver of the vehicle or an event from one of the plurality of on-board subsystems to monitor or control at least one of the plurality of on-board subsystems based on a predefined policy and a plurality of input data from one or more of the plurality of on-board subsystems;

and transmitting the unified control command over one of the associated communication links using a switching fabric.

Optionally, the method further comprises the step of

Converting the local data format of the plurality of on-board subsystems to a common data format to cause data to be sent to the central controller or other of the plurality of on-board subsystems;

and converting the common data format to the local data format or converting the unified control command to a local control command format to be transmitted to one or more in-vehicle devices.

Optionally, the generating, by the central controller, the unified control command further includes:

generating a control command structure common to the plurality of onboard subsystems to encapsulate the unified control command on a common communication bus.

Optionally, the method further comprises the steps of:

monitoring link states of the switch fabric and associated communication links;

and initiating a switch from an active switching unit to a standby switching unit of the switching fabric when the central controller identifies a fault condition in the active switching unit or one of the associated communication links, wherein the switching fabric includes one or more of a CAN data bus, a LIN data bus, a CAN-FD data bus, an ethernet, a low latency ethernet, an AVB data bus, and a pair of ethernet networks.

Optionally, the method further comprises the steps of:

partially executing, by a software virtualization module representing a plurality of in-vehicle devices, one of a plurality of services to execute the unified control command, the plurality of services including a data service, a configuration service, a management service, a diagnostic service, a security service, and a cloud service;

the data services include storing and forwarding telemetry data collected by at least one of the plurality of on-board subsystems, publishing the telemetry data to a remote server, and parsing and encapsulating the telemetry data or collected sensor data into ethernet packets to be transmitted to at least one of the central controller and one of the plurality of on-board subsystems;

the configuration service comprises a management configuration file; the cloud service includes communicating with a remote cloud server and publishing/subscribing to requests/responses to a remote resource management entity;

the management service includes deploying, upgrading, and configuring software components of the plurality of onboard subsystems using at least the cloud service and the configuration service;

also, the security services include providing protection against hacking, theft and forgery, message encryption and authentication for secure connections, and support for a pseudonym stack for privacy protection.

Optionally, the method further comprises the steps of:

employing the on-board subsystem using an optional connector of the plurality of optional connectors without changing the plurality of on-board subsystems.

Optionally, the method further comprises the steps of:

receiving the unified control command from the driver of the vehicle via a touch screen and/or a microphone;

and displaying and/or playing notifications and responses from one of the plurality of in-vehicle subsystems on the touch screen and/or voice speaker.

A monitoring device of an in-vehicle subsystem, which is applied to the in-vehicle gateway system, the monitoring device comprises:

a memory;

and at least one processor coupled to the memory and configured to:

enabling the third of the plurality of on-board subsystems to use data from a second of the plurality of on-board subsystems, wherein the third of the plurality of on-board subsystems is a newly added on-board subsystem; and

generating, by a central controller, a unified control command to monitor or control at least one of the plurality of onboard subsystems in response to an input from a driver of the vehicle or an event from one of the plurality of onboard subsystems, wherein the unified control command is communicated over one of the associated communication links using a switching fabric.

Optionally, the at least one processor is further configured to:

converting a local data format of one of the plurality of on-board subsystems to a common data format to cause data to be transmitted to the central controller or other of the plurality of on-board subsystems;

and converting the common data format into the local data format or converting the unified control command into a local control command format to be sent to the vehicle-mounted subsystem.

From the above technical solutions, the present application discloses a vehicle-mounted gateway system and a monitoring method and device for vehicle-mounted subsystems, where a plurality of vehicle-mounted subsystems at least include a first vehicle-mounted subsystem, a second vehicle-mounted subsystem and a third vehicle-mounted subsystem. The vehicle-mounted gateway system includes: a central controller and a switching fabric; the central controller is configured to: enabling the third vehicle-mounted subsystem to use the resources of the first vehicle-mounted subsystem; and enabling the third onboard subsystem to use data from the second onboard subsystem; the switch fabric is configured to: the central controller is interconnected with the plurality of on-board subsystems and communicates at least a unified control command to at least one of the plurality of on-board subsystems. Therefore, a central control system framework surrounding various subsystems is constructed, unified management of the vehicle-mounted subsystems is realized, and the problem that the vehicle-mounted system is difficult to control, manage, maintain and upgrade at present is solved.

Drawings

In order to more clearly illustrate the embodiments of the present application or the technical solutions in the prior art, the drawings used in the description of the embodiments or the prior art will be briefly described below, it is obvious that the drawings in the following description are only some embodiments of the present application, and for those skilled in the art, other drawings can be obtained according to the drawings without creative efforts.

FIG. 1 provides a block diagram of a functional diagram of an example in-vehicle gateway system, according to one aspect of the present disclosure;

FIG. 2 provides a block diagram of a hardware architecture diagram of an example in-vehicle gateway system, according to one aspect of the present disclosure;

FIG. 3 provides a perspective view of a software architecture of an in-vehicle gateway system according to one aspect of the present disclosure;

FIG. 4 provides a block diagram illustrating a method for monitoring and controlling an onboard subsystem in accordance with an aspect of the present disclosure.

FIG. 5a provides a block diagram illustrating another method for monitoring and controlling an onboard subsystem in accordance with an aspect of the present disclosure;

FIG. 5b provides a block diagram illustrating a method for monitoring switch fabrics and communication links and employing new subsystems, according to one aspect of the present disclosure;

FIG. 6 provides a block diagram illustrating a process of sensor data transmission in an in-vehicle gateway system according to one aspect of the present disclosure;

FIG. 7 provides a block diagram illustrating a process of sensor data transmission using a custom bus in an in-vehicle gateway system according to one aspect of the present disclosure;

FIG. 8 provides a block diagram illustrating a process of interaction between an in-vehicle gateway system and an external cloud server according to one aspect of the present disclosure;

FIG. 9 provides a block diagram illustrating a process of an example of an application of an in-vehicle gateway system based automated parking according to one aspect of the present disclosure.

Detailed Description

The detailed description set forth below in connection with the appended drawings is intended as a description of various configurations and is not intended to represent the only configurations in which the concepts described herein may be practiced. The detailed description includes specific details for the purpose of providing a thorough understanding of various concepts. It will be apparent, however, to one skilled in the art that these concepts may be practiced without these specific details. In some instances, well-known structures and components are shown in block diagram form in order to avoid obscuring such concepts.

Fig. 1 provides a block diagram of a functional diagram of an in-vehicle gateway system 100 in accordance with an aspect of the present disclosure.

As described below, since the in-vehicle gateway system 100 can connect the vehicle with the internet, the in-vehicle gateway system 100 is also referred to as an in-vehicle networking (IoV) gateway system.

The in-vehicle gateway system 100 may include many in-vehicle subsystems. According to an example embodiment, the in-vehicle gateway system 100 may include a networking subsystem 102, a communication and security subsystem 103, and an entertainment subsystem 104. The in-vehicle gateway system 100 may also include an Advanced Driver Assistance System (ADAS) and navigation subsystem 105, a storage subsystem 106, an IT peripherals subsystem 107, and an internet of things (IoT) and sensor gateway subsystem 109. In general, a subsystem may include a set of in-vehicle devices and interfaces that associate the in-vehicle devices with an in-vehicle gateway system and other subsystems. At the center of the in-vehicle gateway system 100 is a central controller and switching fabric 110 and a drive train controller 108.

The networking subsystem 102 provides an interface to and communicates with a communication network, such as a 3G/4G/5G wireless network, a WiFi local area network, a long term evolution vehicle-mounted (LTE-V) network, or a local ethernet network. The in-vehicle gateway system 100 may be connected to external networks and possibly other vehicles through the networking subsystem 102. The communication and security subsystem 103 may manage firewall, VPN related functions for security of the in-vehicle gateway system. Entertainment subsystem 104 may provide an interface to video/audio games and other entertainment-related onboard or external subsystems. The ADAS and navigation subsystem 105 provides an interface to various ADAS devices such as sensors, including but not limited to cameras, radar, GPS, and laser-based radar (lidar) sensors.

The storage subsystem 106 includes various internal or external storage systems, such as Solid State Device (SSD) memory storage devices, hard disk drives, or other storage devices within the vehicle. Storage subsystem 106 provides an interface for the in-vehicle gateway system and other subsystems to access the storage device. The IT peripheral subsystem 107 provides an interface to device IT peripherals such as Liquid Crystal Display (LCD) devices, speakers, microphones, or other input-output IT within the vehicle. An internet of things (IoT) and sensor gateway subsystem 109 provides an interface to internet-connected devices and sensors. The interface may be a bluetooth network, CAN data bus, or other personal area network within the vehicle, such as one or more of CAN-FD data bus, LIN data bus, and AVB data bus, low latency ethernet, and a pair of ethernet (ethernet-T1).

The powertrain controller 108 provides an interface to the conventional control system of the vehicle. A conventional control system of a vehicle may include a plurality of Electronic Control Units (ECUs). In one example, the powertrain controller 108 may perform recommendations for mission critical ECUs in conjunction with strategies, road environments, and images from the ADAS subsystem. For example, when the central controller 110 determines that a fault condition has occurred in the ADAS device, the powertrain controller 108 may return the vehicle to the driver's "manual" control to take over operation of the vehicle.

The above-described subsystems provide interfaces to various in-vehicle devices and components included in the subsystems. In this manner, the subsystem may convert the local data format of the onboard subsystem to a common data format to allow data to be sent to a central controller or other onboard subsystem, or other onboard control subsystem of the plurality of onboard subsystems. The subsystem may also convert the common data format or unified control command to a local data format or a local control command format to cause the data to be transmitted to one or more in-vehicle devices.

The central controller 110 may generate and issue unified control commands to monitor or control the onboard subsystems. The unified control command is based on a control command structure common to all of the onboard subsystems. The central controller 110 may also filter, fuse, and combine various types of pre-processed or post-processed data from the onboard subsystems described above, including data from multiple sensors.

The central controller 110 may provide a unified solution of control, management, and supervision among the subsystems. In this manner, the central controller 110 enables sharing of resources among the aforementioned subsystems. For example, a new application or in-vehicle subsystem may use the resources of an existing subsystem or application, rather than deploying a new set of resources. In addition, the central controller 110 may enable the new application to use data generated by the existing onboard subsystems, rather than having the new application generate its own data.

The switch fabric 110 may interconnect the central controller with the onboard subsystems and communicate unified control commands to the onboard subsystems. In one example configuration, the switch fabric 110 may be a low latency ethernet switch fabric connected between the central controller 110 and the ADAS subsystem. The ethernet switch fabric may be in a dual star topology with 1+1 active redundancy and standby redundancy. The switch fabric management software monitors the internal status and link status of each switching unit and initiates a handoff once the central controller 110 identifies a significant failure in the active switching unit or its associated link. For backward compatibility, the switch fabric may also be used as a Controller Area Network (CAN)/flexible data rate (CAN-FD) bridge for instrument panels and head-up displays.

As can be seen from the above technical solutions, the present embodiment provides an on-vehicle gateway system for monitoring and controlling a plurality of on-vehicle subsystems in a vehicle, where the plurality of on-vehicle subsystems at least include a first on-vehicle subsystem, a second on-vehicle subsystem, and a third on-vehicle subsystem. The vehicle-mounted gateway system includes: a central controller and a switching fabric; the central controller is configured to: enabling the third vehicle-mounted subsystem to use the resources of the first vehicle-mounted subsystem; and enabling the third onboard subsystem to use data from the second onboard subsystem; the switch fabric is configured to: the central controller is interconnected with the plurality of on-board subsystems and communicates at least a unified control command to at least one of the plurality of on-board subsystems. Therefore, a central control system framework surrounding various subsystems is constructed, unified management of the vehicle-mounted subsystems is realized, and the problem that the vehicle-mounted system is difficult to control, manage, maintain and upgrade at present is solved.

There are several advantages associated with the in-vehicle gateway system 100. Example effects of the in-vehicle gateway system 100 may include maximized functionality and flexibility, scalability, high availability, low latency, ease of separating hardware/software/applications, and ease of designing, developing, upgrading, and replacing hardware and software within a vehicle.

Fig. 2 provides a block diagram of an example hardware architecture diagram or configuration 200 of the in-vehicle gateway system 100 in accordance with an aspect of the present disclosure.

Hardware configuration 200 illustrates one possible hardware configuration of in-vehicle subsystem 100 of FIG. 1. Hardware configuration 200 includes infotainment subsystem 210, central controller 220, multi-protocol switching fabric 230, drive train controller 250, and ADAS subsystem 240.

In one example configuration, the infotainment subsystem 210, together with various connected devices, may implement the entertainment subsystem 104, networking subsystem 102, IT peripheral subsystem 107, and communication and security subsystem 103 of FIG. 1. In one example configuration, infotainment subsystem 210 may have a single central processing unit or CPU shared among the aforementioned subsystems. In another configuration, the subsystems described above may be housed in a single physical unit. In an alternative configuration, each subsystem may have its own CPU in addition to the central CPU to facilitate local data processing.

Infotainment subsystem 210 may be connected to various devices found in vehicles today. For example, the infotainment subsystem 210 may connect to an LTE/3G compatible wireless network 201, a WiFi/Bluetooth network 202, a GPS device 203a, a touch LCD device 204a, a rear seat LCD device 204b, an FM or XM radio and CD player with USB connector 205, and an audio device 208. The infotainment subsystem 210 may be connected to the device via a wireless link, such as a WiFi connection, or a wired connection.

The infotainment subsystem 210 may be connected to the central controller 220 and the drive train controller 250 via a multi-protocol switching fabric 230 and an internal ethernet link. In addition to or instead of an ethernet connection, the infotainment subsystem 210 may be connected to the central controller 220 via a wireless link.

In one example configuration, central controller 220 and multi-protocol switch fabric 230, along with various connected devices, may provide an implementation of central controller and switch fabric 110 of fig. 1. The central controller 220 may be connected to a heads-up display 222 and a solid state drive device (SSD) 221. The powertrain controller 250 provides an implementation of the powertrain controller 108 of fig. 1. The central controller 220, together with the multi-protocol switching fabric 230, may provide a unified solution of control, management, and supervision between the infotainment subsystem 210 and the ADAS subsystem 240. The powertrain controller 250 may perform various vehicle control, monitoring, and supervisory functions. Thus, the powertrain controller 250 interfaces with various vehicle components, including the vehicle engine 225, the vehicle transmission 227, the vehicle braking system 229, and the vehicle steering system 231. Other components of the vehicle that interface with the powertrain controller 250 may include a door system 224, a window system 226, an HVAC system 228, an instrument cluster 223, and an on-board diagnostics OBD 233. The connections to the vehicle components include a plurality of Electronic Control Units (ECUs), an ethernet/audio video bridge AVB, a CAN data bus or a CAN-FD data bus.

The ADAS process 240, along with various sensors and navigation devices, may implement the ADAS/navigation subsystem 108 of fig. 1. The sensors and navigation devices may include a camera 207b, a radar/lidar 242, a plurality of sensors 246, and a GPS receiver 203 b. The plurality of sensors 246 may include gyroscopes, ultrasonic sensors, infrared sensors, and the like. In one configuration, an optional expansion slot may accommodate multiple Video Processing Units (VPUs), such as VPU 248a and VPU 248b, to facilitate processing video data from multiple cameras and sensors. The expansion card 251 may accommodate additional devices or processors as needed.

The ADAS process 240 provides a platform for driver assistance functions and associated equipment within the vehicle. In one example configuration, the ADAS process 240 has its dedicated processor or processors, in part because the ADAS process 240 can process large amounts of data to accommodate applications such as autopilot driving.

The example hardware configuration 200 may include the same or similar types of devices in different portions of the example in-vehicle gateway system. For example, camera 207a is used in infotainment system 210 and camera 207b is associated with ADAS process 240. Similarly, LCD 204a and rear seat LCD 204b are associated with infotainment system 210, touch LCD 204c is associated with ADAS process 240, and touch LCD 204d is associated with drive train controller 250.

Fig. 3 provides a block diagram of a service architecture 300 for an in-vehicle gateway system, according to one aspect of the present disclosure.

According to an example aspect of the present disclosure, an in-vehicle gateway system may abstract hardware resources and general software modules into service modules. The service architecture 300 virtualizes various in-vehicle gateway system functions to reduce the cost and complexity of the development of various new in-vehicle gateway applications.

In one example configuration, the in-vehicle gateway service architecture 300 may include a device abstraction layer 320, the device abstraction layer 320 representing various physical in-vehicle devices as virtual entities that provide various services to in-vehicle gateway systems, such as the in-vehicle gateway system 100 and the in-vehicle gateway system 200. Example physical in-vehicle devices may include a WiFi device 321, a USB device 323, an inter-Integrated Circuit communication (I)²C) And a Serial Peripheral Interface (SPI) device 324, a Global Positioning System (GPS) device 325, a general purpose input/output (GPIO) port device 326, and a Controller Area Network (CAN)/Local Interconnect Network (LIN)/modbus device (327). The physical devices share a common Operating System (OS), such as a Linux OS. Based on the virtual entity or virtual device, device abstraction layer 320 provides a set of services based on the services provided by the underlying physical in-vehicle device.

The various services provided by the in-vehicle gateway services architecture 300 may include a management service 301, a cloud service 303, a data service 305, a configuration service 307, a diagnostic service 308, and a security service 309. The onboard gateway service architecture 300 provides services to various onboard subsystems and applications via an onboard gateway service Application Program Interface (API) 310.

The management service 301 is used to manage the in-vehicle gateway system, including deployment, upgrade, and configuration services. For remote configuration and management, the management service 301 relies on cloud services 303 and configuration services 307. The management service 301 provides a mode selection option to the management service API to enable the service client to select either local management or remote management.

The cloud service 303 is used by the onboard subsystem or application to communicate with the remote cloud server. In addition to simple publish/subscribe services, the cloud service 303 also provides cloud service APIs to simplify frequently complex interaction processes such as requests/responses or remote resource management. Cloud services are also used by applications or onboard subsystems to communicate with remote cloud servers. In addition to simple publish/subscribe, cloud services APIs simplify the implementation of more complex interaction flows such as request/response or remote resource management. An example of a cloud service 303 is shown and described in fig. 8.

The data service 305 provides the ability to store and forward telemetry data, such as collected by various onboard devices, and distribute the data to various onboard subsystems or applications. The data service 305 also supports data filtering functions. Examples of data services 305 and their interaction with other services are shown and described in fig. 6 and 7.

The configuration service 307 includes an interface management and profile management module. Configuration service 307 may provide interface management modules to handle I from different buses, e.g., VCG/ADAS interface²C. SPI, GPIO, custom bus, etc. The configuration service 307 may also convert different data formats to a unified data format for the data service 305. The configuration file management module is used for saving/restoring/updating configuration files, such as gateway network configuration files, database configuration files, data service configuration files and the like.

The diagnostic service 308 may include an on-board gateway diagnostic module and a vehicle diagnostic module. The on-board gateway diagnostic module may verify basic hardware connections of the on-board gateway system, e.g., Ethernet, I²C. GPIO, USB, CAN, etc. The on-board gateway diagnostic module may verify the software features,such as database operation validation, cloud server event validation, and the like. The vehicle diagnostic module may check the state of the vehicle from various ECUs.

The security service 309 may provide protection against hacking, theft, and counterfeiting of components. The security service 309 may implement a message encryption and authentication stack for secure connections. The security service 309 also supports a pseudonym stack for privacy protection to avoid tracing. All processors within the onboard gateway system implement a secure boot so that only known approval code runs.

FIG. 4 provides a block diagram of a method 400 for an in-vehicle gateway system to control and monitor various in-vehicle subsystems of a vehicle, according to one aspect of the present disclosure.

The method 400 may include, at 402, enabling a third of the plurality of vehicle-mounted subsystems to use resources of a first of the plurality of vehicle-mounted subsystems. The method 400 may also include enabling a third of the plurality of on-board subsystems to use data from a second of the plurality of on-board subsystems at 404. The method 400 further includes interconnecting the central controller with a plurality of onboard subsystems at 406, generating unified control commands by the central controller at 408, and transmitting the unified control commands to one of the onboard subsystems at 410.

The step of enabling the third vehicle-mounted subsystem to use the resources of the first vehicle-mounted subsystem at 402 may include sharing resources originally specified for one subsystem or application. In one example configuration, the new application/subsystem may share resources of the existing subsystem, even if the existing subsystem and the new subsystem are from two different vendors, rather than adding the entire set of new hardware and software resources for the new application/subsystem. Resource sharing is implemented at least in part by a central controller that provides a unified control command structure that is common to all subsystems. Resource sharing is possible also because the software virtualization module abstracts vendor specific hardware into a common service and provides that service to new subsystems/applications.

The step of enabling a third of the plurality of on-board subsystems to use data from a second of the plurality of on-board subsystems at 404 may include sharing data originally specified for a subsystem or application. In one example configuration, the new application/subsystem may share data generated by and for the existing subsystem, even if the existing subsystem and the new subsystem are from two different vendors, rather than adding an entire set of new hardware and software to generate data for the new application/subsystem. Data sharing is at least partially implemented by a central controller that provides a unified control command structure that is common to all subsystems. Data sharing is possible also because the software virtualization module abstracts vendor specific hardware into a common service and provides that service to new subsystems/applications.

Interconnecting the central controller with the plurality of onboard subsystems at 406 includes connecting the central controller to the plurality of onboard subsystems using a switching fabric. The switching fabric may include one or more of a CAN data bus, a LIN data bus, and a CAN-FD data bus, an ethernet, a low latency ethernet, and a pair of ethernet (ethernet-T1) switching fabrics.

The step of generating a unified control command by the central controller at 408 may include generating a control command structure common to the plurality of onboard subsystems. That is, the command structure is recognized and accepted by each onboard subsystem. One example of such a command structure is an instruction based on the standard ethernet frame structure. The unified control command may be generated in response to an input from a driver of the vehicle or an event from one of the on-board subsystems. For example, when the driver issues a left turn command, the central controller generates a unified control command and sends the command to the driveline control subsystem to make the left turn. As another example, when the ADAS subsystem reports that an object on the road is detected by a camera or other sensor, the central controller also generates unified control commands to the drive train subsystem and the ADAS subsystem to turn around the object.

Transmitting the unified control command at 410 may include transmitting the unified control command over one or more communication links. An example of such a communication link is an ethernet link.

The method 400 of fig. 4 illustrates an example process for an on-board gateway system to control and monitor an on-board subsystem.

The steps and the order of the steps of the method 400 are for illustrative purposes. Some steps may be combined or skipped. Different orders and additional or alternative steps are of course possible. As such, method 400 is a non-limiting example method for controlling and monitoring a plurality of in-vehicle subsystems via an in-vehicle gateway system.

Fig. 5a provides a block diagram illustrating a method 500a for an in-vehicle gateway system to control and monitor a plurality of in-vehicle subsystems, according to one aspect of the present disclosure.

The method 500a may include receiving a control command from a driver of the vehicle via a touch screen and/or a voice receiver at 502, and converting the common data format or unified control command to a local data format or local control command format at 504 to cause the data or unified control command to be sent to the onboard subsystem. The method 500a may further include: executing, by the software virtualization module, one of the plurality of services and executing the control command at 506; converting the local data format of the onboard subsystem to a common data format at 508 such that the data is sent to the central controller or onboard subsystem; and receiving a response from the in-vehicle subsystem at 510.

The step of receiving a control command from a driver of the vehicle at 502 may include receiving a command via an in-vehicle voice receiving device or receiving a command from an in-vehicle touch screen. The receiving device may also have the ability to interact with the driver to clarify ambiguous commands or display errors if the received command is ambiguous or cannot be executed.

The step of converting the unified control commands at 504 may include converting the common control commands to commands in a native format of the onboard subsystems. For example, the control commands for adjusting the sensors, e.g. the cameras, are issued in a common control command from a central controller. The unified command is then converted into a command local to the sensor device. For example, the sensor may have its own control commands specific to the vendor of the camera. The unified control commands are converted into commands that can be understood by the specific vendor's equipment.

The step of executing at least one of the plurality of services by the software virtualization module at 506 may include providing the service to a central controller or an in-vehicle subsystem using one or more in-vehicle devices. The service is provided without burdening the recipient of the service with details specific to one or more in-vehicle devices. That is, the central controller or onboard subsystem may use the services provided by the device without needing to know the details of how the services are provided by the device or any details about the device itself.

Converting the local data format of the in-vehicle device to the common data format at 508 may include converting the format of the data generated by the in-vehicle device to a common data structure known to the central controller. For example, an onboard radar may generate data in a format specific to the radar provider. The data is converted into a common data structure that can be further processed and used by the central controller or ADAS subsystem. The radar data may also be used by other onboard subsystems or newly added subsystems or applications.

Receiving a response from the in-vehicle subsystem at 510 may include receiving a response from a subsystem that cooperates with one or more in-vehicle devices to execute the unified control command. The central controller may also display the response on a touch screen or play the response in a speaker according to a response output format configured by the driver.

The method 500a of fig. 5a illustrates an example process for an onboard gateway system to control and monitor an onboard subsystem.

The steps and the order of the steps of the method 500a are for illustrative purposes. Certain steps may be combined or skipped. Different orders and additional or alternative steps are of course possible. As such, method 500a is a non-limiting example method for controlling and monitoring a plurality of in-vehicle subsystems via an in-vehicle gateway system.

Fig. 5b provides a block diagram illustrating another method 500b for an in-vehicle gateway system to monitor the switch fabric and communication links and employ new subsystems, according to an aspect of the present disclosure.

The method 500b may include: monitoring link states of the switch fabric and associated communication links at 522; initiating a handoff from an active switching unit to a standby switching unit of the switching fabric at 524; and adding the in-vehicle subsystem using one of the optional expansion connectors at 526.

Monitoring link status of the switch fabric and associated communication links at 522 may include monitoring active units of the switch fabric and communication links connecting the active units of the switch fabric with the onboard subsystems in real time. Monitoring may include polling active switching units and status reports of communication links in real time. Monitoring may also include receiving predetermined status reports from the active switching unit and the communication link. In one embodiment, the switching fabric is in a one-to-one active-standby redundancy configuration.

Initiating a handoff from an active switching unit to a standby unit of the switching fabric at 524 may include activating the standby unit of the switching fabric when a fault condition in the active unit or an associated communication link of the switching fabric is detected or reported to the central controller. In one example configuration, the switching fabric is an ethernet switch with a one-to-one redundant configuration. When a fault condition occurs at the active ethernet switching unit, the standby unit is activated in real time and takes over the responsibility of managing the communication between the central controller and the onboard subsystems.

The step of employing the in-vehicle subsystem using one of the plurality of optional expansion connectors at 526 may include employing a new application or in-vehicle subsystem using a platform provided by the in-vehicle gateway system. For example, a black box subsystem may be added to record important transient data related to driving and vehicle conditions. Recorded data for determining single or multiple causes of the incident when needed. In one example configuration, the permanent recording device is plugged into an optional connector. The central controller then routes important data identified from other subsystems, such as the ADAS subsystem and the drive train subsystem, to the recording device of the newly added black box subsystem. Services such as configuration services, data services, cloud services, and management services may be employed in the process of adding the black box subsystem. Other subsystems and applications that share the resources and data of existing subsystems may be added.

Method 500b of fig. 5b illustrates one example method for monitoring the switch fabric and communication links and employing the new subsystem.

The steps and the order of the steps of method 500b are for illustration purposes. Some steps may be combined or skipped. Different orders and additional or alternative steps are of course possible. As such, method 500b is a non-limiting example method for monitoring a switch fabric and a communication link through an in-vehicle gateway system.

Fig. 6 provides a block diagram illustrating a process flow 600 for sensor data transmission in accordance with an aspect of the present disclosure.

As described above, one function of a data service is to store and forward data and publish the data to a remote data server for various applications. One example of data is telemetry data collected by an on-board subsystem. Process flow 600 illustrates a basic sensor data transmission flow within an in-vehicle gateway system. In one example embodiment, onboard devices, such as various sensors 651, collect sensor data in its native format. For example, the various sensors 651 may include a road condition sensor, a magnetic sensor, a vehicle distance sensor, and a GPS sensor. The collected sensor data is sent to the ADAS subsystem 642 via a field bus 641, such as a Controller Area Network (CAN), a Local Interconnect Network (LIN), or FlexRay.

The field sensor data is parsed at the ADAS interface 642 and encapsulated into a common data format, such as ethernet packets. Interface management 632 of configuration service 630 is used to process interface packets of sensor data encapsulated in ethernet packets. In some embodiments, interface management 632 handles processing from different buses, e.g., ADAS interface, I²C. SPI, GPIO, etc. The different data formats are converted to a unified data format for the data service 610. ASome sensor data may be forwarded to interface manager 632 without going through ADAS interface 642. Instead, the data is via a channel such as I²C. One of the common buses 643 for SPI or GPIO is forwarded.

In addition, data service buffers 602, data switches 603, and databases 604 of data service 610 may be used to buffer and filter sensor data. The cached and filtered sensor data may be forwarded by the cloud client 623 to a remote cloud server or other gateway subsystem 653 via wireless communication protocols WiFi, 802.11p, 3G/4G/5G 645, and interface management 632 of the configuration service 630.

FIG. 7 provides a block diagram illustrating a process flow 700 for sensor data transmission using a custom bus in accordance with an aspect of the present disclosure.

The process flow 700 is the same as the process flow 600 shown in fig. 6, except that a custom bus 702 is used instead of a Controller Area Network (CAN)/Local Interconnect Network (LIN) or FlexRay 641 and a third party device 712 is used instead of the ADAS interface 642. According to one configuration, onboard devices such as various sensors 651 collect sensor data in a native format. The collected sensor data is sent to third party device 712 via custom bus 702 and forwarded to interface manager 632. The remainder of process flow 700 is the same as process flow 600.

Fig. 8 provides a block diagram illustrating a process 800 of interaction between an in-vehicle gateway system, such as in-

vehicle gateway systems

100 and 200, and an external cloud server, according to one aspect of the present disclosure.

Process 800 includes in-vehicle gateway systems 812, 814, and 816, which in turn use cloud services 822, 824, and 826, respectively, to monitor and control their respective subsystems. Cloud services 822, 824, and 826 interact with remote cloud server 810. Remote cloud server 810 may include distributed stream server 802, distributed stream processor 804, and distributed data storage server 806. An example of a distributed stream server 802 is Apache Kafka, which provides an open source stream processing platform. An example of a distributed stream processor 804 is Apache Storm, which provides an open source based distributed stream processing computing framework. One example of a distributed data storage server 806 is Apache Hadoop, which provides an open source software framework for distributed storage and processing of large data sets using a specialized programming model, such as the MapReduce programming model.

In an example cloud data flow, cloud services 822-826 may publish and push data collected at in-vehicle gateway systems 812, 814, and 816 to distributed stream server 802 of remote cloud server 810. The distributed stream server 802 may process and store data from the in-vehicle gateway systems 812, 814, and 816 using services from the distributed stream processor 804 and the distributed data storage server 806. The distributed stream server 802 may also respond to data requests for processed and stored data from the in-vehicle gateway systems 812, 814, and 816.

FIG. 9 provides a block diagram illustrating a process 900 of an example of an application of automatic parking using an in-vehicle gateway system, such as in-

vehicle gateway systems

100 and 200, according to one aspect of the present disclosure.

Automated parking may be an application developed on a platform provided by an in-vehicle gateway system.

At 912, driver 910 may trigger an auto stop function via a voice command or pressing a menu button. In one configuration, the trigger action may be generated by an in-vehicle navigation system. For example, when the driver 910 reaches a predetermined destination, the in-vehicle navigation system may issue an auto-stop command by itself.

At step 922, the central controller 920 of the in-vehicle gateway system may send an "auto park" command to the vehicle control subsystem 930 using the ethernet switch fabric and the common communication channel. At step 932, the vehicle control subsystem 930 accepts the "auto stop" command, converts the command to a format specific to the vehicle 940, if appropriate, and then sends the command to the vehicle 940.

At step 944, vehicle control subsystem 930, in cooperation with other subsystems, such as the ADAS subsystem and drive train control subsystem of vehicle 940, initiates a search for a parking space, performs a parking function, and reports status to central controller 920. The vehicle control subsystem 930 may search for parking spaces using radar/lidar, ultrasonic sensors, and video, and perform control of the vehicle through its driveline control subsystem.

At step 946, the central controller 920 displays the status in the local screen. Additionally, the central controller 920 may forward the status to a cloud server. The status includes parking action, GPS location, warning information, etc. In one configuration, the vehicle control subsystem 930 may be a combination of the powertrain controller 108 and the ADAS subsystem 105 of fig. 1, and the central controller 920 is the central controller and switching fabric 110 of fig. 1.

One advantage of the vehicular gateway system is flexibility and ease of adoption of new applications. Another type of vehicle based gateway system is described herein. For example, assume that a vehicle manufacturer desires to add a vehicle auxiliary safety system to monitor sensor status and check whether the sensor status and values are valid. If the sensor status and value are not valid, the in-vehicle gateway system may take action based on the criticality of the sensor data. In addition to the services provided by the in-vehicle gateway system as described above, sensor status and action tables are used to help implement a vehicle assisted security system. For example, a table may be configured via a configuration service to indicate a level of criticality of an event. One example process for using an action table may include the following steps:

1) the central controller configures the action table using a configuration service.

2) The action table is communicated to the vehicle control subsystem via a data service.

3) The central controller of the vehicle monitors the sensor states according to the action table and performs corresponding actions. Table 1 below shows an example of an action table. For example, if the interior temperature sensor reaches a predetermined level, the vehicle air conditioner is turned on or off. For another example, if the radar sensor detects an object within a predetermined distance, the vehicle central controller may issue a brake or acceleration command to the driveline control subsystem based on the distance and other conditions. The powertrain control subsystem may also report status to the central controller.

4) The central controller forwards the state to the cloud server via the cloud service and saves the state data via the data service.

Sensor with a sensor element	Movement of
		Internal temperature	Air conditioner
Radar	Braking and accelerating
		Carbon monoxide	Alarm, open window
Oxygen concentration	Alarm, open window
		Collision of vehicles	Alarm device
Acceleration sensor	Alarm device
		Gravity sensor	Alarm device

Table 1: vehicle auxiliary safety system action table

Those of skill would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the disclosure herein may be implemented as electronic hardware, computer software, or combinations of both. To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described above generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the present disclosure.

The various illustrative logical blocks, modules, and circuits described in connection with the disclosure herein may be implemented or performed with a general purpose processor, a special purpose sensor, an Application Specific Integrated Circuit (ASIC), a Field Programmable Gate Array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor may be a microprocessor, but in the alternative, the processor may be any conventional processor, controller, microcontroller, or state machine.

The steps of a method or algorithm described in connection with the disclosure herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. A software module may reside in RAM memory, flash memory, ROM memory, EPROM memory, EEPROM memory, registers, or any other form of storage medium known in the art. An exemplary storage medium is coupled to the processor such the processor can read information from, and write information to, the storage medium. In the alternative, the storage medium may be integral to the processor. The processor and the storage medium may reside in an ASIC. The ASIC may reside in a sensor device. In the alternative, the processor and the storage medium may reside as discrete components in a sensor device.

In one or more exemplary designs, the functions described may be implemented in hardware, software, firmware, or any combination thereof. If implemented in software, the functions may be stored on or transmitted over as one or more instructions or code on a computer-readable medium. Computer-readable media includes both computer storage media and communication media including any medium that facilitates transfer of a computer program from one place to another. A storage media may be any available media that can be accessed by a general purpose or special purpose computer. By way of example, and not limitation, such computer-readable media can comprise RAM, ROM, EEPROM or other optical disk storage or any other medium that can be used to carry or store desired program code means in the form of instructions or data structures. Also, any connection is properly termed a computer-readable medium. For example, if the software is transmitted from a remote server or other remote source in a website, network cloud, or using a wired link such as coaxial cable, fiber optic cable, twisted pair, Digital Subscriber Line (DSL), or wireless technologies such as infrared, radio, and microwave, then the coaxial cable, fiber optic cable, twisted pair, DSL, or wireless technologies such as infrared, radio, and microwave are included in the definition of medium. Combinations of the above should also be included within the scope of computer-readable media.

The previous description of the disclosure is provided to enable any person skilled in the art to make or use the disclosure. Various modifications to the disclosure will be readily apparent to those skilled in the art, and the generic principles defined herein may be applied to other variations without departing from the spirit or scope of the disclosure. Thus, the disclosure is not intended to be limited to the examples and designs described herein but is to be accorded the widest scope consistent with the principles and novel features disclosed herein.

Claims

1. An on-board gateway system for monitoring and controlling a plurality of on-board subsystems within a vehicle, the plurality of on-board subsystems including at least a first on-board subsystem, a second on-board subsystem, and a third on-board subsystem, the on-board gateway system comprising:

a central controller and a switching fabric;

the central controller is configured to:

enabling the third vehicle-mounted subsystem to use resources of the first vehicle-mounted subsystem; and enabling the third on-board subsystem to use data from the second vehicle-mounted subsystem; generating and issuing a unified control command to monitor or control at least one of the plurality of on-board subsystems, the unified control command comprising a control command structure common to the plurality of on-board subsystems; and filtering, fusing and combining multiple types of pre-processed or post-processed data from the plurality of on-board subsystems, the pre-processed or post-processed data comprising data from a plurality of sensors;

the switch fabric is configured to:

interconnecting the central controller with the plurality of on-board subsystems and communicating at least a unified control command to at least one of the plurality of on-board subsystems;

each of the plurality of on-board subsystems is configured to:

2. The in-vehicle gateway system of claim 1, further comprising a plurality of selectable external connectors, wherein:

3. The in-vehicle gateway system of claim 1, wherein the plurality of in-vehicle subsystems comprises a networking subsystem, an infotainment subsystem, an advanced driver assistance and navigation subsystem, an internet of things subsystem, a sensor gateway subsystem, a communication and security subsystem, an information technology peripheral subsystem, and a storage subsystem, wherein:

4. The vehicular gateway system according to claim 1, further comprising:

wherein the central controller further comprises:

5. The in-vehicle gateway system of claim 1, wherein the switching fabric comprises one or more of a CAN data bus, a CAN-FD data bus, a LIN data bus, an ethernet, an AVB data bus, a low latency ethernet, and a pair of ethernet networks.

6. The in-vehicle gateway system of claim 5, wherein the switch fabric in a one-to-one active and standby redundancy configuration is configured to monitor link status of the switch fabric and associated communication links and initiate a handoff once the switch fabric identifies a fault condition in one of the associated communication links or an active switching unit of the switch fabric.

7. The in-vehicle gateway system of claim 1, further comprising a virtualization module, wherein:

8. The in-vehicle gateway system of claim 7, wherein the data service comprises:

publishing the telemetry data to a remote server;

9. The in-vehicle gateway system of claim 7,

the configuration service comprises a management configuration file;

10. A monitoring method of a vehicle-mounted subsystem is applied to the vehicle-mounted gateway system as claimed in any one of claims 1 to 9, and is characterized by comprising the following steps:

11. The monitoring method of claim 10, further comprising the step of

12. The monitoring method of claim 10, wherein generating the unified control command by the central controller further comprises:

13. The monitoring method of claim 10, further comprising the steps of:

monitoring link states of the switch fabric and associated communication links;

and initiating a switch from an active switching unit to a standby switching unit of the switching fabric when the central controller identifies a fault condition in one of the active switching units or the associated communication links of the switching fabric, wherein the switching fabric includes one or more of a CAN data bus, a LIN data bus, a CAN-FD data bus, an ethernet, a low latency ethernet, an AVB data bus, and a pair of ethernet networks.

14. The monitoring method of claim 10, further comprising the steps of:

15. The monitoring method of claim 10, further comprising the steps of:

16. The monitoring method of claim 10, further comprising the steps of:

17. A monitoring device of a vehicle-mounted subsystem, which is applied to the vehicle-mounted gateway system according to any one of claims 1 to 9, wherein the monitoring device comprises:

a memory;

and at least one processor coupled to the memory and configured to:

18. The monitoring device of claim 17, wherein the at least one processor is further configured to: