DE102015113436A1 - Method and device for activating and logging event data recording - Google Patents

Abstract

A system includes a processor that is configured to detect a condition indicating that event data recording (EDR) should begin. The processor is further configured to start the event data record and continue for a predetermined period of time after the condition. In addition, the processor is configured to store data recorded by the event data record when the predetermined amount of time has elapsed and no serious incident has been detected. The processor is also configured to upload the data to a remote system as soon as a connection to the remote system can be made.

Description

TECHNICAL AREA

The exemplary embodiments generally relate to a method and apparatus for activating and logging event data recording (EDR).

BACKGROUND

Similar to a black box in an airplane, many vehicles include an event data recorder that allows the recording of vehicle data when an accident occurs, the recording when determining vehicle characteristics (eg, speed, malfunction of parts, traction conditions, etc.) can have helped to the accident can be helpful. Currently, most EDRs are used as a storage device for recording a snapshot of data surrounding an accident event. Typically, EDRs have thresholds that determine when recording begins. These thresholds are typically related to conditions that are likely to lead to an accident. In many cases, recordings are started and then later overwritten because the vehicle operating mode exceeded one or more initiation thresholds, but in fact no accident occurred. In these cases, the EDR data is not locked for retrieval, but overwritten by later EDR events when another threshold is exceeded.

U.S. Patent 8,139,820 relates generally to exceptional event recorders and analysis systems, comprising: vehicle mounted sensors configured as vehicle event recorders to capture both discrete and non-discrete data; a discretizer; a database and an analysis server, all of which are coupled as a computer network. Motor vehicles with video cameras and on-board diagnostic systems collect data when the vehicle is involved in an accident or other anomaly (an "event"). Station internally, ie in a discretization facility where interpretation of non-discrete data occurs, collected data is used as a basis for generating discrete supplementation data for further characterization of the event. Such interpreted data is combined with captured data and entered into a database in a structure that is searchable and which supports logical or mathematical analysis by automated machines. A coupled analysis server is designed to check the stored data for prescribed conditions and, if found, to take further actions appropriate to the identified condition.

US Application No. 2006/0212195 generally relates to a vehicle data recorder capable of continuously recording and storing selected data on both driver and vehicle performance including, but not limited to, miles traveled, speed, acceleration / deceleration, Brake activation, seat belt use, vehicle direction, steering anomalies, global position, impact forces and direction, transmission status, and alcohol use. In particular, this recording apparatus has expanded data storage capacity, alcohol key lock, real-time GPS data, low-power cellular telephone noise, and internal wireless communication capabilities. It uses microprocessor-based electronics to record, store and transmit both driver and vehicle performance data in a date and time stamped file used to create personalized insurance premiums, set vehicle tax and toll charges, find "amber alert" victims or stolen Vehicles and, with their on-site access, providing critical injury information mechanisms for emergency workers can be used.

SUMMARY

In a first exemplary embodiment, a system includes a processor configured to detect a condition indicating that event data recording (EDR) should begin. The processor is further configured to start the event data record and continue for a predetermined period of time after the condition. In addition, the processor is configured to store data recorded by the event data record when the predetermined amount of time has elapsed and no serious incident has been detected. The processor is also configured to upload the data to a remote system as soon as a connection to the remote system can be made.

In a second exemplary embodiment, a system includes a processor configured to receive variable input data from a plurality of wirelessly connected vehicles. The processor is further configured to compare the received variable input data to predetermined thresholds to determine whether a condition that is likely to initiate event data recording (EDR) is imminent in one of the plurality of vehicles. In addition, the processor is configured to issue an instruction to the vehicle to warn the driver Motorist, for each vehicle in which the condition is imminent. The processor is also configured to issue a request to each vehicle for which the condition is imminent requesting event data recording. The processor has also been configured to collect data recorded by the requested event data record (s).

In a third exemplary embodiment, a computer-implemented method includes detecting a condition indicating that event data recording (EDR) should begin. The method further comprises starting and continuing the event data record for a predetermined period of time after the condition. In addition, the method includes storing the data recorded by the event data record when the predetermined period of time has elapsed and no serious incident has been detected. The method further includes uploading the data to a remote system as soon as a connection to the remote system can be made.

BRIEF DESCRIPTION OF THE DRAWINGS

1 Fig. 10 illustrates an exemplary vehicle computer system;

2 represents an illustrative example of EDR monitoring;

3 FIG. 10 illustrates an illustrative example of a driver alert process; FIG. and

4 represents another illustrative example of EDR monitoring.

DETAILED DESCRIPTION

As required, detailed embodiments of the present invention are disclosed herein; however, it should be understood that the disclosed embodiments are merely examples of the invention which may be embodied in various and alternative forms. The figures are not necessarily to scale; some features may be exaggerated 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 a representative basis for the teaching of those skilled in the art through various uses of the present invention.

1 illustrates an example block topology for a vehicle-based computer system 1 (VCS) for a vehicle 31 , An example of such a vehicle based computer system 1 is the SYNC system manufactured by THE FORD MOTOR COMPANY. A vehicle provided with a vehicle-based computer system may have a front-end graphical interface 4 included, which is arranged in the vehicle. The user may also be able to interact with the interface if, for example, it is provided with a touch screen. In another exemplary embodiment, the interaction is done by pressing keys, a linguistic dialog system with automatic speech recognition and speech synthesis.

In Exemplary Embodiment 1, which is shown in FIG 1 is shown controls a processor 3 at least some of the operation of the vehicle-based computer system. The processor provided within the vehicle enables on-board processing of commands and routines. Further, the processor is both non-persistent 5 as well as a stable memory 7 connected. In this exemplary embodiment, the non-persistent storage is random access memory (RAM), and the persistent storage is a hard disk drive (HDD) or flash memory. In general, a persistent (non-transitory) memory can include all forms of memory which preserve data when a computer or other device is turned off. These include, but are not limited to, HDDs, CDs, DVDs, magnetic tapes, portable USB drives, and any other suitable form of persistent storage.

The processor is also provided with a number of different inputs that allow the user to interface with the processor via an interface. In this exemplary embodiment, a microphone 29 , an aux-entry 25 (for input 33 ), a USB input 23 , a GPS input 24 , a screen 4 which can be a touchscreen display, and a BLUETOOTH input 15 intended. It is also an input selector 51 provided to allow a user to switch between different inputs. Both the input to the microphone and the aux connector is through a converter 27 converted from analog to digital before being passed to the processor. Although not shown, many of the vehicle components and accessory components in communication with the VCS may use a vehicle network (such as, but not limited to, a CAN bus) to relay data to or from the VCS (or components thereof).

Outputs to the system can be a visual indicator 4 and a speaker 13 or a stereo system output, without being limited thereto. The speaker is with an amplifier 11 connected and receives its signal from the processor 3 through a digital-to-analog converter 9 , The output can be used together with the bi-directional data streams at 19 respectively. 21 to a remote BLUETOOTH device, such as a PND (personal navigation device). 54 , or a USB device, such as a car navigation system 60 , respectively.

In an exemplary embodiment, the system uses 1 the BLUETOOTH transceiver 15 to connect to a nomadic device (ND) 53 of a user (eg cellular phone, smartphone, PDA or any other device connected to a wireless remote network) 17 , The mobile device can then be used to connect to a network 61 outside the vehicle 31 for example through communication 55 with a mobile phone mast 57 to communicate 59 , In some embodiments, the mast 57 be a WiFi access point.

Exemplary communication between the mobile device and the BLUETOOTH transceiver is through the signal 14 shown.

The coupling of a mobile device 53 and the BLUETOOTH transceiver 15 can by a button 52 or a similar input. Accordingly, the CPU is directed to pair the BLUETOOTH transceiver on-board with a BLUETOOTH transceiver in a mobile device.

For example, data may be generated using a data plan, data-over-voice or DTMF tones using the mobile device 53 are associated, between the CPU 3 and the network 61 be communicated. Alternatively, it may be desirable to have an onboard modem 63 with an antenna 18 involve data between the CPU 3 and the network 61 to communicate over the voice band 16 , The mobile device 53 can then be used to connect to a network 61 outside the vehicle 31 for example through communication 55 with a mobile phone mast 57 to communicate 59 , In some embodiments, the modem 63 communication 20 with the mast 57 to communicate with the network 61 produce. As a non-limiting example, the modem 63 be a cellular USB modem, and communication 20 can be cellular communication.

