System for dynamically allocating services between controllers in a car

Abstract

The present disclosure provides a "system for dynamically allocating services between controllers in an automobile". A vehicle comprising a plurality of controllers configured to communicate over a network and programmed to perform services through operation of a plurality of programs stored and executed in at least one of the controllers. The vehicle includes a gateway controller in communication with the controllers and programmed to transfer at least one of the programs from a first controller to a second controller in response to performance data indicating a decrease in performance of the first controller.

Description

Technical Field

[0001] This application generally relates to a vehicle communication system for assigning service programs to controllers in a vehicle. Background Technology

[0002] A car includes many controllers. These controllers are programmed to perform a specific set of vehicle-related functions. For example, a controller might be programmed to manage door locks and windows. This set of functions remains unchanged throughout the controller's lifespan. A controller programmed to manage door locks and windows will perform the same functions throughout the vehicle's lifespan. Controllers are also designed with some memory and processing reserves to ensure they have sufficient execution time and resources to perform all functions. In the event of partial or complete controller failure, those functions implemented by that controller will be lost. Existing systems cannot tolerate failure. Summary of the Invention

[0003] A vehicle includes: a plurality of controllers configured to communicate via a network and programmed to perform services through the operation of a plurality of programs stored and executed in at least one controller. The vehicle also includes a gateway controller that communicates with the controllers and is programmed to transfer at least one program from a first controller to a second controller in response to performance data indicating a performance degradation in the first controller.

[0004] The network may be Ethernet, and the controller may also be configured to implement the Constrained Application Protocol (CoAP) over the Ethernet. Data indicating performance degradation may include service response times exceeding a predetermined time. Data indicating performance degradation may include communication loss between the gateway controller and the first controller exceeding a predetermined time. Data indicating performance degradation may include communication bandwidth between the first controller and the gateway controller being less than a predetermined bandwidth. The gateway controller may also be configured to send commands to the first controller to stop and restart the program in response to performance data indicating performance degradation. The gateway controller may also be connected to an external network and programmed to communicate with applications running on external servers via the external network using Hypertext Transfer Protocol (HTTP).

[0005] The vehicle includes multiple controllers programmed to execute multiple programs to perform services and communicate over a vehicle network using the Constrained Application Protocol (CoAP). The vehicle also includes a gateway controller configured to communicate with external servers using Hypertext Transfer Protocol (HTTP), communicate over the vehicle network using CoAP, and execute a service manager that dynamically allocates programs among the controllers based on their performance parameters.

[0006] The gateway controller can also be programmed to transmit performance parameters to an external server. Performance parameters may include the response time between the arrival and completion of a request to perform a service. Performance parameters may include the communication bandwidth between controllers utilized on the vehicle network. Performance parameters may include the frequency of service usage. The gateway controller can also be programmed to dynamically allocate new service programs based on performance parameters and transmit them to the controller in response to receiving multiple new service programs from an external server for performing a new service. The gateway controller can be programmed to allocate programs based on the controller's resource usage and remaining processing capacity. The gateway controller can also be programmed to transmit at least one program executed by the first controller to a second controller in response to a performance parameter indicating a performance degradation in the first controller.

[0007] A vehicle communication system includes: a gateway controller configured to communicate with an external server using Hypertext Transfer Protocol (HTTP), communicate with an internal vehicle network via the Constraint Application Protocol (CoAP), and execute a service manager that dynamically allocates multiple service programs associated with services among multiple controllers connected to the internal vehicle network based on the controller's performance parameters.

[0008] The gateway controller can also be programmed to receive performance parameters from the controller. It can also be programmed to transmit performance parameters to external servers. Furthermore, it can be programmed to receive service statistics from each controller and transmit them to external servers. Finally, it can be programmed to arbitrate controller access to external servers. Attached Figure Description

[0009] Figure 1 This is a possible configuration for the vehicle communication system.

[0010] Figure 2 This is a possible configuration for a distributed processing architecture used in vehicles.

[0011] Figure 3 It describes the possible configurations for the allocation of service programs between controllers in a vehicle.

[0012] Figure 4 It is a flowchart of a set of possible operations performed by the service manager that implements a distributed service architecture in the vehicle. Detailed Implementation

[0013] Embodiments of this disclosure are described herein. However, it should be understood that the disclosed embodiments are merely examples and other embodiments may take various and alternative forms. The drawings are not necessarily drawn to scale; some features may be enlarged or minimized to show details of particular components. Therefore, the specific structural and functional details disclosed herein are not to be construed as limiting, but merely as representative bases for teaching those skilled in the art to adopt the invention in various ways. As will be understood by those skilled in the art, various features shown and described with reference to any of the drawings may be combined with features shown in one or more other drawings to produce embodiments not explicitly shown or described. The combinations of features shown provide representative embodiments for typical applications. However, various combinations and modifications of features consistent with the teachings of this disclosure may be desired for particular applications or implementations.

[0014] Figure 1 An exemplary block topology for a vehicle-based computing system 100 (VCS) for a vehicle is shown. An example of such a vehicle-based computing system 100 is the SYNC system manufactured by The Ford Motor Company. A vehicle enabled by the vehicle-based computing system 100 may include a visual front-end interface 104 located within the vehicle. If the interface 104 is, for example, equipped with a touch-sensitive display, a user may be able to interact with the interface. In another illustrative embodiment, interaction occurs via button presses, a spoken dialogue system with automatic speech recognition, and speech synthesis.

