COMMUNICATION SYSTEM FOR A VEHICLE

Abstract

In certain embodiments, an electric vehicle control system includes an electronic control unit (ECU) bus and a plurality of ECUs. A first ECU runs a broker service that communicates with a network server over a network, receives state information from applications running on the ECUs, generates subscription information based on the state information, and transmits the subscription information to the applications that have subscribed to it. The first ECU also runs a translation service that communicates with the broker service and the ECU bus, and an application that generates state information, sends the state information to the broker service, and receives subscription information from the broker service.The second ECU runs an application that transmits status information to the first ECU via the ECU bus and receives subscription information from the first ECU via the ECU bus.

Description

CROSS-REFERENCE TO RELATED REGISTRATIONS

[0001] This application claims the benefit of the preliminary US patent application with serial number 63 / 719,643 (filed on November 12, 2024), the contents of which are incorporated herein by reference in their entirety. INTRODUCTION

[0002] The present disclosure relates to communication systems. In particular, the present disclosure relates to a communication system for an electric vehicle.

[0003] Vehicles use various ad-hoc communication techniques to exchange data between applications running on network devices and applications running on the vehicle's electronic control units (ECUs). Once generated, the data is sent and translated across multiple communication channels before being received for further processing. BRIEF DESCRIPTION OF THE DRAWINGS Fig. Figure 1 shows a diagram of an exemplary electric vehicle according to embodiments of the present disclosure. Fig. Figure 2 represents a block diagram of example components of the electric vehicle according to the embodiments of the present disclosure. Fig. Figure 3 represents a block diagram of an exemplary communication system according to the embodiments of the present disclosure. Fig. Figure 4 represents a flowchart that describes the functionality for managing the status information of the electric vehicle according to embodiments of the present disclosure. Fig. Figure 5 represents a flowchart describing the functionality for event-driven or state-driven self-starting of an electric vehicle according to embodiments of the present disclosure. Fig. Figure 6 presents a flowchart describing the functionality for managing status information for an electric vehicle according to certain embodiments of the present disclosure. DETAILED DESCRIPTION

[0004] Existing communication systems lack a unified representation of the data states and services available across network devices and in-vehicle ECUs. Furthermore, applications running on these network devices and ECUs must constantly revise their underlying code to accommodate changes in data structures and application programming interfaces (APIs). Managing these platform and architecture variations becomes complex and cumbersome, making it difficult to share data and services across network devices and ECUs.

[0005] Embodiments of the present disclosure advantageously provide a vehicle communication system that includes a unified communication structure (also referred to as a secure data structure) that is simple, convenient, efficient, and less error-prone. The secure data structure encompasses data transmitted between network applications running on network devices and vehicle applications running on the ECUs, data transmitted between vehicle applications running on different ECUs, and data transmitted between vehicle applications running on the same ECU.

[0006] The network devices can include network servers, cloud-based network servers that provide cloud computing services, smartphones, personal computers, etc. The vehicle has a control system that includes a number of ECUs connected via an ECU bus. Each ECU includes one or more processors configured to run one or more software modules stored in memory. At least one ECU includes a wireless transceiver that may be paired with a wireless network (e.g., a cellular network, a Wi-Fi network, etc.) connected to a wide area network (WAN, e.g., the internet, etc.).

[0007] The network applications and the vehicle applications work together to provide a range of services within the communication system, such as backend services, user services, vehicle services, and so on. Specifically, the network devices and the ECUs in vehicles are nodes that form a distributed cluster for the secure data structure. Data is generated by "producer" applications running on the network devices or the ECUs in vehicles, transmitted over the secure data structure, and received by "consumer" applications running on the ECUs in vehicles or the network devices. The advantage is that an application connected to the secure data structure on one node can generate data that can be used by other applications connected to the secure data structure on any node.

[0008] The secure data fabric includes a messaging protocol and supporting infrastructure that provides a framework for producer applications to publish data and offer services to consumer applications, and for consumer applications to subscribe to published data and request services from producer applications. In certain embodiments, the communication messaging protocol implements the Neural Autonomous Transport System (NATS) protocol. In other embodiments, the communication messaging protocol may implement Apache Kafka, RabbitMQ, Apache Pulsar, gRPC, etc.

[0009] The communication system offers many technical advantages over existing ad-hoc communication techniques. The secure data fabric provides eventual data consistency (also known as "at-least-once" semantics) by making the most recent state of relevant data available to consumer applications, followed by the remaining states of that data. Alternatively, the secure data fabric can compress changes to data states down to the last known state, which is then made available to consumer applications. The secure data fabric provides partition tolerance, allowing nodes in the distributed cluster to operate independently and synchronize (opportunistically) based on their connectivity to the secure data fabric. When a data state changes, the secure data fabric provides asynchronous, flow-controlled event notifications to consumer applications.Data state changes can also be prioritized. In addition to data, a producer application can also provide services to consumer applications connected to the secure data fabric, similar to a remote procedure call (RPC).