In an exemplary embodiment, the processor is provided with an operating system that includes an API to communicate with modem application software. The modem application software may access an embedded module or embedded firmware on the BLUETOOTH transceiver to perform wireless communication with a remote BLUETOOTH transceiver (such as that found in a mobile device). Bluetooth is a subset of IEEE 802 PAN (Personal area network) logs. IEEE 802 LAN (Local Area Network) protocols include WiFi and have significant cross-functionality with IEEE 802 PAN. Both are suitable for wireless communication within a vehicle. Other means of communication that can be used in this area are open-space communication (such as IrDA) and non-standard consumer IR protocols.

In another embodiment, the mobile device includes 53 a modem for voice band or broadband data communication. In the data-over-voice embodiment, a technique known as frequency division multiplexing may be implemented when the owner of the mobile device can talk over the device while data is being transmitted. At other times, when the owner is not using the device, the data transfer can use the full bandwidth (300 Hz to 3.4 kHz in one example). Although the frequency division multiplexing method for analog cellular communication between the vehicle and the Internet may be common and still in use, it has been essentially replaced by code division multiple access (CDMA), time division multiple access (TDMA), space division digital access (SDMA) for digital cellular communication. These are all ITU IMT-2000 (3G) compliant standards and offer data rates of up to 2 Mbps for both inbound and outbound users and 385 kbps for users in a moving vehicle. 3G standards are now being replaced by IMT-Advanced (4G), which offers 100 Mbps for users in a vehicle and 1 Gbps for stand-by users. If the user has a data plan associated with the mobile device, it is possible that the data plan will allow broadband transmission and the system could use a much wider bandwidth (speeding up data transfer). In yet another embodiment, the mobile device is 23 replaced by a cellular communication device (not shown) in the vehicle 31 is installed. In still another embodiment, the ND 53 a wireless local area network (WLAN) device capable of, for example, and without limitation, communication over an 802.11g network (ie, WiFi) or a WiMax network.

In one embodiment, incoming data may be received by the mobile device via data-over-voice or a data plan by the onboard BLUETOOTH transceiver and into the in-vehicle processor 3 be transmitted. In the case of certain temporary data, for example, the data may be on the HDD or another storage medium 7 stored until the data is no longer needed.

Additional sources that may be interfaced with the vehicle include a mobile navigation device 54 for example with a USB port 56 and / or an antenna 58 , a vehicle navigation device 60 with a USB 62 or another connection, a GPS device 24 on board or a remote navigation system (not shown) with connectivity to the network 61. USB is a class of serial network protocols. The serial IEEE 1394 (FireWire ^™ (Apple), i.LINK ^™ (Sony) and Lynx ^™ (Texas Instruments)), EIA (Electronics Industry Association) serial protocols, IEEE 1284 (Centronics Port), S / PDIF (Sony / Philips Digital Interconnect Format) and USB-IF (USB Implementers Forum) form the backbone of serial device device standards. Most of the protocols can be implemented for electrical or optical communication.

Furthermore, the CPU could come with a host of other accessories 65 to be in communication. These devices can be powered by a wireless 67 or wired 69 Be connected. The accessories 65 may include, but is not limited to, personal media players, wireless medical devices, portable computers, and the like.

Additionally or alternatively, the CPU could be used, for example, using e.g. IEEE 803.11 ) 71 Transceiver with a vehicle-based wireless router 73 be connected. This could allow the CPU to connect to remote networks within reach of the local router 73 enable.

In addition to exemplary processes being performed by a vehicle-based computer computer system, in certain embodiments, the example processes may be performed by a computer system in communication with a vehicle computing system. Such a system may include, but is not limited to, a wireless device (eg, and without limitation, a mobile phone) or a remote computer system (eg, and without limitation, a server) connected by the wireless device. Together, such systems may be referred to as vehicle associated computing systems (VACS). In certain embodiments, certain components of the VACS may execute certain portions of a process, depending on the particular implementation of the system. As an example, and without limitation, when a process includes a step of sending or receiving information with a paired wireless device, it is likely that the process will not perform the wireless device because the wireless device does not have information on and of itself Would send and receive. One of ordinary skill in the art will recognize when it is inappropriate to apply a particular VACS to a particular solution. In all solutions, it is contemplated that at least the vehicle computing system (VCS) located within the vehicle may self-execute the example processes.

In each of the exemplary embodiments discussed herein, an illustrative, non-limiting example of a process that may be performed by a computer system is illustrated. With respect to each process, it is possible for the computer system executing the process to be configured as a specialized processor for performing the process for the limited purpose of executing the process. Not all processes must be performed in their entirety, but are to be understood as examples of types of processes that may be performed to achieve elements of the invention. Additionally, steps to the example processors may be added or removed as desired.

In the illustrative example which is in 2 is shown, an EDR monitoring process is shown. In most EDR triggering situations, the data stored by the EDR is discarded because an actual accident requiring the use of the EDR data does not occur. For example, without limitation, when a driver is performing a full brake on a vehicle, this sudden stall or sudden pitching motion of the vehicle may trigger the EDR system.

Since it is desirable to collect data before an actual accident, the EDR system often begins at some point prior to a recording accident. Since it is impossible to know when an actual accident occurs, the EDR system generally begins recording when a precursor event occurs that indicates a potential accident. This could include, but is not limited to, out-of-control of the vehicle, rapid deceleration, pitching of the vehicle over one certain angles or other events that indicate that an accident is imminent.

If the precursor event does not result in an accident, the EDR generally discards the recorded data simply because no accident was detected and no data is needed to analyze the possible cause of the accident. However, in the exemplary embodiments, it is desirable to preserve the EDR data for future analysis.

By using stored EDR data, fleet operators can tell which drivers or vehicles are in the immediate vicinity of possible accidents. That is, operators can determine which drivers or vehicles are likely to cause accidents or be involved in accidents even when no accidents actually occur.

In addition, storing and analyzing EDR data can more easily identify conditions that cause pre-accident triggers. For example, when braking wear leads to vehicles with high EDR triggers, this can be more easily observed if other additional EDR data is stored than if an actual accident occurred.

In the illustrative example which is in 2 is shown, the process monitors the start of the EDR system 201 , As previously mentioned, this may be, for example, any event or vehicle condition that causes the EDR system to begin recording data. As long as the EDR system has not started to record data 203 , the process continues to monitor for the beginning of the recording state. Once the recording condition has been triggered, the process continues.

With respect to the exemplary embodiments described in this figure, it should be noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods set forth herein. In executing code that provides instructions for performing some or all steps of the method, the processor may be temporarily converted to a special purpose processor by the time the method is completed. In another example, appropriately functioning firmware that operates in accordance with a preconfigured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or an appropriate variant thereof.

At the time when the recording state starts in this illustrative example, operator data is stored 205 , This data can be used to assess a tendency of a particular operator to trigger EDR recording conditions. Such an analysis may be useful to a fleet manager in checking personnel. It also stores environmental data measured by vehicle sensors and available from third party vendors. For example, without limitation, rainfall conditions, temperatures, road friction conditions, and other environmental data may be monitored to analyze which environmental data typically triggers or triggers an EDR recording condition (and thus a potential accident).

Vehicle status data is also stored for this second point 207 so that vehicle conditions can be monitored. This may help to determine which vehicle conditions (low fuel reserve, low tire pressure, unbalanced charge, etc.) could typically lead to initiation of EDR recording.

When a serious event (eg an accident) occurs 209 , the process may then lock all recorded data for use by technicians for post-accident analysis 213 , This is similar to the current function of the EDR, where an accident causes preservation of current EDR data.

If there is no serious event, but the EDR conditions for recording continue 215 , the process continues to record all corresponding state data until there are no more EDR recording conditions or until a serious event occurs.

In the current EDR systems, the system clears the data as soon as there are no more recording conditions, thus preventing analysis of the data in non-accident situations. However, in the exemplary embodiments, as soon as the EDR system stops recording the data, the processor stores data for later uploading it to a remote system for analysis, even if no serious event has occurred.