[0015] exist Figure 1 In the illustrative embodiment shown, at least one processor 103 controls at least a portion of the operation of the vehicle-based computing system 100. The processor 103, located within the vehicle 131, allows for in-vehicle processing of commands and programs. Furthermore, the processor 103 is connected to non-persistent memory 105 and persistent memory 107. In this illustrative embodiment, non-persistent memory 105 is random access memory (RAM), while persistent memory 107 is a hard disk drive (HDD) or flash memory. Non-persistent memory can include both persistent memory and RAM. Typically, persistent memory 107 can include all forms of memory that retain data when the computer or other device is powered off. These memories include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, solid-state drives, portable USB drives, and any other suitable form of persistent memory.

[0016] Processor 103 may also include several different inputs that allow users and external systems to interface with processor 103. Vehicle-based computing system 100 may include a microphone 129, an auxiliary input port 125 (for input 133), a Universal Serial Bus (USB) input 123, a Global Positioning System (GPS) input 124, a screen 104 (which may be a touchscreen display), and a Bluetooth input 115. VCS 100 may also include an input selector 151 configured to allow users to switch between various inputs. Inputs from both microphone 129 and auxiliary connector 125 can be converted from analog to digital by analog-to-digital (A / D) converter 127 before being passed to processor 103. Although not shown, many vehicle components and auxiliary components communicating with the VCS may use vehicle networks (such as, but not limited to, Controller Area Network (CAN) bus, Local Area Network (LIN) bus, Media-Oriented System Transport (MOST) bus, Ethernet bus, or FlexRay bus) to allow data to and from VCS 100 (or its components).

[0017] The output from processor 103 may include, but is not limited to, the output from a visual display 104 and a speaker 113 or a stereo system. Speaker 113 may be connected to amplifier 111 and receive its signal from processor 103 via digital-to-analog (D / A) converter 109. The output may also be transmitted to a remote Bluetooth device such as personal navigation device (PND) 154 or a USB device such as vehicle navigation device 160 along bidirectional data streams shown at 119 and 121, respectively.

[0018] In one illustrative embodiment, system 100 uses a Bluetooth transceiver 115 and antenna 117 to communicate with a user's roaming device 153 (e.g., a cellular phone, smartphone, personal digital assistant (PDA), or any other device with wireless remote network connectivity). The roaming device 153 can then be used to communicate with a network 161 outside the vehicle 131, for example, via a device tower communication path 155 having a cellular tower 157, over a tower network communication path 159. In some embodiments, the cellular tower 157 can be a wireless Ethernet or WiFi access point defined by the Institute of Electrical and Electronics Engineers (IEEE) 802.11 standard family. Exemplary communication between the roaming device 153 and the Bluetooth transceiver 115 is represented by a Bluetooth signaling path 114.

[0019] The pairing of roaming device 153 and Bluetooth transceiver 115 can be instructed via button 152 or similar input. Therefore, the CPU is instructed to pair the vehicle-mounted Bluetooth transceiver 115 with the Bluetooth transceiver in roaming device 153.

[0020] Data can be transmitted between CPU 103 and network 161 using, for example, a data plan associated with roaming device 153, onboard data, or dual-tone multi-frequency (DTMF) tones. Optionally, it may be desirable to include a vehicle modem 163 with antenna 118 to establish a vehicle-to-device communication path 116 for transmitting data between CPU 103 and network 161 via voice bands. Roaming device 153 can then be used to communicate with network 161 outside vehicle 131, for example, via device tower communication path 155 with cellular tower 157, on tower network communication path 159. In some embodiments, modem 163 can establish a vehicle-tower communication path 120 directly with cellular tower 157 for communicating with network 161. As a non-limiting example, modem 163 may be a USB cellular modem, and vehicle-tower communication path 120 may be cellular communication.

[0021] In one illustrative embodiment, processor 103 is equipped with an operating system that includes an application programming interface (API) for communicating with modem application software. The modem application software can access embedded modules or firmware on Bluetooth transceiver 115 to enable wireless communication with remote Bluetooth transceivers, such as those present in roaming device 153. Bluetooth is a subset of the IEEE 802PAN (Personal Local Area Network) protocol. The IEEE 802LAN (Local Area Network) protocol includes WiFi and has considerable overlap with IEEE 802PAN. Both are suitable for wireless communication within vehicles. Other wireless communication devices that can be used in this field are free-space optical communications (such as IrDA) and non-standardized consumer IR protocols or inductively coupled devices (including, but not limited to, near-field communication systems such as RFID).

[0022] In another embodiment, roaming device 153 includes a modem for voiceband or broadband data communication. In the voiceband data embodiment, a technique called frequency division multiplexing can be implemented when the owner of the roaming device can make a call through the device while transmitting data. At other times, when the owner is not using the device, data transmission can use the entire bandwidth (300 Hz to 3.4 kHz in one example). While frequency division multiplexing may be common for and still in use for analog cellular communication between vehicles and the Internet, it has been largely replaced by combinations of code division multiple access (CDMA), time division multiple access (TDMA), and space division multiple access (SDMA) for digital cellular communication (including, but not limited to, orthogonal frequency division multiple access (OFDMA) which may include time-domain statistical multiplexing). These are all ITU International Mobile Telecommunications (IMT) 2000 (3G) compliant standards and provide data rates of up to 2 Mbps for stationary or walking users and 385 Kbps for users in moving vehicles. The 3G standard is now being replaced by Advanced IMT (4G), which provides 100 Mbps for users in vehicles and 1 Gbps for stationary users. If a user has a data plan associated with roaming device 153, the data plan may allow for broadband transmission, and the system can use a wider bandwidth (accelerating data transmission). In another embodiment, roaming device 153 is replaced by a cellular communication device (not shown) installed on vehicle 131. In yet another embodiment, roaming device 153 may be a wireless local area network (LAN) device capable of communicating via, for example (but not limited to), an IEEE 802.11g network (i.e., WiFi) or a WiMax network.