[0010] Although aspects of the present disclosure are discussed in relation to an electric vehicle (EV), the disclosure supports any type of vehicle, such as an internal combustion engine vehicle (ICEV), a hybrid electric vehicle (HEV), etc.

[0011] Fig. Figure 1 shows a diagram of an exemplary electric vehicle 100 according to embodiments of the present disclosure.

[0012] The electric vehicle 100 includes, among other things, a frame and body 110, an electric energy storage and distribution system, a drive system, a suspension system, a steering system, a control system, auxiliary and accessory systems (such as thermal management, lighting, wireless communication, navigation, etc.), etc.

[0013] In general, the body 110 can be mounted directly or indirectly to a frame (i.e., body-on-frame construction) or the body 110 can be formed as a single unit with a frame (i.e., unibody construction). The body 110 includes, among other things, a front end 120, a front light bar 122, front turn signals 123, stadium light rings 124, headlights 126, a charging port 130 with a charging port cover 136 that conceals the charging port socket, a driver / passenger compartment or driver / passenger cabin 140, a cargo bed 150, a rear end 160 with taillights 162, a taillight bar, etc. The electric vehicle 100 can be a pickup truck, a sport utility vehicle (SUV) in which the cargo bed 150 is replaced by an extension of the cabin 140, or a sedan in which the cargo bed 150 is replaced by a trunk.In certain embodiments, the electric vehicle can be an electric delivery vehicle, an electric transporter, etc.

[0014] The drive system may include, among other things, one or more ECUs, one or more electric drive units (EDUs), front wheels 170, rear wheels 172, etc. The electrical energy storage and distribution system may include, among other things, one or more ECUs, a battery housing with a traction battery, a subsystem for charging the vehicle with a charging port 130, a high-voltage wiring harness connecting the traction battery to the other components of the high-voltage electrical system, such as the EDUs, etc.

[0015] An EDU with a single motor can be used to drive the front wheels 170 (front-wheel drive) or the rear wheels 172 (rear-wheel drive). Furthermore, an EDU with a single motor can be used to drive the front wheels 170 and an EDU with a single motor can be used to drive the rear wheels 172 (all-wheel drive). An EDU with a twin motor can be used to drive the front wheels 170 independently (independent front-wheel drive) or the rear wheels 172 independently (independent rear-wheel drive). Additionally, an EDU with a twin motor can be used to drive both front wheels 170 independently and an EDU with a twin motor can be used to drive both rear wheels 172 independently (independent all-wheel drive).

[0016] Fig. Figure 2 represents a block diagram of exemplary components of an electric vehicle 100 according to embodiments of the present disclosure.

[0017] In general, an electric vehicle 100 includes a control system 200 configured to perform the functions required to operate the electric vehicle 100. In certain embodiments, the control system 200 includes a number of ECUs 220 connected to the ECU bus 210 (e.g., a control area network or CAN bus, a local network or LAN, etc.). Each ECU 220 performs a specific set of functions and includes, among other things, one or more processors 222 connected to the memory 224 and the ECU bus interface (I / F) 226. The ECUs 220 may include the central gateway module (CGM) ECU 230, the telematics control module (TCM) ECU 240, the experience management module (XMM) ECU 250, etc.

[0018] The ECU bus 210 implements a message-based communication protocol over a physical infrastructure or layer. For example, the ECU bus 210 can be a CAN bus implementing ISO 11898 (CAN protocol) over a twisted-pair differential line carrying the CAN_H and CAN_L data signals. Alternatively, the ECU bus 210 can be a LAN implementing IEEE 802.3 (Ethernet protocol) over wired cables (such as CAT-8 Ethernet cable), fiber optic cables, etc. In some embodiments, the control system 200 can include an additional LAN 212 that connects specific ECUs 220, such as the TCM ECU 240, XMM ECU 250, etc. The LAN 212 can be configured to transfer data between these specific ECUs without affecting the data flow over the ECU bus 210.

[0019] The 222 processor can be a microcontroller unit, a microprocessor unit, a central processing unit (CPU), a programmable logic device (PLD), a complex PLD, a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), etc. The memory 224 can include volatile and non-volatile memory, such as random access memory (RAM), static RAM (SRAM), dynamic RAM (DRAM), read-only memory (ROM), flash memory, universal flash memory (UFS), solid-state drives (SSDs), etc. The processor 222 can run a real-time operating system (RTOS), such as VxWorks, Integrity, a proprietary RTOS, etc. In certain embodiments, one or more ECUs 220 can include one or more multi-core processors 222 running an operating system that supports high-volume multithreaded applications (such as Linux, Unix, BSD, etc.), etc., such as the TCM ECU 240, XMM ECU 250, etc.

[0020] In certain embodiments, the control system 200 can include a number of Systemon chips (SoCs). Each SoC can include a number of multi-core processors coupled with a high-speed interface and on-chip memory, providing more robust functionality and performance than a single ECU 220. Accordingly, each SoC can combine the functions provided by multiple ECUs 220.