For example, if or when the local recording system is connected by a vehicle computer using a wireless connection to a wireless telephone to connect to the remote server, the process uploads the data to the remote server 223 , If no connection is made 219 For a while, the process can try one Make connection 221 , If still disconnected, the process may return to monitoring and recording and upload the data at a future time when a connection is made.

In the illustrative example which is in 3 is shown, a driver monitoring process is shown. In this example, driver states and vehicle conditions may be monitored to determine if an EDR trigger condition is imminent. Based on the observed triggers for EDR recording (either general or specific to that driver / vehicle), the process may observe vehicle state changes and determine whether a start of an EDR condition is likely.

With respect to the exemplary embodiments described in this figure, it should be noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods set forth herein. In executing code that provides instructions for performing some or all steps of the method, the processor may be temporarily converted to a special purpose processor by the time the method is completed. In another example, appropriately functioning firmware that operates in accordance with a preconfigured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or an appropriate variant thereof.

In this illustrative example, the processor identifies an operator 303 , Environment variables 305 and vehicle conditions 307 as soon as the vehicle is started 301 , These data are used to compare with known variable conditions that can initiate EDR recording conditions (identify potential imminent accidents).

In addition, variables are loaded in this illustrative example 309 which can cause the onset of EDR recording conditions. These may be general variables (eg vehicle speed) or driver or vehicle specific variables. In some cases, general variables may have values associated with them that are based on a driver or vehicle, according to which values generally the occurrence of EDR recording conditions for a specific driver or vehicle is observed. In other cases, the variables may have general thresholds associated therewith, generally resulting in EDR states.

For example, it can be observed that when the driver is Joe, an EDR condition generally occurs with an accumulated amount of snow on the road of more than one inch. Thus, for this driver, a snow amount environment variable may have a one inch threshold. It can also be observed that over 128 kilometers per hour (eighty miles per hour) all drivers experience EDR conditions more frequently, so a speed variable may have a limit of 128 km / h associated with it.

Once all identifiers and variables have been loaded (along with the appropriate thresholds), the process can be used to monitor driving parameters 311 kick off. This may concern both the driving conditions of the vehicle and the environmental conditions under which the vehicle is traveling. For example, the process may also monitor driver attention conditions when such monitoring is available.

Each one of the monitored parameters may be compared to the thresholds associated with the hazardous condition variables 313 , This data can be used to determine if a variable or variable is indicative of the likely beginning of a pre-accident EDR recording condition. If there is a match between the hazard state parameters and the variables 315 , the process can report the variable thresholds to the driver 317 that have been exceeded (for example, without limitation "speed above a safety threshold" or "snow accumulation can make driving dangerous"). If the driver is able to control the variable, the driver may in response, bring the condition below the threshold, although in some cases the best the driver can do is to take further precautions as the driver can not actually change the weather.

4 Figure 4 illustrates an illustrative example of a cloud-based data analysis and EDR start-up process. In this illustrative example, a plurality of vehicles report to a cloud-based system that performs variable analysis and can request EDR logging if desired for data in particular state vehicles further analysis are desired.

With respect to the exemplary embodiments described in this figure, it should be noted that a general purpose processor may be temporarily activated as a special purpose processor for the purpose of performing some or all of the example methods set forth herein. When executing code, the instructions for performing some or all steps of the procedure can be temporarily converted into a special processor by the time the procedure is completed. In another example, appropriately functioning firmware that operates in accordance with a preconfigured processor may cause the processor to act as a special purpose processor provided for the purpose of performing the method or an appropriate variant thereof.

In this example, the process requests vehicle data from one or more connected vehicles that are in communication with the remote system 401 , For each vehicle from which data was requested, the data is collected and received 403 , These data may include, but are not limited to, speed data, weather data, driver data, and generally any data that would be useful in analyzing likely upcoming EDR conditions or that would be useful in analyzing vehicle conditions that cause vehicle problems.

The collected data can then be compared generally with thresholds for known EDR start conditions 405 that tend to indicate whether the system is likely to trigger a condition under which EDR recording occurs or not. The general nature of the comparison here means that the data is compared to thresholds for all vehicles / drivers or for a class of vehicles / drivers.

When a match is found based on the collected data 407 that an EDR condition may be imminent, the process may warn the driver 409 , This could be in any suitable form including, but not limited to, a visual warning, an audible warning, etc. In addition, a warning would be issued to a fleet operator for the specific vehicle, if desired.

The process may also direct EDR record at the time the condition is detected 411 , This may help to preserve data to show what conditions occurred after the warning and help determine whether the driver has taken preventive action or continued driving in the same manner. The data could also be used to compare with previously observed data to show whether the output of the alert was appropriate and / or reduced the likelihood of an actual accident, as can be observed from the recorded EDR data. Since the actual EDR onset can be avoided by issuing the alert, it may be useful to see to what degree the actual behavior changes occurred.

In addition to the general comparison, the process may also compare the received data with known variables corresponding to the driver specific thresholds that trigger an EDR record for a specific driver or vehicle 413 , This can help to determine likely upcoming EDR recording conditions for a specific driver or vehicle.

If there is a match 415 , the process returns a message again 417 , The notification may be made to the appropriate participant and in the appropriate form (s). In addition to the message output, the process can again command an EDR recording 419 to judge the driver's reaction to the message.

If no EDR record has been instructed in this process 421 , the process ends. However, when the EDR record has been instructed, the process requests the recorded EDR data from the corresponding vehicle (s) and stores / analyzes the data as needed as soon as the data is received.

Following are a number of EDR-related scenarios that use the EDR data and preserved variables. These are for illustrative purposes only and are not intended to limit the scope of the invention in any way.

Example 1:

• Actuators: Telematics Control Unit (TCU)
• Prerequisites: The TCU is awake and in operation, the TCU is configured to support 1-wire with driver ID.
• Description of Scenario: The TCU continuously monitors 1-wire network for connection of a driver identification device for a predetermined and configurable duration after the transition of the ignition to an OPERATION / ON position. The TCU sends a message and data when the driver identification device is found.

Process:

• 1) After the ignition is switched to OPERATION / ON, the TCU activates a timer of fixed and configurable duration and continuously monitors the application of a driver identification device in the 1-wire network.
• 2) When the TCU detects the connection of a 1-wire driver identification device, the TCU issues a driver ID message and generates the following data bundles: 1-wire, VSTAT, and GPS info bundles.
• 3) The TCU sends the message and the data to the ESB or the web service.
• 4) If the TCU does not read or recognize a driver identification device prior to the expiration of the persistent timer, the TCU issues a driver ID error message, which also includes VSTAT and GPS info bundles.
• 5) The TCU outputs the error message and the data bundles to the ESB or the web service.

• Post-conditions: The TCU is ready to recognize another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 2

• Actuators: TCU module
• Prerequisites: The TCU is awake and in operation, the TCU is configured to support 1-wire with temperature sensor.
• Scenario description: For a predefined and configurable cadence, the TCU periodically prompts 1-wire temperature sensors to provide data. The TCU then issues a message and sends data to the ESB or the web service. The TCU sends an error message if a temperature sensor does not respond to a request.

Steps:

• 1) The TCU periodically requests temperature sensors connected to the 1-wire network to provide temperature data. The prompts are issued at a predetermined and configurable rate.
• 2) Upon receiving a response from the temperature sensor, the TCU generates a message and collects or forms the following data bundles: 1-Wire, VSTAT, and GPS Info Bundles.
• 3) The TCU outputs the message and the data bundles to the web service or ESB.
• 4) If a response from one of the temperature sensors connected to the 1-wire network is not received after a configurable number of retry attempts, the TCU will issue an error message and include VSTAT and GPS info bundles.
• 5) The TCU sends the error message and the data bundles to the web service or ESB.

• Post-conditions: The TCU is ready to recognize another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 3

• Actuators: TCU module
• Prerequisites: The TCU is awake and operational, the TCU is configured to be ACTIVE, the TCU is configured to detect output events.
• Scenario description: The TCU continuously monitors the status of the external hardwired outputs during all TCU operation and performance modes. If the TCU is commanded by the ESB or the web service, or if it internally determines that an exit must work. The TCU sends the message and the data to the web service.

Steps:

• 1) Upon receipt of an OTA command issued by the web service / ESB or internal decision by the TCU to enable or disable an output. The TCU forms an outgoing message and collects the following data bundles: VSTAT and GPS info bundles.
• 2) The TCU outputs the message and the data bundles to the web service or ESB.
• 3) If the TCU fails to activate the TCU as required, the TCU will issue an output error message and VSTAT- u. GPS Info Bundle off.
• 4) The TCU outputs the error message and the bundles to the web service / ESB.

• Post-conditions: The outgoing message and the data have been sent to the web service, the TCU is ready to recognize another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 4

• Actuators: TCU module
• Prerequisites: The TCU is awake and ready, the TCU is configured to be active (configured to provide messages ... inactive: the TCU does not provide messages), the TCU is configured to receive onboard warnings provides.
• Scenario description: The TCU issues a message to the web service if the TCU has issued an onboard alert to the operator.

Steps:

• 1) When an onboard alert is issued, the TCU issues a message to the ESB or the web service.
• 2) The TCU forms the following data bundles: VSTAT- u. GPS info bundle.
• 3) If the TCU fails to perform the onboard warning as required, the TCU will issue an onboard warning error message and VSTAT-u. GPS Info Bundle off.
• 4) The TCU outputs the message and the bundles to the web service / ESB.

• Post Conditions: The onboard alert message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 5

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active.
• Scenario description: The TCU continuously monitors the status of all external hardwired inputs to the TCU during all TCU operation and performance modes. When the TCU detects a state change indicating that an external device connected to the input port of the TCUs has been activated or deactivated, the TCU sends a message and data to the web service.

Steps:

• 1) When a change in state on a hardwired input to the TCU is detected, the TCU issues a warning and collects the following data bundles: VSTAT and GPS Info.
• 2) The TCU outputs the message and the data bundles to the web service or ESB.

• Post Conditions: An input message code and snapshot data has been sent to the web service, the TCU is ready to detect another message.

Example 6

• Actuators: TCU module
• Prerequisites: The TCU is awake and operational, the vehicle ignition status is "Power On", "Accessory On Mode" or "Operation", the TCU has been configured to provide driver safety messages.
• Scenario description: The TCU monitors the HSCAN network traffic of the vehicle or performs internal calculations or comparisons when the TCU has determined that a driver safety condition or a driver safety event has started or ended. The TCU generates a driver security message and notifies the service provider at the beginning and end of each event.

Steps:

• 1) The TCU is configured to provide driver safety messages.
• 2) According to requirements, when the TCU recognizes the beginning or end of a safety or behavioral driving condition. The TCU generates a driver safety message.
• 3) The TCU collects driver safety, VSTAT u GPS info bundles.
• 4) The TCU generates a message code and the data bundles and outputs a record to the ESB or the web service.

• Post-conditions: The TCU is ready to detect another message, the TCU has sent the driver safety message, the TCU has sent the VSTAT bundle, the TCU has received the GPS info. Driver security bundle sent.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 7

• Actuators: TCU module
• Prerequisites: The TCU is ready, both onboard and offboard clients are connected, and the TCU is configured to support output devices.
• Scenario description: The web service issues a command to the TCU to enable or disable a hardwired TCU output. The TCU executes the command and responds with a response indicating whether the command was successful.

Steps:

• 1) The web service issues a command to prompt the TCU to enable or disable an output.
• 2) The TCU receives the command and executes the requested procedures to enable or disable the TCU output.
• 3) After executing the command or attempting to execute the command, the TCU will issue a response message to the web service, see Use case for outbound message.

• Post Conditions: The TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 8

• Actuators: TCU module
• Prerequisites: The TCU is ready, both onboard and offboard clients are connected, and the TCU is configured to support onboard alerts.
• Scenario description: The web service issues a command to the TCU to enable an onboard alert to an operator. The TCU executes the command and responds with a response indicating whether the command was successful.

Steps:

• 1) The web service issues a command to prompt the TCU to issue or stop an onboard alert.
• 2) The TCU receives the command and executes the requested procedures to enable or disable the onboard alert.
• 3) After executing the command or attempting to execute the command, the TCU issues a response message to the web service, see Use case for on-board alert message.

• Post-conditions: The TCU issued the warning and replied to the WEB services whether it was done or not.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 9

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Description of the scenario: The web service has issued a diagnostic command to run a diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the request status and the required data.

Steps:

• 1) The web service issues a command to prompt the TCU to run a diagnostic service.
• 2) The TCU performs the diagnostics service contained in a DiagDataFromCloud data bundle sent by the web service or the ESB.
• 3) After the execution of the service request or the attempted execution of the service request, the TCU collects the diagnostic response from the destination ECU.
• 4) The TCU packs the diagnostic response (s) into a DiagDataFromVehicle data bundle.
• 5) The TCU issues a diagnostic data message with the DiagDataFromVehicle data bundle to the web service.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has submitted the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 10

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Description of the scenario: The web service has issued a diagnostic command to repeat the execution of a diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the status of the request and requested data. The TCU executes the command with the specified cadence until the TCU receives a command to terminate the service request.

Steps:

• 1) The web service issues a command to prompt the TCU to run a diagnostic service.
• 2) The TCU performs the diagnostics service contained in a DiagDataFromCloud data bundle sent by the web service or the ESB.
• 3) After the execution of the service request or the attempted execution of the service request, the TCU collects the diagnostic response from the destination ECU.
• 4) The TCU packs the diagnostic response (s) into a DiagDataFromVehicle data bundle.
• 5) The TCU issues a diagnostic data message with the DiagDataFromVehicle data bundle to the web service.
• 6) The TCU proceeds to re-execute the diagnostic command with the defined cadence as instructed by the ESB issuing the diagnostic command.
• 7) The TCU continues to execute the diagnostic request until it is commanded by the web service or the ESB to complete the diagnostic requests.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has sent the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 11

• Actuators: TCU module
• Prerequisites: The TCU is ready, both onboard and offboard clients are connected, and the TCU is configured to be active.
• Scenario description: The TCU has been instructed by the ESB to perform a diagnostic service request on onboard modules, or it has performed it automatically. The TCU has performed the requested or prescribed service and returns the requested diagnostic data.

Steps:

• 1) The TCU has performed the requested or required diagnostic service request.
• 2) The TCU has received a diagnostic response from the target ECUs.
• 3) The TCU packs the diagnostic responses back into a DiagDataFromVehicle bundle and forms VSTAT and GPS info bundles.
• 4) The TCU outputs a diagnostic data message and the bundles to the web service / ESB.

• Post-conditions: The outgoing message and the data have been sent to the web service, the TCU is ready to recognize another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 12

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Scenario description: The web service has issued a cancellation command to terminate the requested diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the status of the request and requested data.

Steps:

• 1) The web service issues a command to prompt the TCU to stop a previously requested diagnostic service.
• 2) The TCU executes the commands.
• 3) After executing the command or trying to execute the command, the TCU issues a diagnostic data message to the web service.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has sent the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 13

• Actuators: TCU module
• Prerequisites: The TCU is ready, both onboard and offboard clients are connected, and the TCU is configured to support output devices.
• Scenario description: The web service issues a command to the TCU to enable or disable a hardwired TCU output. The TCU executes the command and responds with a response indicating whether the command was successful.

Steps:

• 1) The web service issues a command to prompt the TCU to enable or disable an output.
• 2) The TCU receives the command and executes the requested procedures to enable or disable the TCU output.
• 3) After executing the command or attempting to execute the command, the TCU will issue a response message to the web service, see Use case for outbound message.

• Post Conditions: The TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 14

• Actuators: TCU module
• Prerequisites: The TCU is ready, both onboard and offboard clients are connected, and the TCU is configured to support onboard alerts.
• Scenario description: The web service issues a command to the TCU to enable an onboard alert to an operator. The TCU executes the command and responds with a response indicating whether the command was successful.

Steps:

• 1) The web service issues a command to prompt the TCU to issue or stop an onboard alert.
• 2) The TCU receives the command and executes the requested procedures to enable or disable the onboard alert.
• 3) After executing the command or attempting to execute the command, the TCU issues a response message to the web service, see Use case for on-board alert message.

• Post-conditions: The TCU has issued the warning and replied to the web services whether it was done or not.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 15

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Description of the scenario: The web service has issued a diagnostic command to run a diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the status of the request and requested data.