[0023] In one embodiment, input data can be transmitted to the vehicle's internal processor 103 via roaming device 153 through an audio data or data plan, via an in-vehicle Bluetooth transceiver 115. For example, in the case of some temporary data, the data can be stored on an HDD or other storage medium 107 until the data is no longer needed.

[0024] Additional sources that can interface with the vehicle-based computing system 100 include a personal navigation device 154 with, for example, a USB connection 156 and / or an antenna 158, a vehicle navigation device 160 with a USB 162 or other connections, an in-vehicle GPS device 124, or a remote navigation system (not shown) connected to a network 161. USB is one of the serial networking protocols. IEEE 1394 (FireWire) TM (Apple Inc.), iLINK TM (Sony) and Lynx TMThe Texas Instruments (TI) serial protocol, EIA (Electronic Industries Association) serial protocol, IEEE 1284 (Centronics port), S / PDIF (Sony / Philips Digital Interconnect Format), and USB-IF (USB Users Forum) form the main part of the device-to-device serial standard. Most protocols can be implemented for electrical or optical communication.

[0025] Furthermore, the CPU 103 can communicate with various other auxiliary devices 165. The auxiliary devices 165 can be connected wirelessly (e.g., via auxiliary device antenna 167) or wired (e.g., via auxiliary device USB 169). The auxiliary devices 165 may include, but are not limited to, personal media players, wireless medical devices, portable computers, etc.

[0026] Alternatively or additionally, CPU 103 may connect to vehicle-based wireless router 173 using, for example, a WiFi (IEEE 802.11) transceiver / antenna 171. This allows CPU 103 to connect to remote networks within range of local router 173. In some configurations, router 173 and modem 163 may be combined into an integrated unit. However, the features described herein are applicable to both modular and integrated configurations.

[0027] In addition to the exemplary process performed by a vehicle computing system located within the vehicle, in some embodiments, the exemplary process may also be performed by a computing system communicating with the vehicle computing system. Such a system may include, but is not limited to, wireless devices (e.g., but not limited to, mobile phones) or remote computing systems (e.g., but not limited to, servers) connected via wireless devices. Such systems may be collectively referred to as a Vehicle-Associated Computing System (VACS). In some embodiments, specific components of the VCS may perform specific parts of the process depending on the specific implementation of the system. By way of example and not limitation, if a process has a step of sending or receiving information with a paired wireless device, it is likely that the wireless device does not perform the process, because a wireless device does not “send and receive” information with itself. Those skilled in the art will understand when it is inappropriate to apply a particular VCS to a given solution. In all solutions, it is expected that at least the vehicle computing system (VCS) located within the vehicle itself will be able to perform the exemplary process.

[0028] The vehicle-based computing system 100 can act as a gateway between an external network (e.g., 161) and an internal vehicle network. Figure 2A possible diagram of a distributed architecture for connecting multiple controllers in vehicle 131 is depicted. The vehicle system may include any number of controllers. Controllers can be programmed to implement various services. Services can be implemented in hardware / firmware to perform a specific set of operations related to a feature or function. For example, services can be implemented to lock and unlock doors, measure and transmit specific sensor signals, or perform diagnostic requests. Services can be triggered periodically for real-time operation. Services can be triggered on demand when an external diagnostic request is received or when other user-initiated functions are to be performed. Services can be implemented as a single program in a single controller or as multiple programs across multiple controllers.

[0029] Distributed architectures are beneficial for control services, such as those implemented in vehicles. They avoid the bottleneck of a single central coordinator and ensure that not all services stop working if the coordinator fails. From an optimization perspective, distributed architectures are also beneficial because the amount of data transmitted can often be reduced by placing data-consuming control logic closer to the data producer. Furthermore, new services with previously unknown functionality can be added at any time. To support these dynamics, controllers can manage and provide a repository of services available on the network, as well as logging facilities that allow tracking changes. Because new applications can be installed at runtime, the purpose of individual services on the network is not fixed but may change throughout the network's lifetime. This requires dedicated lifetime management, which supports the installation, startup, shutdown, and deletion of services in controllers connected to the network.

[0030] Services can execute on devices with limited storage and processing power and can benefit from efficient message formats for communication between these devices. Efficient communication can be achieved by defining a clear boundary between a data description specified only once and a transmission format that includes only the raw data payload in binary representation. Furthermore, services and software can be designed efficiently to facilitate execution on resource-constrained devices. In such systems, minimal communication overhead is desirable. A service may comprise multiple service routines that execute in multiple controllers connected to a network. Intelligently distributing service routines among controllers can minimize the network bandwidth required to transfer data between controllers.

[0031] As the demand for connectivity and cloud communication increases in vehicle applications, automotive embedded networks will continue to evolve to include a variety of controllers based on different platforms (e.g., operating systems, programming languages, etc.). Another challenge is that each controller can be designed and developed by different vendors using different platforms. Therefore, the software should support vendor-independent, interoperable, cross-platform solutions. Any software solution should facilitate interoperability and data exchange between different products or services intended for widespread adoption.

[0032] Control services running on automotive networks can be data-driven. In a data-driven environment, data can be periodically acquired from sensors and pushed to networked services executed in the controller. These services can generate new data based on the received input and then push the new data to the next service in the processing chain. Control services running on automotive networks can also be control-driven. In a control-driven environment, client applications can interact with services through an abstract device interaction mechanism. The service can then control the device (e.g., the service can issue a command to open / close the rear window via a client program request). Generic commands can be defined, and control services can be implemented to execute these generic commands. Advanced users or services can communicate using generic commands without needing to know specifically how or in which controller(s) the generic command is implemented. For example, the interface can consist of operations of the Hypertext Transfer Protocol (HTTP) type, such as GET, POST, PUT, and DELETE.