[0021] The control system 200 can be coupled with sensors (such as cameras, radar sensors, ultrasonic sensors, etc.), actuators (such as electrical, hydraulic, pneumatic, etc.), input / output (I / O) devices, and other components within the drive system, the electrical energy storage and distribution system, the suspension system, the steering system, the auxiliary and accessory systems, etc., such as EDU 180, battery pack 190, etc.

[0022] The CGM ECU 230 provides a central communication hub for the electric vehicle 100. The CGM ECU 230 includes (or is coupled to) I / OI / F(s) 232 to receive data from various vehicle components, such as sensors, actuators, input devices, output devices, etc., and to send commands. The CGM ECU 230 also includes (or is coupled to) network I / F(s) 234 to provide network connectivity via ECU bus ports, local area networks (LIN), Ethernet ports, etc.

[0023] The CGM control unit 230 can forward messages (including commands, data, etc.) via the ECU bus 210 from one ECU 220 to another ECU 220, or from one ECU 220 to multiple ECUs 220 (e.g., broadcast messages, etc.). For example, the CGM ECU 230 can receive a message from a source ECU 220, process the message to determine the destination ECU 220, and then send the message to the destination ECU 220. Alternatively, the CGM ECU 230 can simply mediate the ECU bus 210 so that the source ECU 220 can send a message directly to the destination ECU 220.

[0024] The CGM control unit 230 can receive data from a sensor, I / O device, vehicle component, etc., and then send a message containing that data to the corresponding ECU 220 via the ECU bus 210. Likewise, the CGM ECU 230 can receive a message containing a command or data from an ECU 220 and then send the command or data to the corresponding actuator, I / O device, vehicle component, etc. Furthermore, the CGM ECU 230 can manage the vehicle mode (e.g., road driving mode, off-road mode, towing mode, camping mode, parking mode, etc.) and control certain vehicle components related to the transition between different vehicle modes.

[0025] The TCM ECU 240 provides a wireless communication hub for the electric vehicle 100. The TCM ECU 240 can include or be paired with a Bluetooth (BT) or Bluetooth Low Energy (BLE) transceiver 242, a WiFi transceiver 244, a cellular network transceiver 246 configured to send and receive data via a cellular connection, etc. The TCM ECU 240 can also include a Global Positioning System (GPS) receiver 248.

[0026] In certain embodiments, the control system 200 may also include, among others, the Autonomous Control Module (ACM), the Autonomous Safety Module (ASM), the Body Control Module (BCM), the Battery Management System (BMS), the Battery Power Insulation (BPI) ECU, the Equalizing Voltage Temperature (BVT) ECU, the Door Control Module (DCM), the Driver Monitoring System (DMS) ECU, the Near Field Communication (NFC) ECU, the Rear Zone Control (RZC) ECU, the Seat Control Module (SCM) ECU, the Thermal Management Module (TMM) ECU, the Vehicle Access System (VAS) ECU, the Winch Control Module (WCM) ECU, the Engine Control Unit (XCC) ECU, etc.

[0027] Fig. Figure 3 represents a block diagram of the communication system 300 according to embodiments of the present disclosure.

[0028] In certain embodiments, the communication system 300 includes, among other things, a network 310, one or more network servers 320 configured to run one or more applications 322 (e.g., a Manufacturing Execution System or MES, etc.), one or more mobile computing devices 330 (e.g., smartphones, tablets, laptop computers, etc.) configured to run one or more applications 332 (e.g., a smartphone app), and control system 200 ECUs 220, such as the TCM-ECU 240 with BT / BLE transceiver 242, WLAN transceiver 244, and cellular transceiver 246, XMM-ECU 250, etc. Each ECU 220 is configured to run one or more applications, service modules, etc. For example, TCM-ECU 240 can be configured to run the BrokerService 241, the TranslationService 243, the Application 245 and the DiagnosticClient 247, and XMM-ECU 250 can be configured to run the Application 255.Other diagnostic clients that perform the same or similar functionality as diagnostic client 247 can be hosted by other components of the communication system 300, such as a diagnostic client hosted by network server 320, diagnostic client 257 hosted by XMM-ECU 250, and so on.

[0029] The Network 310 can include one or more LANs, wireless LANs (WLANs), WANs (such as the internet, etc.), etc., which can run various network protocols, such as Ethernet, Bluetooth, WiFi, etc. The Network 310 can also include various combinations of wired and / or wireless physical layers, such as copper wire or coaxial cable networks, fiber optic networks, Bluetooth wireless networks, WiFi wireless networks, wireless CDMA, FDMA, and TDMA cellular networks, etc.