Steps:

• 1) The web service issues a command to prompt the TCU to run a diagnostic service.
• 2) The TCU performs the diagnostics service contained in a DiagDataFromCloud data bundle sent by the web service or the ESB.
• 3) After the execution of the service request or the attempted execution of the service request, the TCU collects the diagnostic response from the destination ECU.
• 4) The TCU packs the diagnostic response (s) into a DiagDataFromVehicle data bundle.
• 5) The TCU issues a diagnostic data message with the DiagDataFromVehicle data bundle to the web service.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has sent the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 16

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Description of the scenario: The web service has issued a diagnostic command to repeat the execution of a diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the status of the request and requested data. The TCU executes the command with the specified cadence until the TCU receives a command to terminate the service request.

Steps:

• 1) The web service issues a command to prompt the TCU to run a diagnostic service.
• 2) The TCU performs the diagnostics service contained in a DiagDataFromCloud data bundle sent by the web service or the ESB.
• 3) After the execution of the service request or the attempted execution of the service request, the TCU collects the diagnostic response from the destination ECU.
• 4) The TCU packs the diagnostic response (s) into a DiagDataFromVehicle data bundle.
• 5) The TCU issues a diagnostic data message with the DiagDataFromVehicle data bundle to the web service.
• 6) The TCU proceeds to re-execute the diagnostic command with the defined cadence as instructed by the ESB issuing the diagnostic command.
• 7) The TCU continues to execute the diagnostic request until it is commanded by the web service or the ESB to complete the diagnostic requests.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has sent the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 17

• Actuators: TCU module
• Prerequisites: The TCU is awake and running, on and offboard clients are connected, the TCU is configured to be active.
• Scenario description: The TCU has been instructed by the ESB to perform a diagnostic service request on onboard modules, or it has performed it automatically. The TCU has performed the requested or prescribed service and returns the requested diagnostic data.

Steps:

• 1) The TCU has performed the requested or required diagnostic service request.
• 2) The TCU has received a diagnostic response from the target ECUs.
• 3) The TCU packs the diagnostic responses back into a DiagDataFromVehicle bundle and forms VSTAT and GPS info bundles.
• 4) The TCU outputs a diagnostic data message and the bundles to the web service / ESB.

• Post-conditions: The outgoing message and the data have been sent to the web service, the TCU is ready to recognize another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 18

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, onboard and offboard clients are connected.
• Scenario description: The web service has issued a cancellation command to terminate the requested diagnostic service to the TCU. The TCU executes the command and responds with a response indicating the status of the request and requested data.

Steps:

• 1) The web service issues a command to prompt the TCU to stop a previously requested diagnostic service.
• 2) The TCU executes the commands.
• 3) After executing the command or trying to execute the command, the TCU issues a diagnostic data message to the web service.

• Post Conditions: The TCU has responded to the web service with the success or failure of the web command, the TCU has sent the requested data to the web service, the TCU is ready to recognize another message or command.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 19

• Actuators: TCU module
• Prerequisites: Vehicle Ignition Status is "Power On", "Accessory On Mode" or "Operation", the TCU has been configured to provide driver alerts, the powertrain is running, all lamp tests required by FMVSS have been performed.
• Scenario description: The TCU has determined that a driver alert is displayed to the driver. The TCU generates a driver alert message and notifies the service provider of the beginning and end of each alert displayed to the driver.

Steps:

• 1) The TCU is configured to provide driver alerts.
• 2) When the TCU detects a state change or level change in any monitored warning. The TCU issues a driver warning message.
• 3) The TCU collects a VSTAT u. GPS info bundle.
• 4) The TCU assembles a DRIVER ALARM bundle.
• 5) The TCU compiles a TRAVEL REPORT bundle.
• 6) The TCU generates a message and outputs it with the data bundles to the ESB or the web service.

• Post-conditions: The TCU is ready to detect another warning, the TCU has issued the driver warning message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 20

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active.
• Description of the scenario: The TCU monitors the vehicle speed. When the vehicle speed has increased above a configurable vehicle speed setting for a configurable amount of time. The TCU issues a MOVE-STOP-STOP message.

Steps:

• 1) The TCU determines the vehicle speed.
• 2) If the vehicle speed is> STOPPED SPEED configuration, then the TCU starts the post-stop timer.
• 3) If the post-stop continuous timer> POST-STOP-TIME configuration, then the TCU will register the MOVE POST-STOP warning.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU collects a TRAVEL REPORT bundle.
• 6) The TCU collects a DRIVER ALARM bundle.
• 7) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundles, and correlation ID.
• 8) The TCU gives the record message and the data bundles to the
• Web service off.

• Post Conditions: The MOVE POST STOP message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 21

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active.
• Description of the scenario: The TCU monitors the vehicle speed. When the vehicle speed has fallen below a configurable vehicle speed setting for a configurable amount of time. The TCU issues a STOPPED message.

Steps:

• 1) The TCU determines the vehicle speed.
• 2) If the vehicle speed is <STOPPED SPEED configuration, then the TCU will start the Stopped timer.
• 3) If the Stop Stopped Timer> STOP TIME Configuration, then the TCU will register the STOPPED message code.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU collects a TRAVEL REPORT bundle.
• 6) The TCU collects a DRIVER ALARM bundle.
• 7) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundles and correlation ID, the TCU outputs the messages and data bundles to the web service.

• Post Conditions: The STOPPED message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 22

• Actuators: TCU module
• Preconditions: The TCU is ready to operate, the TCU is configured to be active, the time of the trip report time counter has expired.
• Scenario description: When the configurable time counter for configurable trip report or main messages of the TCU has expired. The TCU registers a trip report message, then collects and sends the message code and VSTAT- u. GPS info data to the web service.

Steps:

• 1) The limit of the timer for periodic trip report (main) messages of the TCU has been exceeded or has expired.
• 2) The TCU registers the trip report (15 min) message.
• 3) The TCU collects VSTAT- u. GPS info.
• 4) The TCU collects a TRAVEL REPORT bundle.
• 5) The TCU collects a DRIVER ALARM bundle.
• 6) The TCU resets the timer or counter.
• 7) The TCU generates an MQTT record with a corresponding MQTT header and returns it with message code, data bundle and correlation ID as user data.
• 8) The TCU gives the record message and the data bundles to the
• Web service off.

• Post Conditions: The periodic ride report message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 23

• Actuators: TCU module
• Prerequisites: The TCU is ready to operate, the TCU is configured to be active, slave or timer count has expired.
• Scenario description: When the configurable slave timer of the TCU has expired. The TCU registers a side event message, then collects and sends the message code and VSTAT- u. GPS info data to the web service.

Steps:

• 1) The counter of the TCU based on the configurable vehicle status reporting time has expired.
• 2) The TCU registers the secondary message code.
• 3) The TCU collects VSTAT- u. GPS info bundle.
• 4) The TCU resets the counter or timer.
• 5) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundle, and correlation ID.
• 6) The TCU outputs the record message and the data bundles to the web service.

• Post Conditions: The vehicle status (2 min) message and the data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 24

• Actuators: TCU module
• Prerequisites: The TCU is ready to operate, the TCU is configured to be active, slave or timer count has expired.
• Scenario description: When the configurable slave timer of the TCU has expired. The TCU registers a side event message, then collects and sends the message code and VSTAT- u. GPS info data to the web service.

Steps:

• 1) The counter of the TCU based on the configurable vehicle status reporting time has expired.
• 2) The TCU registers the secondary message code.
• 3) The TCU collects VSTAT- u. GPS info bundle.
• 4) The TCU resets the counter or timer.
• 5) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundle, and correlation ID.
• 6) The TCU outputs the record message and the data bundles to the web service.

• Post Conditions: The vehicle status (2 min) message and the data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 25

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active.
• Description of Scenario: The TCU determines that the powertrain has entered an activated or operational state and sends an EngON (MtrEIN) message with data bundles.

Steps:

• 1) The TCU determines the engine driveline condition as active.
• 2) BEV u. HEV: The TCU determines the engine state as active.
• 3) The TCU issues the EngOn message.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU collects a TRAVEL REPORT bundle.
• 6) The TCU collects a DRIVER ALARM bundle.
• 7) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundles, and correlation ID.
• 8) The TCU issues the record message and the data bundles to the web service.