[0033] Vehicle networks do not operate in isolation and are typically configured to access wide area networks and / or the Internet. Network service-based interfaces can be implemented to integrate vehicle networks with external components. A challenge lies in connecting resource-intensive network service domains with high component availability to vehicle network domains with limited coverage. Network service interfaces alone are insufficient for integrating vehicle networks with enterprise backends (e.g., in shop-floor integration scenarios). Additionally, data transmitted by sensor networks can be integrated into the enterprise knowledge domain. This may involve semantic information that allows combining measurement data with information contained in backend databases. Vehicle networks can also address security issues. Security functions in automotive networks can include integrity, authentication, and confidentiality. Software solutions can be designed to provide mechanisms for addressing and implementing these security features.

[0034] refer to Figure 2 Vehicle 131 may include gateway controller 204. Gateway controller 204 may include, as per [the relevant information] Figure 1 The features and functions described in the vehicle-based computing system 100. The gateway controller 204 can be configured to communicate between the external network 161 and the internal vehicle network (represented by the network switch 206).

[0035] Vehicle 131 may include multiple controllers or electronic control units (ECUs). For example, vehicle 131 may include a first controller 208 coupled to a first group 210 of sensors and actuators. Vehicle 131 may include a second controller 212 coupled to a second group 214 of sensors and actuators. Vehicle 131 may include a third controller 216 coupled to a third group 218 of sensors and actuators. Vehicle 131 may include a fourth controller 220 coupled to a fourth group 222 of sensors and actuators. Controllers (208, 212, 216, 220) and gateway controller 204 may include processors and volatile and non-volatile memory. Controllers (208, 212, 216, 220) may also include interface circuitry for connecting to a set of associated sensors and actuators. Sensors may be configured to provide feedback signals for operating various vehicle features. Actuators may be configured to operate various vehicle features. Note that additional controllers may be present without limitation.

[0036] The controllers (208, 212, 216, 220) can be connected to an internal vehicle network. The internal vehicle network may include a network switch 206. The network switch 206 can be configured to route data and messages between controllers (including gateway controller 204) within vehicle 131. The vehicle network may be Ethernet (IEEE 802). Each controller (208, 212, 216, 220) may be configured with hardware and software components to interface with the vehicle network.

[0037] Controllers (208, 212, 216, 220) can be programmed to implement specific services. To execute a service, signals from one or more other controllers may be required. Controllers (208, 212, 216, 220) can transmit signals via the internal vehicle network. Traditional automotive controls are statically configured, with services statically assigned to predetermined controllers. Such configurations are typically predetermined during the vehicle design phase and remain constant throughout the vehicle's lifespan. After vehicle production and sale, this design cannot effectively handle the addition of features and functions. As automotive technology expands to include autonomous vehicles and increased connectivity between vehicles and infrastructure, such static designs cannot keep pace. A more dynamic approach can lead to longer vehicle lifespans and greater customer satisfaction.

[0038] Services provide high-level abstractions that securely hide the implementation details of hardware devices from developers. Newly added services can be automatically discovered and integrated into existing applications or used to build new applications automatically or semi-automatically. Decomposing services into loosely coupled software modules provides high flexibility, reusability, and scalability, while facilitating the coexistence of different applications. Another benefit is the seamless integration of services from various hardware and software vendors. Furthermore, due to the high level of abstraction, domain knowledge is sufficient to intuitively understand the functionality of services and to install and configure / reconfigure services across the network.

[0039] Each of the sensors and actuators may have a corresponding service routine implemented in the associated controller. The service routine can be a program or application configured to provide an interface to the associated sensor or actuator. The service routine can be referred to as a server for the sensor / actuator. The service routine can be configured to process sensor inputs and provide one or more corresponding signals to the vehicle network. The service routine can be configured to receive signals including requests to operate the actuator and to provide signals to the actuator to perform the requested operation. The controller can be programmed to broadcast a list of available services via the internal vehicle network upon initialization or upon request. The available services can be listed in a repository along with data identifying the controllers in which the services are implemented.

[0040] Note that each controller can be programmed with multiple service routines. Furthermore, various levels of service routines may exist. For example, a high-level service routine can interface with many low-level service routines to perform functions. Additionally, some controllers can implement service routines that interface with service routines in other controllers. This architecture can be described as a distributed computing environment. Service routines may include interfaces for communication over the vehicle network.

[0041] Each of the controllers (208, 212, 216, 220) can implement a real-time operating system that allows for effective management of services. The operating system can be configured to allow the installation, removal, startup, and shutdown of services. The real-time operating system can manage and coordinate services (e.g., tasks) assigned to the controller. For example, the real-time operating system can trigger the periodic execution of services that are scheduled to run periodically.

[0042] Figure 3An example of a distributed, embedded, service-oriented architecture for a vehicle is depicted. The gateway controller 204 can be programmed with a service manager application 320. The service manager application 320 can be configured to manage services present in the controller. Service applications available in a distributed computing environment can be registered with the service manager application 320. The service manager application 320 can be programmed to store a repository or database of available services and service applications, storing the database in non-volatile memory for continued use.

[0043] The Service Manager application 320 can also be configured to monitor services distributed throughout the vehicle. The Service Manager application 320 can maintain a service registry, including the status of each service and / or service program. The service registry may include service version information, service compatibility information, a privilege list for each service, and service statistics. The Service Manager application 320 can be responsible for starting, stopping, and resetting services present in the vehicle. For example, the Service Manager 320 can interface with the operating system to provide commands for starting and stopping service programs in the controllers. Each controller can collect information about the assigned services and transmit this service information to the Service Manager 320 via the vehicle's Ethernet network.

[0044] The service manager application 320 can also monitor the resources used by services. For example, the service manager 320 can maintain a list of low-level programs used by each service. The service manager application 320 can maintain relevant service statistics for each service. Service statistics can be received from services running in the controller.