[0030] In certain embodiments, the Network Server 320 can be connected to a LAN (or corresponding LANs) that is connected to a WAN (such as the Internet, etc.). The BT / BLE Transceiver 242 can be connected to a Bluetooth network device, which in turn is connected to the LAN. The WiFi Transceiver 244 can be connected to a wireless WiFi network that is connected to the WAN. The Cellular Network Transceiver 246 can be connected to a CDMA, FDMA, or TDMA cellular network that is connected to the WAN. In general, Network 310 includes the LANs and WANs required to interconnect the Network Server 320 and the Electric Vehicle 100. Real-time vehicle condition monitoring and communication

[0031] Embodiments of the present disclosure advantageously provide real-time monitoring and communication of the vehicle's condition using an ECU 220 (such as TCM-ECU 240) to improve operational decision-making and efficiency. Condition information is passively and actively collected from the electric vehicle 100 and its components by broker service 241 to create an internal model of the vehicle's condition and its components. This information is then translated into actionable states or statuses that are accessible as subscriptions to applications running on ECUs 220 (e.g., application 245 running on TCM-ECU 240, application 255 running on XMM-ECU 250, etc.), other systems (such as application 322 (e.g., the MES) running on network server 320, etc.), user devices (e.g., application 332 running on mobile computing device 330), etc.

[0032] Certain features include real-time visibility of vehicle and component status, providing immediate access to detailed vehicle information. This enables operators to gain actionable insights and optimize workflows by providing detailed status updates. Direct feedback can be provided to automated systems both before and after an action is taken regarding status changes. Additional functionalities include adaptability to various environments where real-time status communication is essential, facilitating improved issue escalation, optimized quality control, and more efficient vehicle operation while driving or performing work.Furthermore, integration with quality control points and management systems is provided, ensuring consistent communication, reducing diagnostic time, and supporting decision-making through a standardized data framework.

[0033] For example, condition information (or status information) from Application 245 can be provided directly to Broker Service 241, which runs on TCM 240. The condition information can include vehicle data (e.g., one or more vehicle parameters, etc.) provided by Application 245, and Broker Service 241 publishes the condition information as one or more subscriptions that are available to other applications (e.g., Application 255, Application 322, Application 332, etc.). A subscription can include a single data point (e.g., a vehicle parameter), a set of related data points (e.g., related vehicle parameters), and so on.

[0034] State changes can be summarized and presented to operators in simple language, thus facilitating the communication and use of these changes. For example, battery voltage consumption can be displayed and, depending on the voltage range, converted to "OK" or "NOK" (not OK) for the operator. Translation and publication of vehicle communication signals into rate-limited change events that applications can subscribe to.

[0035] Advantageously, embodiments of the present disclosure provide translation service 243, which receives or intercepts CAN or Diagnostic over Internet Protocol (DoIP) messages from the ECU bus 210 (in raw UDP format), translates the intercepted CAN messages into refined signals defined by a CAN database (DBC), and then sends the refined signals to broker service 241 for publication via one or more subscriptions. Filters for "only on change" and automatic rate limiting of the data can be provided.

[0036] For example, status information from Application 255, running on XMM-ECU 250, can be indirectly provided to Broker Service 241, running on TCM 240, via ECO-Bus 210 and Translation Service 243. More precisely, Application 255 encodes status information as one or more CAN (or DoIP) messages, which are provided to ECU-Bus 210. Translation Service 243 intercepts the CAN messages on ECU-Bus 210 and converts them into data link interception signals. It then translates these data link interception signals into refined signals, which are provided to Broker Service 241 for publication as one or more subscriptions available to other applications (e.g., Application 245, Application 322, Application 332, etc.).

[0037] The advantage is that the data processing requirements of an application running on an ECU 220 are abstracted at every level below the signal listing, including the handling of redundant or recurring information. An application simply specifies which signals it needs from the ECU bus 210 and receives them only when they change and at a specific maximum rate of change. The use of all data traffic on the ECU bus 210 is permitted, and the translation of this traffic into published messages for internal ECU communication is predefined using specific names stored in a database, thus translating raw data into usable data.

[0038] For example, ECU bus 210 can include a signal containing battery voltage status information from an ECU 220 (e.g., the BMS ECU). Battery voltage data can be received, rate limiting can be applied, and subscribers and data brokers on the ECUs 220 can be notified when the battery voltage value changes. Subscription to vehicle condition and diagnostic data

[0039] In general, Broker Service 241 provides subscriptions to facilitate communication between ECUs 220 (e.g., TCM-ECU 240, XMM-ECU 250, etc.) and messages / events in Application 322 (e.g., the MES) running on the network server 320. Specifically, event-driven status or diagnostic data of the electric vehicle 100 is presented to the MES in real time, as is a way for the MES to present event-driven changes to the electric vehicle 100 in real time. Similarly, Broker Service 241 provides subscriptions to facilitate communication between ECUs 220 (e.g., TCM-ECU 240, XMM-ECU 250, etc.) and messages / events in Application 332 running on the mobile computing device 330.