• Post-conditions: The EngON message and the data bundles have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 26

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active.
• Scenario description: The TCU determines that the powertrain has transitioned to a non-operational or non-operational state. The TCU sends an EngOFF (MtrAUS) message with data bundles.

Steps:

• 1) The TCU determines that the engine is not operating.
• 2) BEV u. HEV: The TCU determines that the powertrain is OFF.
• 3) The TCU outputs the EngOff message code.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU collects a TRAVEL REPORT bundle.
• 6) The TCU collects a DRIVER ALARM bundle.
• 7) The TCU generates an MQTT record with a corresponding MQTT header and outputs it as payload with message code, data bundles, and correlation ID.
• 8) The TCU issues the record message and the data bundles to the web service.

• Post Conditions: The engine operating mode is the OFF or non-operational state, the ENGOFF message code and data has been sent to the web service, the TCU is waiting to detect additional message conditions.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interfaces.

Example 27

• Actuators: TCU module
• Preconditions: The ignition status is "Operation", the TCU is ready, the TCU is configured to be active.
• Description of Scenario: If the vehicle enters or exits from any other operating condition, the TCU will register an IgnOff (ZdgAus) message, then collect and send the message code and VSTAT- u. GPS info data to the web service.

Steps:

• 1) The TCU determines the ignition state.
• 2) Upon transition from any other state to Ignition OFF, the TCU will send a message.
• 3) The TCU issues the IGNOff message.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU generates an MQTT record with a corresponding MQTT header and returns it with message code, VSTAT, and the like. GPS Info and Correlation ID as payload.
• 6) The TCU outputs the record message and the data bundles to the web service.

• Postcondition: The IgnOFF message code and vehicle snapshot u. GPS data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 28

• Actuators: TCU module
• Preconditions: The ignition status is "off", the TCU is ready, the TCU is configured to be active.
• Description of the Scenario: When the vehicle transitions from the off or inoperative state to any other operating state, the TCU registers an IgnRun message, then collects and transmits the message code and VSTAT- u. GPS info data to the web service.

Steps:

• 1) The TCU determines the ignition state.
• 2) Upon transition from any other ignition state to Ignition = OPERATION or Accessory On Mode, the TCU will send a message.
• 3) The TCU outputs the IGNrun message code and collects VSTAT u. GPS info.
• 4) The TCU generates an MQTT record with a corresponding MQTT header and returns it with message code, VSTAT, and the like. GPS Info and Correlation ID as payload.
• 5) The TCU outputs the record message and the data bundles to the web service.

• Postcondition: The IgnRun message code and VSTAT- u. GPS bundle data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA upload / download (cellular connection), vehicle system interface.

Example 29

• Actuators: TCU module
• Prerequisites: The TCU is awake and in full power or low power mode.
• Scenario description: When the TCU detects conditions indicating that the GPS has reached a 3D GPS degree of dimension. The TCU issues a GPS 3D FIX message.

Steps:

• 1) The TCU monitors the HSCAN signals provided by the GPSM module or equivalent signals provided by an internal or a dedicated GPS antenna.
• 2) The TCU monitors GPS dimension info.
• 3) If GPS_dimension = 3D fix, the TCU will register the GPS 3D FIX message code.
• 4) The TCU collects VSTAT- u. GPS info.
• 5) The TCU generates an MQTT record with a corresponding MQTT header and returns it with message code, VSTAT, and the like. GPS Info and Correlation ID as payload, it outputs the message and the data bundles to the web service.

• Post-conditions: The TCU is ready to recognize another message.

Example 30

• Actuators: TCU module
• Prerequisites: The TCU is ready to operate, the TCU is configured to provide police reports, the lateral acceleration exceeds 8 m / s ² , or the braking torque exceeds 5000 Nm, with the transmitted message monitor indicating that the vehicle has entered the tracking mode, the TCU is configured to be ACTIVE (configured to provide messages ... INACTIVE: the TCU does not provide any messages), the vehicle has entered the Pursuit mode.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects the tracking mode condition, the TCU issues a police tracking mode message and continues to issue tracking mode messages every 5 seconds until the conditions indicate that the tracking mode has ended.

Steps:

• 1) The TCU monitors lateral acceleration and braking torque data.
• 2) If the lateral acceleration exceeds 8 m / s ² or the braking torque exceeds 5000 Nm, the TCU outputs a tracking mode message and starts a 45 second timer.
• 3) The TCU collects VSTAT and GPS info bundles and sends these bundles with each tracking mode message that the TCU issues.
• 4) The TCU outputs the message and the data bundles to the web service.
• 5) The tracking mode messages are continually reissued every 5 seconds with updated VSTAT and GPS info bundles and output to the web service until the 45 second timer ends.
• 6) If the TCU experiences a lateral acceleration in excess of 8 m / s ² or a brake torque in excess of 5000 Nm before the expiration of the 45-second timer, the timer is reset and the tracking mode messages continue for another 45 seconds.

• Post Conditions: The police tracking mode message and the data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 31

• Actuators: TCU module
• Preconditions: The TCU is ready to operate, the TCU is configured to be active, the TCU is configured to support police functions, the TCU has an input port designed to support a police siren.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects that a police siren has been activated by monitoring designated and configured input ports, the TCU issues a SIRENE ON message to the web service.

Steps:

• 1) The TCU has determined that the police siren has been activated.
• 2) The TCU issues a SIRENE-ON message with bursts.
• 3) The TCU collects vehicle status or VSTAT and GPS info bundles for all messages.
• 4) The TCU outputs the message and the record to the web service.

• Post-conditions: The police siren-on message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 32

• Actuators: TCU module
• Preconditions: The TCU is ready to operate, the TCU is configured to be active, the TCU is configured to support police functions, the TCU has an input port designed to support a police siren.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects that a police siren has been disabled by monitoring designated and configured input ports, the TCU issues a SIRENE OFF message to the web service.

Steps:

• 1) The TCU has determined that the police siren has been disabled.
• 2) The TCU issues a SIRENE-OFF message with bursts.
• 3) The TCU collects VSTAT and GPS info bundles with all messages.
• 4) The TCU outputs the message and the data set to the web service.

• Post-conditions: The police siren-off message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 33

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active, the TCU is configured to support police capabilities, the TCU has an input port designed to support a police lightbar.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects that a police lightbar has been activated by monitoring designated and configured input ports, the TCU issues a LIGHT BAR ON message to the web service.

Steps:

• 1) The TCU has determined that the police light bar has been activated.
• 2) The TCU outputs a LIGHT BAR ON message with data bursts.
• 3) The TCU collects VSTAT and GPS info bundles for all messages.
• 4) The TCU outputs the record message and the data bundles to the web service.

• Post Conditions: The Police Lightbar On message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 34

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to be active, the TCU is configured to support police capabilities, the TCU has an input port designed to support a police lightbar.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects that a police light bar has been disabled by monitoring designated and configured input ports, the TCU issues a LIGHT BAR OFF message to the web service.

Steps:

• 1) The TCU has determined that the police light bar has been disabled.
• 2) The TCU outputs a LIGHT BAR OFF message with data bursts.
• 3) The TCU collects VSTAT and GPS info bundles for all messages.
• 4) The TCU outputs the record message and the data bundles to the web service.

• Post Conditions: The police light bar OFF message and the data have been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 35

• Actuators: TCU module
• Preconditions: The TCU is ready, EDRTriggerEvntSyncLateral has triggered, the TCU is configured to be active.
• Description of the scenario: only police vehicles; the TCU is configured to support police vehicle options. After the TCU detects an EDRTriggerEvntSync transition to active, the TCU issues a police EDR message.

Steps:

• 1) The TCU has determined that the vehicle is experiencing conditions that cause an EDR event.
• 2) The TCU issues an EDR message with data bundles.
• 3) The TCU collects VSTAT and GPS info bundles and sends these bundles with each EDR message that the TCU issues.
• 4) The TCU outputs the message and the data bundles to the web service.
• 5) The EDR messages are continuously reissued every 5 seconds with updated VSTAT and GPS info bundles and output to the web service until the 45 second timer ends.
• 6) If the TCU experiences additional EDR events before the 45-second timer expires, the timer is reset and the EDR messages continue for another 45 seconds.