[0045] Gateway controller 204 can also be programmed with a first service application 322 (e.g., vehicle application X) and a second service application 324 (e.g., vehicle application Y). The first service application 322 and the second service application 324 can be configured to coordinate and manage specific services or features implemented in multiple controllers.

[0046] The first controller 208 can be configured to implement a service program 326 associated with the first service application 322 (e.g., vehicle service X1). The first controller 208 can be configured to implement a service program 328 associated with the second service application 324 (e.g., vehicle service Y2). The second controller 212 can be configured to implement a service program 330 associated with the first service application 322 (e.g., vehicle service X2). The second controller 212 can be configured to implement a service program 332 associated with the second service application 324 (e.g., vehicle service Y1). The third controller 216 can be configured to implement a service program 334 associated with the first service application 322 (e.g., vehicle service X3). Note that additional controllers may exist alongside other service programs.

[0047] The first controller 208, the second controller 212, and the third controller 216 can be configured to communicate via a vehicle network. Each service program can be configured to interface with a vehicle network driver to transmit signals via the vehicle network. The vehicle network can be Ethernet. Messages and signals exchanged by the controllers can conform to defined protocols.

[0048] Each controller can connect to one or more Ethernet networks within the vehicle. Gateway controller 204 can be configured to interface with external network 161. For example, gateway controller 204 can be configured to wirelessly connect to a remote network via a cellular network or wireless Ethernet connection. Communication with the remote network can be achieved using Transmission Control Protocol (TCP) (HTTP).

[0049] Several protocols are available for communication over Ethernet. Some applications can use TCP to communicate over a network. TCP includes features that ensure error-free transmission of data over a secure network. TCP defines how data is transmitted over a network. Vehicle communication systems can use HTTP to transmit information between systems. HTTP defines how data is encapsulated and configured for transmission over a network. HTTP defines how requests for data and responses are handled. TCP implementations typically require more memory and processing resources than are available in an embedded controller. For example, TCP requires establishing a connection during a multi-step handshake process before any messages are exchanged. This increases startup and communication time. Furthermore, in TCP, two communicating nodes can continuously keep their TCP sockets open to each other through persistent sessions, which can be difficult to implement with resource-constrained devices. TCP heartbeats can also be an additional overhead for resource-constrained devices. As a result, TCP may not be the best choice for real-time systems requiring fast response times.

[0050] For embedded applications such as vehicles, a more resource-efficient protocol may be preferred. One such protocol is the Constrained Application Protocol (CoAP). CoAP is designed for embedded systems and Internet of Things (IoT) applications. CoAP can be defined by Request for Comments (RFC) 7252 and related documents published by the Internet Engineering Task Force (IETF). Compared to TCP-based systems, CoAP-based systems may require fewer memory and processing resources. Embedded controllers implementing CoAP can communicate using the User Datagram Protocol (UDP). UDP is an alternative to TCP. UDP is designed to send packets without providing checks to ensure packets are not lost or received out of order. In contrast, TCP checks and retransmits lost packets, which increases overhead and latency. Therefore, UDP may be a more suitable protocol for real-time embedded applications.

[0051] The requirements for Internet-based communication and vehicle-to-everything (V2X) communication are not the same. Many vehicle applications may require very short timeouts to react or respond within a very short time. UDP can meet these characteristics because the application itself can be configured to handle unlikely error events. For example, in use cases with cyclic data, a preferred approach might be to wait for the next data transmission rather than attempting to repair the previous transmission. A disadvantage of UDP is that it does not handle segmentation and may only transmit small packets. This software solution can support UDP and handle segmentation at the application layer. Current transport protocols for CAN and FlexRay limit messages to 4095 bytes.

[0052] CoAP over UDP with associated service discovery mechanisms supports distributed and reconfigurable network architectures. Vehicle networks can change over time by adding new services and / or removing existing ones. The CoAP Service-Oriented Architecture (SOA) platform supports these dynamic networks by providing discovery mechanisms for new services. Automatic / semi-automatic service composition can be used to provide rapid integration of new services with running applications when a new service is detected.

[0053] CoAP is fast and efficient because it relies on low-overhead UDP. UDP is inherently and intentionally less reliable than TCP, and depends on the reliability of repeated message delivery rather than consistent connections. TCP is ideal for two communicating nodes to keep their TCP sockets open to each other through persistent sessions, which can be difficult for resource-constrained devices.

[0054] CoAP's reliability permeates Quality of Service (QoS). It provides a simple method for delivering both acknowledged and unacknowledged messages. Acknowledged messages can be confirmed using an acknowledgment message (ACK) from the intended recipient. This confirms that the message was received, but does not confirm whether the message content was correctly decoded or not decoded at all. Unacknowledged messages are sent and ignored. In embedded automotive systems, the vehicle network is typically in a closed environment and local to the vehicle.

[0055] CoAP can carry different types of data payloads and can identify the type of payload being used. CoAP integrates with Extensible Markup Language (XML), JavaScript Object Representation (JSON), Concise Binary Object Representation (CBOR), or any data format. CoAP has a fixed 4-byte header, and its compact option encoding ensures that a small number of messages produce little or no fragmentation at the link layer.

[0056] CoAP networks are inherently one-to-one. However, they also support one-to-many or many-to-many multicast messaging. This is inherent to CoAP because it is built on top of Internet Protocol version 6 (IPv6), which implements multicast addressing to devices in addition to their regular IPv6 addresses. CoAP is built as an application layer protocol on top of the Internet Protocol (IP) layer. Therefore, CoAP works independently of IP versions. Services built using CoAP are portable and can be migrated to IPv6. CoAP supports a request / response-based interaction model through the Representational State Transition (REST) ​​architectural style. Additionally, it supports a publish-subscribe (e.g., pub / sub) based interaction model.