[0040] For example, application 322 (e.g., the MES) can subscribe to status information provided by application 255, which runs on the XMM-ECU 250. Based on an analysis of the status information (and possibly other data), application 322 can decide to update the status information to reflect a more current view of the vehicle data (e.g., one or more vehicle parameters) mapped in the status information. Application 322 can send a status command via network 310 to diagnostic client 247, which runs on TCM-ECU 240, to update the status information provided by application 255. Diagnostic client 247 then sends the status command via ECU bus 210 to application 255, which runs on the XMM-ECU 250.

[0041] Application 255 can then decide whether Application 322 has permission to update the status information. If Application 322 is not authorized to update the status information, Application 255 sends a response to Diagnostic Client 247 indicating that the status command is not permitted. If Application 322 is authorized to update the status information, Application 255 attempts to change the status information based on the status command. If this is successful, Application 255 sends a response to Diagnostic Client 247 indicating that the status command was successful. If this is unsuccessful, Application 255 sends a response to Diagnostic Client 247 indicating that the status command was unsuccessful.

[0042] In some embodiments, diagnostic client 247 can send a response to application 322 indicating whether the status command was successful. If the status command was unsuccessful, application 322 can repeat the process by sending the status command again to diagnostic client 247 to update the status information provided by application 255. In some embodiments, application 322 can start a timer that, after a predetermined time, repeats the process by sending the status command again to diagnostic client 247 to update the status information provided by application 255, until the subscription indicates to the status information that the updated status information has been received by application 255 from broker service 241.

[0043] Similarly, application 245, running on TCM-ECU 240, can subscribe to status information provided by application 255. Based on an analysis of the status information (and possibly other data), application 245 can decide to update the status information to reflect a more current view of the vehicle data (e.g., one or more vehicle parameters) contained within the status information. Application 245 can send a status command to diagnostic client 247 to update the status information provided by application 255. And so on.

[0044] In general, a first application can update the status information provided by a second application, provided the first application has the necessary permissions to do so.

[0045] Applications running on ECUs 220, Network Servers 320, and Mobile Computing Devices 330 can establish close cohesion with event-driven, real-time data. For example, Applications 322 and 332 can subscribe to real-time event data from one or more ECUs 220 and create patterns or responses to changes in that data. Similarly, applications running on ECUs 220 (such as Applications 245, 255, etc.) can also subscribe to real-time event data published by Network Servers 320 and Mobile Computing Devices 330 and create patterns or responses to changes in that data.

[0046] For example, an electric vehicle 100 might have a door change state from an open position to a closed position. The ECU 220, which hosts the application for managing the door status, would send the status information via the ECU bus 210. This information would be intercepted by the translation service 243, converted into a data link intercept signal, and then translated into a refined signal that is provided to the broker service 241 for publication as one or more subscriptions available to other applications. A third-party system (such as the MES) that has subscribed to the door status from the electric vehicle 100 would be notified of the state change in real time at the time of the event. The MES can then use the door status to prevent a calibration from being performed.

[0047] In another example, the applications running on the ECUs 220 can retrieve status information describing the "production status" or the position in the factory provided by the MES, or even the vehicle owner ID directly from the MES in real time.

[0048] Fig. Figure 4 represents a flowchart 400 that describes the functionality for managing state information of electric vehicle 100 according to embodiments of the present disclosure.

[0049] In general, flowchart 400 represents the flow of information between certain components of the communication system 300, including the network server 320, TCM-ECU 240, ECU bus 210, and a generic ECU 220 (e.g., XMM-ECU 250). Time is represented by a vertical axis 402, which is assigned to each component of the communication system 300 and runs from the top to the bottom of the flowchart 400. Network server 320 executes application 322. TCM-ECU 240 executes broker server 241, translation service 243, application 245, and diagnostic client 247. ECU 220 executes application 225.

[0050] Sequence 410 generally represents status information flowing from application 322, application 245, and application 225 to broker service 241, as well as subscriptions (subscription information) flowing from broker service 241 to application 322, application 245, and application 225. Application 322 sends status information to broker service 241 and receives subscription information from it via network 310. Application 245 sends status information directly to broker service 241 and receives subscription information directly from it, as both components run on TCM-ECU 240.

[0051] Application 225 sends status information to Broker Service 241 and receives subscription information from it via ECU Bus 210. More precisely, Application 225 encodes status information as one or more CAN (or DoIP) messages, which are then provided to ECU Bus 210. Translation Service 243 intercepts the CAN messages on ECU Bus 210 and converts them into data link interception signals. It then translates these data link interception signals into refined signals, which are provided to Broker Service 241 for publication as one or more subscriptions available to other applications (e.g., Application 245, Application 322).

[0052] In certain embodiments, application 225 can periodically transmit status information over ECU bus 210 based on a cycle time, such as every second, every 5 seconds, etc. Translation service 243 intercepts the CAN messages on ECU bus 210 and converts them into data link interception signals. It then compares the current data link interception signals with the previous data link interception signals for application 225. If the current and previous data link interception signals are the same, then the status information has not changed, and translation service 243 does not translate the data link interception signals into more refined signals. In other words, translation service 243 skips the status update.