• Post-conditions: The police EDR message and data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 36

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is in the ACTIVE state, the ignition is in the IGNITION KEY OFF position, the TCU has entered low power or sleep mode.
• Scenario description: The TCU periodically wakes up from low power or sleep mode according to a configurable timer. The default time or default is 12 hours. On awakening, the TCU acquires GPS and vehicle data, establishes an MQTT connection, and sends data to the ESB or the web service. Upon completion, the TCU returns to the low power or sleep mode.

Steps:

• 1. The TCU sleep timer has expired.
• 2. The TCU wakes the vehicle bus to collect GPS and vehicle data.
• 3. The TCU forms VSTAT and GPS Info Bundles.
• 4. The TCU establishes an MQTT connection to the ESB or the web service.
• 5. The TCU issues records to the ESB or the web service.
• 6. The TCU reverts to low power or sleep mode.

• Post Conditions: The TCU returns to low power or sleep mode and waits for vehicle reporting conditions.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 37

• Actuators: TCU module
• Prerequisites: The TCU is ready to operate, the TCU is configured to issue a generic message, the TCU has been configured to associate an HSCAN signal and data required to issue the generic message, the TCU is configured that she is active.
• Scenario description: The TCU has been configured to output generic messages. The TCU has determined that the configured HSCAN signal has transitioned to a state requiring the issuance of a message. The TCU outputs the message with the required data bundles.

Steps:

• 1. The TCU has determined that the vehicle is experiencing conditions that cause the issuance of a generic message.
• 2. The TCU outputs a generic message # with data bundles.
• 3. The TCU collects VSTAT- u. GPS info.
• 4. The TCU outputs the generic message and the data bundles to the web service.

• Post-conditions: The generic message # and data has been sent to the web service, the TCU is ready to detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 38

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU is configured to stream HSCAN frames, the TCU is configured to stream selected HSCAN frames, the TCU is configured to be active, the TCU has an active one Connect to the ESB or the web service.
• Scenario description: The TCU has been configured to enable the TCU to stream vehicle data in real time when data is received in the HSCAN network of the vehicle. In this mode, the TCU receives HSCAN messages and loads the unprocessed HSCAN frames as MQTT payloads for transmission to the Web service or the ESB.

Steps:

• 1. The TCU establishes an MQTT connection to the ESB or the web service.
• 2. The TCU receives designated HSCAN messages from the HSCAN network of the vehicle.
• 3. The TCU stores 30-second increments of continuous HSCAN data.
• 4. The TCU issues a CANNET message and bundles a 30-second interval of HSCAN data to an SVHSCAN bundle and broadcasts or issues the message data to the web service.
• 5. The TCU continuously stores and bundles HSCAN data and outputs it continuously to the web service.

• Post-conditions: The data was successfully received by the ESB or the web service.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 39

• Actuators: TCU module
• Prerequisites: The TCU is ready for operation, the ESB is ready for operation, the TCU has the default configuration "inactive", the TCU has the default configuration "not authorized".
• Scenario description: The TCU was installed in a vehicle by an on-site technician. The TCU determines whether the power mode or the VIN has changed. The TCU establishes a cellular connection and issues an authorization request to a service provider.

Steps:

• 1) After power is supplied to the TCU, the TCU establishes a cellular connection to the ESB, MQTT message broker, or web service.
• 2) If either the TCU determines that the power mode is "power supplied first" or the TCU detects a new VIN. The TCU returns to the default configuration. The TCU must issue an authorization request to the ESB.
• 3) The TCU sets the delivery reason flag to "power supplied first" or "new VIN" in the provision bundle as required by the conditions.
• 4) The TCU sends the authorization request with the provisioning bundle, the VSTAT bundle and the GPS info bundle to the web service.
• 5) The ESB processes the authorization request.
• 6) The ESB sends a diagnostic command with configuration data to change the TCU operating state to ACTIVE and the TCU authorization state as AUTHORIZED.

• Post Conditions: The TCU immediately sends a TCU configuration request and a vehicle content request request to the ESB for use case and request, the TCU status is now active and authorized.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 40

• Actuators: TCU module
• Preconditions: The TCU is active and awake, the TCU has completed the authorization request.
• Description of Scenario: The TCU sends the request to the web service, requesting the ESB or the web service to issue diagnostic commands to the TCU to query other modules or ECUs to determine vehicle features and content to support team leader features.

Steps:

• 1) The TCU initiates a vehicle content query request to the ESB or web service.
• 2) The TCU sends the request along with the Provisioning Bundle, the VSTAT Bundle, and the GPS Info Bundle to the ESB.
• 3) The ESB sends a diagnostic command to query the modules to the TCU.
• 4) The vehicle modules respond to the TCU request with diagnostic data.
• 5) The TCU sends the diagnostic data to the ESB.
• 6) The ESB continues to send diagnostic commands to interrogate the modules to the TCU until the ESB collects configuration data from all of the requested modules.
• 7) The ESB processes the configuration data to determine the TCU configuration.

• Post Conditions: The TCU is ready to accept the TCU configuration command and detect another message.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 41

• Actuators: TCU module
• Preconditions: The TCU is active and awake.
• Description of the scenario: The TCU checks the configuration status; if the TCU has not been configured, the TCU issues a TCU configuration request per request to the ESB after each firing-on message.

Steps:

• 1) If the TCU has not been configured, the TCU sends a TCU configuration request to the ESB with the Provisioning Bundle, the VSTAT Bundle, and the GPS Info Bundle.
• 2) The ESB processes the configuration request and sends a diagnostic command with configuration data to the TCU.
• 3) The TCU processes the diagnostic command and writes configuration data to the correct locations.
• 4) After completing the configuration write, the TCU reads the stored configuration data and sends the data to the ESB as a diagnostic bundle.
• 5) The ESB receives the diagnostic data from the TCU and confirms that the correct configuration has been processed.
• 6) The ESB issues a diagnostic command to clear all diagnostic error codes to the TCU.

• Post-conditions: The TCU is ready to detect another message, the TCU is ready for another command, the TCU configuration-not-completed-message code has been sent.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Example 42

• Actuators: TCU module
• Preconditions: The TCU is ready for operation, the TCU is awake.
• Description of Scenario: The TCU has detected conditions that indicate that it is necessary to issue a PROVISIONAL message to the ESB or the web service.

Steps:

• 1) The TCU has encountered a condition that requires the issue of a reset / provision message.
• 2) The TCU registers the provisioning message.
• 3) The TCU collects VSTAT- u. GPS info bundle.
• 4) The TCU collects a PROVISION bundle (includes the reason for the message).

• Post-conditions: The TCU is ready to recognize another message.

Example 43

• Actuators: TCU module
• Preconditions: The TCU is active, the TCU reads HSCAN messages, the retrofit tool is connected.
• Scenario description: The TCU continuously monitors HSCAN traffic when the TCU detects HSCAN traffic indicating that a service tool is attached to the bus. The TCU issues a validator message to the web service.

Steps:

• 1) The TCU recognizes that a test tool is connected to the HS CAN.
• 2) The TCU outputs the validator report code.
• 3) The TCU collects VSTAT- u. GPS info bundle.

• Post-conditions: The TCU is ready to recognize another message.

Example 44

• Actuators: TCU module
• Prerequisites: The TCU is ready, the TCU has undergone a first powering event, or the TCU is reading a new VIN, the TCU has established an MQTT connection to the web service, the TCU has issued a provisioning, GPS Info, and VSTAT bundle. the TCU has completed the authorization process,
• Scenario description: The TCU has been successfully powered and has one MQTT connection to the ESB message broker. The TCU issues a diagnostic command or a diagnostic request to execute a self-test diagnostic routine to a BCM. This indicates to the fitter that the TCU has been installed correctly.

Steps:

• 1. The TCU issues a service 0x31 with the routine identifier 0x0202 to the BCM.
• 2. The BCM receives a diagnostic command.
• 3. The BCM executes the command.
• 4. The TCU reads the diagnostic command response from the BCM.
• 5. Receive positive response, execute command; the TCU sends a diagnostic message and a diagnostic bundle to the ESB or the web service.
• 6. Receive negative response, command not executed; the TCU sends a diagnostic message and diagnostic data bundle to the ESB or the web service.