[0057] CoAP is portable from small embedded microcontrollers to high-end microprocessors. CoAP is an application protocol and can run on many operating systems (OS). Multiple language implementations are available to support cross-platform integration / interoperability. The CoAP protocol has many implementations. CoAP was developed as part of the Internet standard document RFC 7252. CoAP is designed to interoperate with HTTP and RESTful Web through a simple proxy, making it inherently compatible with the Internet. CoAP uses Datagram Transport Layer Security (DTLS) on top of the UDP transport protocol. DTLS is a complete security protocol that uses negotiated key materials and algorithms to perform authentication, key exchange, and application data protection. CoAP endpoints may be limited by bandwidth and processing power. To optimize data transmission performance under these constraints, CoAP uses caching features consistent with HTTP.

[0058] Service orchestration is a form of service composition where interaction protocols exist between several partner services without a single point of control. Service coordination is another form of service composition where the relationships between all participating services can be described by a single endpoint (i.e., the composed services). Coordination involves transaction management between individual services. Coordination employs a centralized approach to service composition. Both forms of service composition can be implemented using CoAP. Using a client-server pattern, a centralized coordinator can implement business logic to coordinate with other services to fulfill requirements.

[0059] The vehicle communication system can be configured to enable CoAP (Cooperative Access Point) on the vehicle network. Communication over the vehicle network can utilize CoAP. Gateway controller 204 can implement CoAP to interface with controllers connected to the vehicle network. Controllers connected to the vehicle network can also implement CoAP to communicate with gateway controller 204. Gateway controller 204 can also be configured to communicate with external network 161 using HTTP. Gateway controller 204 can be configured to translate between HTTP and CoAP to facilitate communication between external network 161 and vehicle network 206.

[0060] Vehicle service programs can be implemented as CoAP clients. Each vehicle service program can manage and coordinate child processes or services implemented within the same controller. Vehicle service programs (e.g., CoAP clients) can exchange data using UDP datagram packets instead of TCP / IP connections on the vehicle network. Data communication between elements can follow peer-to-peer communication protocols.

[0061] Service statistics and / or performance parameters can be collected by the controller and reported to the service manager 320. The service manager 320 can use an established HTTP-CoAP proxy to report service statistics to external servers connected to the external network 161. Service statistics may include processor utilization, which can be expressed as a percentage of total possible utilization. Processor utilization may also be expressed as the amount of execution time over a given period. Service statistics may include memory utilization, which can be expressed as a percentage of total memory. Memory utilization can be interpreted as the controller's volatile and non-volatile memory usage. Service statistics may include network utilization, which can be expressed as the amount of data exchanged over the vehicle network within a given time interval.

[0062] Performance parameters can include service response time. For example, Service Manager 320 can be configured to record the amount of time it takes to complete a service. The time from service startup to service completion can be measured. A response time exceeding a predetermined time can indicate performance degradation. The response times of various sub-services can also be monitored. The response time of a sub-service can be measured as the time between request arrival and request completion. The ability to monitor various response times can be used to identify potential processing bottlenecks within the service.

[0063] Performance parameters can include the frequency of use of services and / or service programs. The controller can be programmed to count the number of requests for services and / or service programs within a predetermined time interval. Higher usage frequency may indicate services that require more processor time.

[0064] Performance parameters may include the communication status between gateway controller 204 and other controllers. Service manager 320 can be configured to monitor for communication loss between controllers. For example, service manager 320 may log the time associated with the last message received from a controller. A time elapsed since the last recorded time exceeding a predetermined period can indicate a loss of communication with the controller (e.g., performance degradation).

[0065] Performance parameters may include network bandwidth utilization between controllers. Service Manager 320 can be configured to monitor traffic on the vehicle network. Service Manager 320 can also be configured to determine the network utilization of each service. For example, the network utilization of each service can be determined by monitoring message traffic for each service. Network bandwidth can be expressed as a percentage of the total network bandwidth consumed in communicating with the controller.

[0066] Using this protocol, fault management can be simplified in a service-oriented distributed architecture. Any fault or performance degradation detected by a service can be propagated to other services. The parent service can decide to repair the system by resetting / recovering the child service, or it can propagate the error to the root service (Service Manager 320). Service Manager 320 can enforce policies and attempt recovery by resetting the service or system based on the criticality of the fault. Service Manager 320 can report fault / error statistics for a given service to external servers connected to the external network 161.

[0067] Services may need to respond to system / user events such as ignition on / off events or factory resets. The Service Manager 320 can multicast these messages over the network, and services can determine the order in which they start / stop. A parent service can determine the order of all its child services. Various other system / user events are possible.

[0068] Due to message multicasting, the connectivity status of a vehicular network can be easily identified. For example, a traffic application establishing a link with a traffic server residing in the cloud may need to know the optimized connection path before attempting to establish the link. The application can communicate with local network services to establish the optimized link. Controllers that monitor and publish connectivity status (e.g., Wi-Fi, cellular, Bluetooth) can multicast the status of all services that need connectivity status over the vehicular network. Network service programs residing on the controller running the traffic application can subscribe to this information and cache it locally. The controller can determine the optimized path and establish the link for the application based on the cached information. The traffic application can then connect to the external traffic server through the optimized link provided by the network service.

[0069] Service manager 320, executing in gateway controller 204, can monitor every service implemented in the system. In response to performance parameters indicating a degraded service or service program, service manager 320 can dynamically allocate related programs among controllers. For example, in response to data indicating a degraded performance of the first controller, service manager 320 can transfer a service program executing in the first controller to a second controller. Service manager 320 can send instructions or commands to the first controller to stop the execution of the related service program. Then, service manager 320 can transfer the service program to the second controller for installation. Service manager 320 can update the repository and send commands to the second controller to start the transferred service program. Service manager 320 can retrieve service programs from external servers connected to an external network. Service manager 320 can receive service programs from the first controller upon request.