[0053] Generally, Broker Service 241 publishes status information as subscription information. As described above, a subscription can include a single data point (e.g., a vehicle parameter), a set of related data points (e.g., vehicle parameters), and so on. Each application can subscribe to one or more subscriptions provided by Broker Service 241. For example, Application 322 can subscribe to certain status information provided by Applications 245 and 225. Application 245 can subscribe to certain status information provided by Applications 322 and 225, and Application 225 can subscribe to certain status information provided by Applications 322 and 245.In certain embodiments, an application can analyze the status information provided by a particular subscription to determine whether the status information in that subscription should be updated.

[0054] Sequence 420 generally represents an analysis phase for application 322 and application 245, which each subscribe to status information from ECU 220.

[0055] For example, application 322 (e.g., the MES) can subscribe to status information provided by application 225, which runs on ECU 220. Based on an analysis of the status information (and possibly other data), application 322 can decide to update the status information to reflect a more current view of the vehicle data (e.g., one or more vehicle parameters) mapped in the status information.

[0056] Similarly, Application 245 can subscribe to status information provided by Application 225 running on ECU 220. Based on an analysis of the status information (and possibly other data), Application 245 can decide to update the status information to reflect a more current view of the vehicle data (e.g., one or more vehicle parameters) contained within the status information.

[0057] Sequence 430 generally represents a state instruction phase for application 322 and application 245, each subscribing to state information provided by application 225. While the following description uses application 322 as an example, the procedure is identical for application 245 in various embodiments.

[0058] Application 322 can send a status command to diagnostic client 247 via network 310 to update the status information provided by application 225. The status command includes updated status information. Diagnostic client 247 determines that the status command is associated with application 225, determines that application 225 is running on ECU 220, and sends the status command to application 225 running on ECU 220 via ECU bus 210.

[0059] Application 225 then determines whether Application 322 has permission to update the status information. If Application 322 does not have permission to update the status information, Application 225 sends a response to Diagnostic Client 247 indicating that the status command is not permitted. If Application 322 does have permission to update the status information, Application 225 attempts to change the status information based on the status command. If this is successful, Application 225 sends a response to Diagnostic Client 247 indicating that the status command was successful. If this is unsuccessful, Application 225 sends a response to Diagnostic Client 247 indicating that the status command was unsuccessful.

[0060] In some embodiments, diagnostic client 247 can send a response to application 322 indicating whether the status command was successful. If the status command was unsuccessful, application 322 can repeat the process by sending the status command to diagnostic client 247 to update the status information provided by application 225. In some embodiments, application 322 can start a timer that, after a predetermined time, repeats the process by sending the status command again to diagnostic client 247 to update the status information provided by application 225, until the status information subscription indicates that the updated status information has been received from application 225.

[0061] Sequence 440 generally represents updated status information flowing from Application 225 to Broker Service 241, and updated subscription information flowing from Broker Service 241 to Applications 322 and 245. As explained in relation to Sequence 410, Application 225 encodes updated status information as one or more CAN (or DoIP) messages delivered to ECU Bus 210. Translation Service 243 intercepts the CAN messages on ECU Bus 210 and converts them into data link intercept signals. It then translates the data link intercept signals into refined signals delivered to Broker Service 241 for release as updated subscription information to Applications 322 and 245. Event- and condition-driven self-startup

[0062] Embodiments of the present disclosure provide a method for electric vehicle 100 or a non-vehicle MES (e.g., Application 322) to initiate or complete vehicle commissioning steps using changes in the vehicle state or changes in production or assembly operations. In certain embodiments, a method defines and executes commissioning steps as an event response to changes in the vehicle state or to changes in the assembly process.

[0063] The commissioning steps can be performed either by the ECUs 220 of the electric vehicle 100 or by an external MES in a manner that abstracts the steps themselves. The commissioning steps can be defined with a list of preconditions and trigger events and executed in real time in response to changes in the preconditions or the occurrence of the trigger events. Automation enables the electric vehicle 100 to independently initiate critical manufacturing or service steps by responding to operator actions or changes in the meta-status of external systems. The MES can also complete follow-up actions based on changes in the vehicle's state to simplify automation and ensure precise feedback.A feedback loop allows repeated attempts and the status is only finalized upon successful completion, thus ensuring complete feedback control of the commissioning steps.

[0064] For example, an operator in the MES releases a factory release for a vehicle identification number (VIN), and this event can be used to control subtasks within application 225 that run on one or more ECUs 220 of electric vehicle 100 (e.g., application 245 running on ECU-TCM 240, application 255 running on ECU-XMM 250, etc.). In another example, an operator connects a seat assembly to electric vehicle 100, and this event (such as a change in the "seat connection status") can trigger a quality update in the MES, which then executes a commissioning task such as "calibrate front seat." Advantageously, the events can occur on the MES or on electric vehicle 100.