• Post Conditions: BCM self-test performed, the TCU begins monitoring the vehicle for message conditions.
• Interfaces: OTA broadcast or download of cellular network, vehicle system interface.

Although exemplary embodiments are described above, it is not intended that these embodiments describe all possible forms of the invention. Rather, the terms used in the specification are words of description rather than limitation, and it is to be understood that various changes may be made without departing from the spirit and scope of the invention. Additionally, the features of various implementation embodiments may be combined to form further embodiments of the invention.

• A. System, umfassend: einen Prozessor, der konfiguriert ist zum: Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte; Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung; Speichern von Daten, die durch die Ereignisdatenaufzeichnung aufgezeichnet wurden, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde; und Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
• B. System nach A, wobei die Bedingung von einem Hersteller vordefiniert ist.
• C. System nach A, wobei die Bedingung einen bevorstehenden Unfall anzeigt.
• D. System nach A, wobei das Remote-System ein Kraftfahrzeughersteller-Server ist.
• E. System nach A, wobei das Remote-System ein Flottenverwaltungsserver ist.
• F. System nach A, wobei sich die Bedingung auf einen Bremszustand des Fahrzeugs bezieht.
• G. System nach A, wobei sich die Bedingung auf einen Bewegungszustand des Fahrzeugs bezieht.
• H. System nach A, wobei sich die Bedingung auf eine Geschwindigkeitsänderung des Fahrzeugs bezieht.
• I. System, umfassend: einen Prozessor, der konfiguriert ist zum: Empfangen von variablen Eingabedaten von einer Mehrzahl von drahtlos verbundenen Fahrzeugen; Vergleichen der empfangenen variablen Eingabedaten mit vorbestimmten Schwellen, um zu bestimmen, ob eine Bedingung, die wahrscheinlich eine Ereignisdatenaufzeichnung (EDR) initiiert, in einem der Mehrzahl von Fahrzeugen bevorsteht; Ausgeben für jedes Fahrzeug, bei welchem die Bedingung bevorsteht, einer Anweisung für das Fahrzeug, einen Autofahrer zu warnen; Ausgeben an jedes Fahrzeug, für welches die Bedingung bevorsteht, einer Anforderung, welche die Ereignisdatenaufzeichnung anfordert; und Sammeln der Daten, die durch die angeforderte(n) Ereignisdatenaufzeichnung(en) aufgezeichnet wurden.
• J. System nach I, wobei die Warnung eine optische Warnung ist.
• K. System nach I, wobei die Warnung eine akustische Warnung ist.
• L. System nach I, wobei der Prozessor außerdem so konfiguriert ist, dass er eine Warnung an einen Flottenbetreiber ausgibt.
• M. System nach Anspruch 9, wobei die Daten gesammelt werden, während die Aufzeichnung läuft.
• N. System nach I, wobei die Daten nach der Ereignisdatenaufzeichnung gesammelt werden.
• O. Computerimplementiertes Verfahren, umfassend: das Erkennen einer Bedingung, die darauf hinweist, dass Ereignisdatenaufzeichnung (EDR) beginnen sollte; das Starten und Fortsetzen der Ereignisdatenaufzeichnung für eine vorbestimmte Zeitdauer nach der Bedingung; das Speichern von Daten, die durch die Ereignisdatenaufzeichnung aufgezeichnet wurden, wenn die vorbestimmte Zeitdauer verstrichen ist und kein ernstlicher Zwischenfall erkannt wurde; und das Hochladen der Daten auf ein Remote-System, sobald eine Verbindung mit dem Remote-System hergestellt werden kann.
• P. Verfahren nach O, wobei die Bedingung von einem Hersteller vordefiniert ist.
• Q. Verfahren nach O, wobei die Bedingung einen bevorstehenden Unfall anzeigt.
• R. Verfahren nach O, wobei das Remote-System ein Kraftfahrzeughersteller-Server ist.
• S. Verfahren nach O, wobei das Remote-System ein Flottenverwaltungsserver ist.

It is further described:

• A. A system comprising: a processor configured to: detect a condition indicating that event data recording (EDR) should begin; Starting and resuming the event data record for a predetermined period of time after the condition; Storing data recorded by the event data record when the predetermined time period has elapsed and no serious incident has been detected; and upload the data to a remote system as soon as a connection to the remote system can be made.
• B. System according to A, wherein the condition is predefined by a manufacturer.
• C. System of A, the condition indicating an imminent accident.
• D. System according to A, wherein the remote system is a motor vehicle manufacturer server.
• E. System according to A, wherein the remote system is a fleet management server.
• F. System according to A, wherein the condition relates to a braking state of the vehicle.
• G. System according to A, wherein the condition relates to a state of motion of the vehicle.
• H. System according to A, wherein the condition relates to a change in speed of the vehicle.
• I. A system, comprising: a processor configured to: receive variable input data from a plurality of wirelessly connected vehicles; Comparing the received variable input data with predetermined thresholds to determine whether a condition likely to initiate an event data record (EDR) is imminent in one of the plurality of vehicles; Issuing, for each vehicle in which the condition is imminent, an instruction for the vehicle to warn a driver; Outputting to each vehicle for which the condition is due, a request requesting the event data record; and collecting the data recorded by the requested event data record (s).
• J. System according to I, wherein the warning is an optical warning.
• K. System according to I, wherein the warning is an audible warning.
• The system of claim 1, wherein the processor is further configured to issue a warning to a fleet operator.
• The system of claim 9, wherein the data is collected while the recording is in progress.
• N. System according to I, wherein the data is collected after the event data recording.
• O. A computer-implemented method, comprising: detecting a condition indicating that event data recording (EDR) should begin; starting and resuming the event data record for a predetermined period of time after the condition; storing data recorded by the event data record when the predetermined time period has elapsed and no serious incident has been detected; and uploading the data to a remote system as soon as it can connect to the remote system.
• P. Method according to O, wherein the condition is predefined by a manufacturer.
• Q. Procedure to O, where the condition indicates an imminent accident.
• R. method to O, wherein the remote system is a motor vehicle manufacturer server.
• S. Method to O, where the remote system is a fleet management server.

QUOTES INCLUDE IN THE DESCRIPTION

This list of the documents listed by the applicant has been generated automatically and is included solely for the better information of the reader. The list is not part of the German patent or utility model application. The DPMA assumes no liability for any errors or omissions.

Cited patent literature

• US 8139820 [0003]

Cited non-patent literature

• IEEE 802 PAN [0021]
• IEEE 1394 [0024]
• IEEE 1284 [0024]
• IEEE 803.11 [0026]

Claims (14)

System comprising: a processor configured to: Detecting a condition indicating that event data recording (EDR) should begin; Starting and resuming the event data record for a predetermined period of time after the condition; Storing data recorded by the event data record when the predetermined period of time has elapsed and no serious incident has been detected; and Upload the data to a remote system as soon as it can connect to the remote system. The system of claim 1, wherein the condition is predefined by a manufacturer. The system of claim 1, wherein the condition indicates an imminent accident. The system of claim 1, wherein the remote system is a motor vehicle manufacturer server. The system of claim 1, wherein the remote system is a fleet management server. The system of claim 1, wherein the condition relates to a braking condition of the vehicle. The system of claim 1, wherein the condition relates to a state of motion of the vehicle. The system of claim 1, wherein the condition relates to a speed change of the vehicle. System comprising: a processor configured to: Receiving variable input data from a plurality of wirelessly connected vehicles; Comparing the received variable input data with predetermined thresholds to determine whether a condition likely to initiate an event data record (EDR) is imminent in one of the plurality of vehicles; Issuing, for each vehicle in which the condition is imminent, an instruction for the vehicle to warn a driver; Outputting to each vehicle for which the condition is due, a request requesting the event data record; and collecting the data recorded by the requested event data record (s). The system of claim 9, wherein the warning is an optical warning. The system of claim 9, wherein the warning is an audible warning. The system of claim 9, wherein the processor is further configured to issue a warning to a fleet operator. The system of claim 9, wherein the data is collected while recording is in progress. The system of claim 9, wherein the data is collected after the event data record.

Images