[0070] In some configurations, Service Manager 320 can receive new services and related service programs. For example, it can receive new services from an external server via external network 161. Service Manager 320 can examine service statistics for each controller to determine on which controller the new service program should be assigned. For example, it can examine performance data including processor and memory utilization. Additionally, Service Manager 320 can determine which low-level services the new service program requires. Service Manager 320 can attempt to assign the new service program to controllers that are currently executing the low-level services used by the new service program, minimizing network traffic. Service Manager 320 can transmit the new service program to the selected controllers via the vehicle network. After installing the new service program, Service Manager 320 can issue a start command for the new service, which initiates its execution.

[0071] There are many examples of potential new services. Examples include diagnostic and troubleshooting service procedures that can be loaded and executed by the service facility. Diagnostic service procedures can help diagnose the condition of various components. An advantage of this architecture is that new service procedures can be installed and executed to perform specific functions. New service procedures can be temporary and will be removed after use. Other potential new services may include enabling new features or functions. For example, vehicle functions may be upgraded over time, requiring additional service procedures.

[0072] Figure 4 A possible flowchart 400 depicts a series of operations that can be performed by the service manager 320. Note that the depicted operations can be executed in parallel for any number of services. Operations can be repeated continuously for each service and service program. At operation 402, the service manager 320 can receive and / or calculate performance parameters. Performance parameters may include those parameters and service statistics previously discussed herein. Performance parameters can be received from the service programs running in the controller.

[0073] At operation 404, Service Manager 320 can monitor the services currently installed in the vehicle. For example, Service Manager 320 can monitor a database of services and related parameters to determine if the services are functioning correctly. Service Manager 320 can check parameters to ensure the availability of each service. Monitoring results may include requests to add, remove, or transfer service programs.

[0074] At operation 406, Service Manager 320 can perform a check to determine whether any new services should be added. Service Manager 320 can receive requests from external servers to install new services. If a new service is to be added, operation 408 can be performed. At operation 408, the service program associated with the new service can be assigned to the controller based on performance parameters as described herein.

[0075] If no new services are to be added, operation 410 can be performed to check if any services need to be deleted. If services need to be deleted, operation 412 can be performed to stop and remove the relevant service program from the controller. For example, a temporarily added service can be deleted after the service has been executed. Service Manager 320 can receive commands to delete services from external servers.

[0076] If no service is to be removed, operation 414 can be performed to determine if any performance parameters indicate a performance degradation of the relevant service. If performance parameters for one or more services indicate a performance degradation, operation 416 can be performed to command a service restart (e.g., stop and then start). At operation 418, a check can be performed to determine if a restart is sufficient to eliminate the degraded performance state. That is, performance parameters can be checked to determine if the performance degradation still exists. If the performance parameters indicate normal operation, execution can return to operation 402. If the degraded performance state still exists, operation 420 can be performed to reassign the affected service to another controller, as described herein.

[0077] The processes, methods, or algorithms disclosed herein can be delivered to or implemented by a processing device, controller, or computer (which may include any existing programmable electronic control device or special-purpose electronic control device). Similarly, the process, method, or algorithm can be stored as data and instructions in many forms executable by a controller or computer, including (but not limited to) information permanently stored on non-writable storage media such as ROM devices and information variablely stored on writable storage media such as floppy disks, magnetic tapes, CDs, RAM devices, and other magnetic and optical media. The process, method, or algorithm can also be implemented in a software executable object. Optionally, the process, method, or algorithm can be implemented wholly or partially using suitable hardware components (such as application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), state machines, controllers, or other hardware components or devices) or a combination of hardware, software, and firmware components.

[0078] While exemplary embodiments have been described above, it is not intended that these embodiments describe all possible forms covered by the claims. The vocabulary used in the specification is descriptive and not restrictive, and it should be understood that various changes may be made without departing from the spirit and scope of this disclosure. As previously stated, features of various embodiments may be combined to form further embodiments of the invention that may not be explicitly described or shown. While various embodiments may have been described as providing advantages or superiority over other embodiments or prior art implementations with respect to one or more desired characteristics, those skilled in the art will recognize that one or more features or characteristics may be compromised to achieve desired overall system properties, depending on the specific application and implementation. These properties may include, but are not limited to, cost, strength, durability, lifecycle cost, marketability, appearance, packaging, size, serviceability, weight, manufacturability, ease of assembly, etc. Therefore, embodiments described as less desirable than other embodiments or prior art implementations with respect to one or more characteristics are not outside the scope of this disclosure and may be desirable for a particular application.

[0079] According to the present invention, a vehicle is provided having: a plurality of controllers configured to communicate via a network and programmed to perform services by operating a plurality of programs stored and executed in at least one controller; and a gateway controller communicating with the controllers and programmed to transfer at least one program from the first controller to a second controller in response to performance data indicating a performance degradation of the first controller.

[0080] According to an embodiment, the network is an Ethernet, and the controller is also configured to implement the Constraint Application Protocol (CoAP) over the Ethernet.

[0081] According to an embodiment, data indicating performance degradation includes service response times exceeding a predetermined time.

[0082] According to an embodiment, the data indicating performance degradation includes communication loss between the gateway controller and the first controller exceeding a predetermined time.

[0083] According to an embodiment, the data indicating performance degradation includes communication bandwidth between the first controller and the gateway controller being less than a predetermined bandwidth.

[0084] According to an embodiment, the gateway controller is also configured to send a command to the first controller to stop and restart the program in response to performance data indicating a performance degradation.

[0085] According to an embodiment, the gateway controller is also connected to an external network and is programmed to communicate with an application running on an external server via the external network using the Hypertext Transfer Protocol (HTTP).