[0065] In another example, a transporter parks the electric vehicle 100 in a specific parking space. An ECU 220 can parse both the change in the driving cycle state and the current ownership status to enable automatic mode changes for energy saving.

[0066] In another example, after a final assembly step is completed, a notification can be sent to the MES indicating that electric vehicle 100 is ready for completion. The MES can use this event to trigger one or more commissioning steps on the vehicle, such as "activating the immobilizer," resetting user data, etc.

[0067] In another example, the resale of a vehicle with a change of ownership could trigger a notification of the status change from network server 320 to electric vehicle 100 and a commissioning step to "delete all previous private data".

[0068] In another example, an operator on an assembly line establishes a connection to the electric vehicle 100, thereby automating a response or notification in the MES to cancel a quality warning.

[0069] Fig. Figure 5 represents a flowchart 500 that describes the functionality for event-driven or state-driven self-starting of the electric vehicle 100 according to embodiments of the present disclosure.

[0070] In certain embodiments, an event 510 (such as a first event 512, second event 514, etc.) or a state update 520 (such as an update of the commissioning task status, etc.) can trigger a response 530 to the event 510 or the state update 520. Subsequently, prerequisites 540 can be checked to determine whether an action is required. If an action is required, the action is performed (550) and the action status is updated (560). For example, the action status can be updated to The action status can be updated to "completed" if the action has been completed, or it can be updated to "not completed" if the action has not been completed. If no action is required, the action status is simply updated to 460. For example, the action status can be updated to "completed," "not required," etc. The action status is then published to state update 520, which can trigger a further response 530 to state update 520, and so on.

[0071] As described above, the functionality shown in flowchart 500 can be performed by application 245, which runs on TCM-ECU 240, and / or by application 255, which runs on XMM-ECU 250. In other embodiments, the functionality shown in flowchart 500 can be performed by application 245, which runs on TCM-ECU 240, and / or application 255, which runs on XMM-ECU 250, in conjunction with application 322, which runs on network server 320 (e.g., the MES). In general, the functionality shown in flowchart 500 can be performed by one or more applications running on one or more ECUs 220, optionally in conjunction with application 322 (e.g. the MES) running on the network server 320, and / or an application 332 running on the mobile computing device 330.

[0072] Fig.Figure 6 represents a flowchart 600 that describes the functionality for managing state information for electric vehicle 100 according to certain embodiments of the present disclosure.

[0073] In general, the functionality for managing status information is performed by a processor 222 of an ECU 220, such as the processor of the TCM-ECU 240, which is configured to run broker service 241 and application 245. Blocks 620, 630, and 640 are performed by broker service 241, while blocks 650, 660, and 670 are performed by application 245.

[0074] In block 610, broker service 241 communicates with network server 320 via network 310.

[0075] In block 620, broker service 241 generates subscription information based on status information received from applications running on ECUs 220 coupled with ECU bus 210, such as application 255 running on XMM-ECU 250.

[0076] In block 630, broker service 241 transmits the subscription information to the applications running on the ECUs 220 that have subscribed to the subscription information, such as application 255.

[0077] In block 640, application 245 generates status information.

[0078] In block 650, application 245 sends the status information to broker service 241.

[0079] In block 660, application 245 receives subscription information from broker service 241.

[0080] The many features and advantages of the disclosure are evident from the detailed patent specification, and thus the attached claims are intended to cover all such features and advantages of the disclosure that fall within the scope of protection of the disclosure. Since numerous modifications and variations readily occur to those skilled in the art, it is furthermore undesirable to limit the disclosure to the exact construction and process illustrated and described, and accordingly, recourse may be had to all suitable modifications and equivalents that fall within the scope of protection of the disclosure.

Claims