[0086] According to the present invention, a vehicle is provided having: a plurality of controllers programmed to execute a plurality of programs to perform services and communicate via a vehicle network using the Constrained Application Protocol (CoAP); and a gateway controller configured to communicate with an external server using the Hypertext Transfer Protocol (HTTP), communicate via the vehicle network using CoAP, and execute a service manager that dynamically allocates programs among the controllers based on the controllers' performance parameters.

[0087] According to an embodiment, the gateway controller is also programmed to transmit performance parameters to an external server.

[0088] According to an embodiment, the invention is further characterized in that the performance parameters include the response time between the arrival of a request for the execution service and the completion of the request.

[0089] According to an embodiment, the invention is further characterized in that the performance parameters include the communication bandwidth between controllers utilized on the vehicle network.

[0090] According to an embodiment, performance parameters include the frequency of service usage.

[0091] According to an embodiment, the gateway controller is also programmed to dynamically allocate new service programs based on performance parameters and transmit them to the controller in response to receiving multiple new service programs from an external server for performing new services.

[0092] According to an embodiment, the gateway controller is programmed to allocate programs based on the controller's resource usage and remaining processing capacity.

[0093] According to an embodiment, the gateway controller is also programmed to transmit at least one program executed by the first controller to the second controller in response to a performance parameter of the first controller indicating a performance degradation of the first controller.

[0094] According to the present invention, a vehicle communication system is provided, the vehicle communication system comprising: a gateway controller configured to communicate with an external server using Hypertext Transfer Protocol (HTTP), to communicate with an internal vehicle network via Constraint Application Protocol (CoAP), and to execute a service manager that dynamically allocates multiple service programs associated with services among multiple controllers connected to the internal vehicle network based on the controller's performance parameters.

[0095] According to an embodiment, the gateway controller is also programmed to receive performance parameters from the controller.

[0096] According to an embodiment, the gateway controller is also programmed to transmit performance parameters to an external server.

[0097] According to an embodiment, the gateway controller is also programmed to receive service statistics from each controller and transmit service statistics to an external server.

[0098] According to an embodiment, the gateway controller is also programmed to arbitrate access to external servers.

Claims

1. A vehicle comprising: sensor; Multiple controllers, the multiple controllers being configured to communicate via the vehicle's internal vehicle network; and A gateway controller that communicates with the plurality of controllers via the internal vehicle network and is connected to an external network. The first controller among the plurality of controllers is programmed to generate a service request corresponding to the received signal from the sensor and send the service request to the gateway controller in response to receiving the signal from the sensor. The gateway controller is programmed as follows: In response to receiving the service request, a service command is generated and sent to the second controller among the plurality of controllers to start a new service defined by a plurality of programs that are not previously known to the second controller, and to enable the second controller to perform functions corresponding to the new service; In response to performance data indicating a performance degradation of the second controller, at least one of the plurality of programs is transferred from the second controller to a third controller, such that the at least one program is removed from the second controller, and the second controller and the third controller cooperate to execute the plurality of programs to achieve the function.

2. The vehicle as claimed in claim 1, wherein, The internal vehicle network is an Ethernet network, and the multiple controllers are also configured to implement constraint application protocols over the Ethernet network.

3. The vehicle as claimed in claim 1, wherein, Data indicating performance degradation includes the service response time exceeding a predetermined time.

4. The vehicle as claimed in claim 1, wherein, Data indicating performance degradation includes communication loss between the gateway controller and the first controller exceeding a predetermined time.

5. The vehicle as claimed in claim 1, wherein, Data indicating performance degradation includes communication bandwidth between the first controller and the gateway controller being less than a predetermined bandwidth.

6. The vehicle as claimed in claim 1, wherein, The gateway controller is also configured to send a command to the first controller to stop and restart the program in response to performance data indicating a performance degradation.

7. The vehicle as claimed in claim 1, wherein, The gateway controller is also programmed to communicate with applications running on external servers via the external network using the Hypertext Transfer Protocol.

8. A vehicle comprising: Multiple controllers, which are programmed to execute multiple programs to perform services and communicate over the vehicle network using constrained application protocols; and A gateway controller is configured to communicate with an external server using the Hypertext Transfer Protocol and to communicate through the vehicle network using the Constraint Application Protocol. The first controller among the plurality of controllers is programmed to generate a service request corresponding to a signal received from the external server via the gateway controller and send the service request to the gateway controller. The gateway controller is programmed as follows: In response to receiving the service request, a service command is generated and sent to the second controller among the plurality of controllers to start a new service defined by a plurality of programs that are not previously known to the second controller, and to enable the second controller to perform functions corresponding to the new service; In response to a performance parameter indicating a performance degradation of the second controller, at least one of the plurality of programs is transferred from the second controller to a third controller, such that the at least one program is removed from the second controller, and the second controller and the third controller cooperate to execute the plurality of programs to achieve the function.

9. The vehicle as claimed in claim 8, wherein, The gateway controller is also programmed to transmit performance parameters to the external server.

10. The vehicle as claimed in claim 8, wherein, Performance parameters include the response time between the arrival of a request to perform a service and the completion of that request.

11. The vehicle as claimed in claim 8, wherein, Performance parameters include the communication bandwidth between controllers utilized on the vehicle network.

12. The vehicle as claimed in claim 8, wherein, Performance parameters include the frequency of use of the service.

13. The vehicle as claimed in claim 8, wherein, The gateway controller is also programmed to dynamically allocate and transmit the multiple new service programs to the multiple controllers based on the performance parameters in response to receiving multiple new service programs from the external server for performing another new service.

14. The vehicle as claimed in claim 8, wherein, The gateway controller is programmed to allocate the program based on the resource usage and remaining processing capacity of the plurality of controllers.

Images