[1] Control system for an electric vehicle, wherein the control system comprises: an electronic control unit (ECU) bus; and a variety of ECUs coupled to the ECU bus, including: a first ECU that is configured to: Running a broker service configured to communicate with a network server over a network; Generating subscription information based on status information received from applications running on the ECUs; Transmitting the subscription information to one or more applications running on the ECUs that have subscribed to the subscription information; and Executing a translation service configured to communicate with the broker service and the ECU bus; and a second ECU that is configured to: Running an application configured to transmit status information to the first ECU via the ECU bus; and Receiving subscription information via the ECU bus from the first ECU. [2] Control system according to claim 1, wherein the translation service is configured to: Receiving status information from the second ECU via the ECU bus in a first format; Converting the state information in the first format to state information in the second format; and Providing the status information in the second format to the broker service. [3] Control system according to claim 2, wherein the translation service is further configured to: Receiving additional status information from the second ECU via the ECU bus in the first format; Determine whether the additional state information differs from the state information; and If the additional state information differs from the state information, convert the state information in the first format to state information in the second format, and provide the state information in the second format to the broker service. [4] Tax system according to claim 1, wherein: the first ECU is further configured to run an application that is configured to: Generating status information; Sending the status information to the broker service; and Receiving subscription information from the broker service; where an application running on the network server is subscribed to the subscription information; and The broker service is further configured to transmit subscription information over the network to the application running on the network server. [5] Tax system according to claim 4, wherein the broker service is further configured to: Receiving additional status information from the application running on the network server; Generating additional subscription information based on the additional status information received from the network server; and transmitting the additional subscription information to the applications running on the ECUs that have subscribed to the additional subscription information. [6] Tax system according to claim 4, wherein: the first ECU is further configured to run a diagnostic client; and The diagnostic client is configured to: Receiving a status command from the application running on the network server, wherein the status command is associated with an application that transmits status information, and the status command includes updated status information; Determine which ECU runs the application, which transmits the status information; and Sending the status command via the ECU bus to the specific ECU. [7] Control system according to claim 6, wherein the application associated with the status command is configured to: Determine whether the status order is approved; If the status command is approved, change the status information to the updated status information; and Transferring the updated status information via the ECU bus to the first ECU. [8] Electronic control unit (ECU) for an electric vehicle, wherein the ECU comprises: a storage facility; and a processor coupled to the memory and an ECU bus, the processor being configured to: Running a broker service configured to: Communicating with a network server over a network, Generating subscription information based on status information received from applications, which are executed on ECUs coupled to the ECU bus, and Transmitting the subscription information to one or more applications running on the ECUs that have subscribed to the subscription information; Executing a translation service configured to communicate with the broker service and the ECU bus; and Running an initial application configured to: Generating status information, Sending the status information to the broker service, and Receiving subscription information from the broker service. [9] ECU system according to claim 8, wherein the translation service is configured to: Receiving status information from an application running on an ECU via the ECU bus, in a first format; Converting the state information in the first format to state information in the second format; and Providing the status information in the second format to the broker service. [10] ECU according to claim 9, wherein the translation service is further configured to: Receiving additional status information from the application running on the ECU via the ECU bus in the first format; Determine whether the additional state information differs from the state information; and If the additional state information differs from the state information, convert the state information in the first format to state information in the second format, and provide the state information in the second format to the broker service. [11] ECU according to claim 8, wherein: where an application running on the network server is subscribed to the subscription information; and The broker service is further configured to transmit the subscription information to the application running on the network server. [12] ECU according to claim 11, wherein the broker service is further configured to: Receiving additional status information from the application running on the network server; Generating additional subscription information based on the additional status information received from the network server; and Transmitting the additional subscription information to the applications running on the ECUs that have subscribed to the additional subscription information. [13] ECU according to claim 11, wherein: the processor is further configured to run a diagnostic client; and The diagnostic client is configured to: Receiving a status command from the application running on the network server, wherein the status command is associated with an application that transmits status information, and the status command includes updated status information; Determine which ECU runs the application, which transmits the status information; and Sending the status command via the ECU bus to the specific ECU. [14] ECU according to claim 13, wherein the diagnostic client is further configured to: Receiving updated status information from the application running on the specific ECU via the ECU bus. [15] Method for managing status information for an electric vehicle, the method comprising: Communicate, via a broker service running on an electronic control unit (ECU) coupled to an ECU bus, with a network server over a network, Generate, via the broker service, subscription information based on status information received from applications running on ECUs coupled to the ECU bus, and Transmit, via the broker service, subscription information to one or more applications running on the ECUs that have subscribed to the subscription information; Generating, through an initial application executed on the ECU, status information, Sending, through the application, the status information to the broker service and Received, through the application, subscription information from the broker service. [16] The method of claim 15, further comprising: Received, via a translation service running on the ECU, which translates status information from an application running on an ECU over the ECU bus in a first format; Convert, via the translation service, the status information in the first format to status information in the second format; and Provide, via the translation service, the status information in the second format to the broker service. [17] The method of claim 16, further comprising: Received, via the translation service, additional status information from the application running on the ECU via the ECU bus in the first format; Determine, via the translation service, whether the additional status information differs from the status information; and If the additional state information differs from the state information, convert, via the translation service, the state information in the first format into state information in the second format, and provide the state information in the second format to the broker service. [18] Method according to claim 15, wherein: where an application running on the network server is subscribed to the subscription information; and The procedure further includes the transmission, via the broker service, of subscription information to the application running on the network server. [19] The method of claim 18, further comprising: Receive, via the broker service, additional status information from the application running on the network server; Generate, via the broker service, additional subscription information based on the additional status information received from the network server; and Transmit, via the broker service, the additional subscription information to the applications running on the ECUs that have subscribed to the additional subscription information. [20] The method of claim 18, further comprising: Receiving, via a diagnostic client, a status command from the application running on the network server, wherein the status command is associated with an application that transmits status information, and the status command includes updated status information; Determine, via the diagnostic client, which ECU is running the application, which transmits the status information; Sending the status command to the specific ECU via the ECU bus, using the diagnostic client; and Received, via the diagnostic client, updated status information from the application running on the specific ECU, via the ECU bus.

Images