Method and system for decoupling charging signal from battery signal

Abstract

Embodiments of the present disclosure relate to methods and systems for decoupling a charging signal from a battery signal. A method at a computing device includes sending a request to a vehicle communication subsystem to determine a number of charging ports on a vehicle; receiving a response providing a number of charging ports on the vehicle; sending a request to a vehicle communication subsystem for finding a battery associated with each charging port; and receiving a response identifying a battery associated with each charging port.

Description

Technical Field

[0001] The present disclosure relates to vehicle systems, and in particular to objects within such vehicle systems. Background Art

[0002] Modern vehicles have many components and sensors. Such components and sensors can be called data objects and are queried and combined to provide insights into the vehicle and vehicle operation.

[0003] However, the current tree structure defines data objects in a rigid way, which may cause problems as technology evolves. Summary of the invention

[0004] The present disclosure provides a method at a computing device, the method comprising: sending a request to a vehicle communication subsystem to determine the number of charging ports on a vehicle; receiving a response providing the number of charging ports on the vehicle; sending a request to the vehicle communication subsystem to find a battery associated with each charging port; and receiving a response identifying the battery associated with each charging port.

[0005] The present disclosure also provides a computing device, which includes: a processor; and a communication subsystem, wherein the computing device is configured to: send a request to a vehicle communication subsystem to determine the number of charging ports on a vehicle; receive a response providing the number of charging ports on the vehicle; send a request to the vehicle communication subsystem to find a battery associated with each charging port; and receive a response identifying the battery associated with each charging port.

[0006] The present disclosure also provides a non-transitory computer-readable medium for storing instruction codes, which, when executed by a processor of a computing device, causes the computing device to: send a request to a vehicle communication subsystem to determine the number of charging ports on a vehicle; receive a response providing the number of charging ports on the vehicle; send a request to the vehicle communication subsystem to find a battery associated with each charging port; and receive a response identifying the battery associated with each charging port. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] The present disclosure will be better understood with reference to the accompanying drawings, in which:

[0008] Figure 1 is a block diagram showing a tree structure for classifying charging under a battery;

[0009] Figure 2 is a block diagram showing a revised tree structure of various batteries under the traction battery branch;

[0010] Figure 3is a block diagram showing a modified tree structure of various charging ports under the charging port branch;

[0011] Figure 4 is a data flow graph for determining the number of charging ports and whether each charging port is connected;

[0012] Figure 5 is a data flow graph for determining the remaining range of a vehicle;

[0013] Figure 6 is a data flow diagram of an alternative method for determining the remaining range of a vehicle;

[0014] Figure 7 is a data flow graph for determining a state of charge of a plurality of batteries having a plurality of charging ports;

[0015] Figure 8 is a block diagram illustrating an example vehicle computing node; and

[0016] Fig. 9 is a block diagram of a simplified computing device that can be used with embodiments of the present disclosure. DETAILED DESCRIPTION

[0017] In modern vehicles, information from one or more physical sensors can be processed and combined to create "insights" that can be valuable in the system. Such one or more physical sensors and the processing associated with them can be logically referred to as microservices or synthetic sensors (SS). The terms microservices and synthetic sensors can be used interchangeably in this article.

[0018] The synthetic sensor may be present in other types of applications, including but not limited to medical applications, manufacturing applications, Internet of Things applications, etc., and the present disclosure is not limited to vehicle applications. Vehicle applications are as follows.

[0019] Insight is a term used in this article to describe any computer-created interpretation of basic sensor data. Insights can be as simple as data aggregation or correlation or as complex as artificial intelligence and machine learning. For example, a temperature sensor that provides high and low watermarks for notifications can be considered an "insight." For location services, geo-fencing is an insight. For cameras, passenger identification can be an insight. The use of a combination of sensors such as a temperature sensor and a camera can be used with an artificial intelligence model to determine if a car seat is occupied by a hot car, which can be an insight. Many other examples of insights are possible.

[0020] In one embodiment, vehicle applications can be implemented in a system that provides consistent access to vehicle data and intelligent insights in a way that is familiar and accessible to the developer community. Such an environment can allow cloud developers to extend their reach to the edge within the vehicle by developing synthetic sensors that gain intelligent insights on vehicle data using common cloud development techniques and paradigms. Such an environment can provide consistent access to vehicle data so that synthetic sensors can be written without customization and deployed to a broad base of vehicles.

[0021] However, in order to facilitate access to such vehicle data, it is necessary to identify, locate data objects within the vehicle, and easily identify associations between various data objects within the vehicle.

[0022] The situation can be complicated by the different naming and relational conventions used by different vehicle manufacturers. To overcome this, the Vehicle Signal Specification (VSS) is currently being used. VSS defines itself as a method for creating a common understanding of vehicle signals in order to reach a common language independent of the protocol or serialization used. VSS introduces a domain classification for vehicle signals that can serve as a standard for passing information around the vehicle in automotive applications. VSS focuses on vehicle signals, in the sense of classic attributes, sensors and actuators, the raw data is transmitted over the vehicle bus and the data is usually associated with the infotainment system.

[0023] For example, the VSS naming convention is described in Table 1 below.

[0024]

[0025]

[0026] Table 1: Example VSS naming conventions

[0027] As shown in Table 1 above, dot notation name paths are used in VSS to identify components as branches (a set of data entries) and data entries (sensors, actuators, or properties).

[0028] Using dot-marked name paths, a tree structure can be built for the various data objects within the vehicle.

[0029] The Connected Vehicle Systems Alliance (COVESA) defines vehicle signal specifications and signal catalogs. More generally, the signal catalog is referred to herein as the "VSS catalog." However, the various parts of the COVESA VSS catalog are currently rigid. For example, battery and charging are associated in a one-to-one manner and grouped under battery. This is shown in the VSS example in Table 2 below:

[0030]

[0031]

[0032]

[0033] Table 2: VSS for battery and charger

[0034] In Table 2, sensors are unidirectional signals originating from the vehicle (i.e., a sensor is a signal used to read the value of a property in the vehicle). Actuators are bidirectional signals and can either set or get a value (i.e., an actuator can be used to control the value of a property in the vehicle). Branches are nodes in a tree structure. Properties are typically fixed values. Sensors / actuators typically have a publisher (or producer) that continually updates the signal value when changes occur, while properties have a set value that typically should not change more than once per ignition cycle.

[0035] For example, now refer to Figure 1 , Figure 1 An example tree structure of a portion of Table 2 above is shown.

[0036] exist Figure 1 In the embodiment of FIG. 1 , the object tree 100 is rooted at vehicle 110 . Below the root, an example in the tree may be powertrain 120 .

[0037] The powertrain 120 may have a battery, shown as TractionBattery 130 .

[0038] A cell can have various sensors, properties, actuators, and branches. Figure 1 In the example of FIG. 1 , the TractionBattery 130 includes sensors such as a cumulative consumed energy sensor 140 and a cumulative charged energy sensor 142. For simplicity, other sensors and actuators in Table 2 above are not shown.

[0039] In addition, Figure 1 In the example of FIG. 1 , TractionBattery 130 includes a charge branch 144 and a charge state branch 146. For simplicity, the charge state branch 146 is not shown as having sub-branches, but the sub-branches are provided in Table 2 above.

[0040] The charging branch 144 includes various sensors, actuators, and attributes. Figure 1 The example of 150 shows a charging current sensor 150, a charging limit actuator 152, a charging rate sensor 154, a charging plug type attribute 156, a charging port shutter actuator 158, a charging voltage sensor 160, and a "charging" sensor 162. Other sensors, attributes, and actuators are shown in Table 2 above.

[0041] The requirement that the charging port and charging information be located below the battery branch in the tree structure creates significant limitations. In particular, the current structure in the VSS directory cannot support more than one battery. Furthermore, a charging port is associated with each battery, where it should be associated with the vehicle.

[0042] Thus, according to an embodiment of the present disclosure, batteries and charging are separated in the VSS tree structure. This allows one charging port to be associated with multiple batteries, multiple charging ports to be associated with various batteries, and other options, resulting in an "M" to "N" relationship between charging ports and batteries. These and other elements are described below.

[0043] In particular, in the example of Table 3 below, the charging port is decoupled from the battery. In this way, the charging port can be used to support multiple batteries, and in the case where the vehicle has multiple charging ports, the charging port can also be defined to have multiple instances, as well as other options.

[0044]

[0045]

[0046]

[0047]

[0048] Table 3: Corrected VSS for battery and charger

[0049] As shown in Table 3, under the powertrain, the traction battery and the charging port are separated. There are various sensors, actuators, attributes, and branches under each charging port and traction battery.

[0050] This will refer to Figure 2 and Figure 3 In particular, reference is now made to Figure 2 , Figure 2 A modified VSS directory is shown with the charge port and battery separated. Object tree 200 includes a vehicle 210 having a powertrain 220 .

[0051] Under powertrain, traction battery 230 is a branch of various batteries on the vehicle. Charge port 260 is a branch of one or more charge ports associated with the vehicle. Examples of branch nodes under charge port 260 are as follows: Figure 3 In some cases, powertrain 220 may also include information for non-traction batteries (eg, batteries for medical equipment).

[0052] Under traction batteries 230, a battery count value or attribute 232 may indicate how many traction batteries are present in the vehicle. Figure 2 In the example of FIG. 2 , a first battery branch 234 and a second battery branch 236 are provided.

[0053] Under the first battery branch 234, there may be various sensors, actuators and properties and sub-branches. These are shown in Table 3 above, and Figure 2 A subset is shown in the example of . In particular, an identifier attribute 240 is provided. A cumulative charge energy sensor 242 is provided. A charge state branch 244 is provided, and a range sensor 246 is provided.

[0054] The charging status of the branch may include a current charge 247 , a displayed charge 248 , and a target charge 249 .

[0055] Similarly, under the second battery branch 236, there may be various sensors, actuators and properties and sub-branches. These are shown in Table 3 above, and Figure 2 A subset is shown in the example of . In particular, an identifier attribute 250 is provided. A cumulative charge energy sensor 252 is provided. A charge state branch 254 is provided, and a range sensor 256 is provided.

[0056] The charging status branch may include current charge 257 , displayed charge 258 , and target charge 259 .

[0057] Therefore, if Figure 2 As shown, the traction battery branch may have different batteries associated with it, each battery identified by its own branch. Battery count 232 may indicate the number of batteries. In some cases, an enumerated list may exist as a property under the traction battery branch to list the batteries associated with the vehicle.

[0058] Similarly, a charging port branch may have one or more charging ports associated therewith. Figure 3 .

[0059] exist Figure 3 In the embodiment of FIG. , vehicle 210 includes a powertrain 220 including a traction battery branch 230 and a charging port branch 260 .

[0060] Under the charge ports branch 260, a port count attribute 262 indicates the number of charge ports associated with the vehicle. For example, in some cases, a vehicle may have different battery packs that may be charged using different charge ports. One non-limiting example may be an ambulance that is equipped with a battery that is certified as medical grade for running medical equipment and is also equipped with a battery for moving the vehicle. In this case, the charge port for the medical battery may be different from the charge port for the traction battery. Other examples are possible.

[0061] Therefore, in Figure 3 In the example of FIG. 1 , there may be a first port branch 264 and a second port branch 266 .

[0062] Each port branch may have a property, called battery 268, which may be a list of enumerated values ​​indicating the battery associated with that charging port. In some cases, the enumeration list may include an identifier for the battery. In other cases, the enumeration list may include a path within VSS for the battery. For example, where the first port 264 has two battery packs associated with it, the enumeration list for the property may include [vehicle.powertrain.tractionbattery.battery1,

[0063] vehicle.powertrain.tractionbattery.battery2]. This will allow vehicle manufacturers to replace the battery pack without changing the ID sensor and still utilize the VSS naming convention.

[0064] In practice, an application can query a charging port to determine which batteries are associated with that port, and then use the paths in the enumerated list to obtain information directly from those batteries.

[0065] Other sensors, properties, and actuators may exist under the port branch, examples of which are listed in Table 3 above. Figure 3 In the embodiment of FIG. 2 , a charging current sensor 270 , a charging limit actuator 272 , a charging plug type 274 , and a “charging” sensor 276 are shown.

[0066] Furthermore, a timer branch 278 having a time executor 280, a completion time sensor 282 and a mode executor 284 is provided.

[0067] Therefore, using Figure 2 and Figure 3As well as the example of Table 3, the charging port is decoupled from the battery to enable various functions within the vehicle. This allows for multiple batteries to be supported in the vehicle, multiple charging ports to be supported for the vehicle, and an M-to-N relationship between the charging ports and the batteries. In other cases, multiple charging ports (e.g., different types of charging ports) can be used to charge the same set of batteries. Other options are also possible. Data objects can be associated with each other using attributes within the VSS structure.

[0068] use

[0069] Various examples are provided below to indicate how the decoupling of the charging port and battery, and more generally the association between data objects using properties, can be used in practice.

[0070] Is my car plugged in?

[0071] In one example, a driver may arrive at their office and not remember whether they plugged the vehicle in at the parking lot. In previous VSS systems, there was only one battery and one charging port, so this relationship was set. However, in more modern vehicles with multiple batteries and potentially multiple charging ports, such a query is not so simple.

[0072] Therefore, now refer to Figure 4 .exist Figure 4 In the example of , phone application 410 can communicate with vehicle communication subsystem 412. Phone application 410 can be an application on a mobile phone. Vehicle communication subsystem 412 can be on a vehicle.

[0073] In some cases, such communication may be direct communication. For example, if the vehicle communication subsystem and the phone application are both on the same Wi-Fi network, they may be able to communicate directly with each other.

[0074] In other cases, communications may be conducted over a cellular network or other wide area network. In such cases, there may be an intermediary server to facilitate the communications. For example, a vehicle manufacturer may have a server through which all communications routed to the vehicle need to pass.

[0075] Other examples are also possible

[0076] The vehicle communication subsystem 412 may store a copy of the VSS directory for the vehicle. The vehicle communication subsystem 412 may also store the latest status of the vehicle and may also collect signals from various sensors. Figure 4 In the example of FIG. 4 , a charging cable connection sensor 414 from a first charging port and a charging cable connection sensor 416 from a second charging port may provide signals that may be intercepted or collected by the vehicle communication subsystem 412. The charging cable connection sensors 414 and 416 may be on the vehicle.

[0077] In this case, the phone application 410 may query how many charging ports there are on the vehicle, as shown in message 420. Since the number of charging ports is a property of the vehicle, the vehicle communication subsystem 412 will store this information and may therefore provide a message 422 back to the phone application 410 indicating at least one of the number of charging ports, identifiers of the charging ports, paths to the charging ports, and other information.

[0078] The vehicle communication subsystem 412 may then intercept or collect the signal. For example, the charging cable connection sensor 414 may provide a signal that the charging cable is connected, as shown by message 430. Similarly, the charging cable connection sensor 416 may provide a signal 432 that the second charging port cable is connected.

[0079] At a later time, the charge cable connection sensor 416 may provide a signal 432 that the second charge port is disconnected. For example, the second charge port may have been disconnected by a third party who needs the cable, or the charge cable may not have been properly connected and became loose and disconnected, or the driver disconnected the cable, among other options.

[0080] The driver can use the phone application 410 to check whether the charging port is connected. In this case, a message 440 can be sent from the phone application 410 to the vehicle communication subsystem 412, asking whether the charging port 1 is connected. In response, the vehicle communication subsystem 412 can send a message 442 indicating that the charging port 1 is connected.

[0081] Similarly, message 450 may be sent from phone application 410 to vehicle communication subsystem 412 asking if charge port 2 is connected. In response, vehicle communication subsystem 412 may send message 452 indicating that charge port 2 is disconnected.

[0082] The phone application 410 may then consolidate the information and may provide a representation of the vehicle and charging port, for example, using a user interface.

[0083] Subsequently, if the first charging port is disconnected, the charging cable connection sensor 414 may send a message or signal 460 indicating that the port is now disconnected, which may be collected or intercepted by the vehicle communication subsystem 412 .

[0084] Thus, in this case, the phone application 410 may be constructed to interact with a vehicle having multiple batteries, multiple charging ports, or both.

[0085] What is the vehicle's range?

[0086] In vehicles with multiple batteries, the vehicle's range can be calculated at the vehicle communication subsystem or on an application that displays the range. Figure 5 and Figure 6 , which illustrate each of these scenarios.

[0087] exist Figure 5 In the embodiment of , a display system 510 in a vehicle is seeking to provide range information for display on a user interface. In this regard, the display system 510 communicates with a vehicle communication subsystem 512. The vehicle communication subsystem 512 maintains the state of the vehicle, stores a copy of the VSS tree including all properties, and intercepts or collects signals from various sensors and actuators. In this example, the communication may be over an internal bus. However, other communication techniques are possible.

[0088] exist Figure 5 In the example of FIG. 5 , the vehicle communication subsystem 512 collects or intercepts signals from a battery range sensor 514 of a first battery and a battery range sensor 516 of a second battery.

[0089] The battery range sensor 514 periodically transmits the battery range as a signal 520 , which is collected by the vehicle communication subsystem 512 .

[0090] Similarly, the battery range sensor 516 transmits a second battery range signal 522 , which is collected by the vehicle communication subsystem 512 .

[0091] Display system 510 in the vehicle may periodically request remaining range, as shown at message 530 , and receive vehicle range at message 532 .

[0092] In an alternative embodiment, a computing device associated with the display may calculate the effective range based on the range received from each individual battery. Figure 6 .

[0093] exist Figure 6 In an embodiment of the present invention, a display system 610 in the vehicle communicates with a vehicle communication subsystem 612. The vehicle communication subsystem 612 maintains the state of the vehicle, maintains a copy of the VSS directory with attributes for the vehicle, and collects signals from sensors and actuators including a range sensor 614 for the first battery and a range sensor 616 for the second battery.

[0094] In this case, if the display system 610 in the vehicle has not previously done so, it may request the number of batteries in the vehicle in a message 620. Such a number of batteries is stored as a property in the vehicle communication subsystem 612, and is therefore returned in a message 622. In some cases, the message 622 may contain the addresses of the batteries, such as vehicle.powertrain.tractionbattery.battery1 and vehicle.powertrain.tractionbattery.battery2. In some cases, this information may be obtained by first looking up the charging ports and then, for each charging port, looking up the battery associated with the charging port. Other options are also possible.

[0095] A range sensor in the battery may periodically provide its range, for example as signals 630 and 632 .

[0096] Using this information, display system 610 may request the range of the first battery in message 640 and receive a response 642 .

[0097] The display system 610 in the vehicle may request the range of the second battery from the vehicle communication subsystem 612 in message 644 and receive a response in message 646 .

[0098] The vehicle's range may then be calculated and displayed at display system 610 .

[0099] Ambulance Fleet Monitoring

[0100] In another example, an emergency operations center may monitor a fleet of ambulances, some of which are electric and others of which are gasoline. The electric ambulances may have two charging ports, a first charging port for a traction battery and a second charging port for emergency equipment. In particular, the emergency equipment battery may have to meet certain specifications or standards that the traction battery may not. Furthermore, the charging ports for such emergency batteries may have different specifications and standards.

[0101] In this regard, Figure 7 As shown, the emergency operation center 710 can communicate with various ambulances and Figure 7 , an ambulance is shown with a vehicle communication subsystem 712. The vehicle communication subsystem 712 can maintain the state of the vehicle, properties from the VSS tree, and collect signals from sensors and actuators.

[0102] exist Figure 7In the example of FIG. 7 , various battery sensors may be providing status signals that may be collected by the vehicle communication subsystem 712. In particular, the emergency device battery charge status sensor 714 may periodically provide a battery charge status message 720. The traction battery 716 may periodically provide a battery charge status signal 722. The traction battery 718 may also periodically provide a battery charge status signal 724.

[0103] Signals 720 , 722 , and 724 may be captured by the vehicle communication subsystem 712 and stored as part of the state of the vehicle.

[0104] When the emergency operations center wants to update the status of its fleet, it can ask the specific vehicle communication subsystem 712 how many charging ports the ambulance has in message 730. The number of charging ports is a known property of the vehicle communication subsystem 712 and is returned in response 732.

[0105] The emergency operations center can then obtain identifiers or addresses of the various batteries. Specifically, as shown in message 734, the emergency operations center 710 can request information about the batteries served by charging port 1. In response, message 736 can provide an identifier or namespace for the batteries served by charging port 1. For example, this can be a string with an array of enumeration values ​​listed in Vehicle.ChargingPort.Port1.Batteries.

[0106] For example, if charging port 1 relates to a charging port for emergency equipment such as medical equipment on an ambulance, the string returned may be similar to [vehicle.emergency.battery] if a single battery is present for the device. In other cases, multiple batteries may be identified. In yet other cases, a unique identifier for the battery may be provided, rather than a path or namespace. Other options are possible.

[0107] Similarly, the emergency operations center 710 may send a request for batteries associated with port 2 in message 738 and receive an array of identifiers or enumeration values. For example, if charging port 2 is associated with a traction battery, the response 740 may include [vehicle.powertrain.tractionbattery.battery1,

[0108] vehicle.powertrain.tractionbattery.battery2].

[0109] Once the emergency operations center 710 has a list of all batteries on the vehicle, the charge status of these batteries can be queried. Figure 7 In the example of , this is shown as message 750. As will be appreciated by those skilled in the art, message 750 may include a single message having all batteries whose information is sought. In other cases, message 750 may be broken down into individual messages for each battery identified in responses 734 and 738.

[0110] A battery status response 752 may be provided from the vehicle communication subsystem 712 back to the emergency operations center based on the battery status collected by the vehicle communication subsystem 712. Likewise, the message 752 may be a single message or may be broken into multiple messages, each addressing the status of a single battery.

[0111] The emergency operations center 710 can then update its systems to provide the latest information on the status of the fleet. For example, if the battery power is too low, this can allow mitigation measures to be taken.

[0112] Other information options are also possible

[0113] In this manner, the emergency operations center does not need to know the current configuration of any particular vehicle, but can use a request to the vehicle communication subsystem to identify the number of charging ports, the number of batteries, and the status of each battery.

[0114] Example Vehicle Systems

[0115] The present disclosure is described with respect to an automotive system having nodes. However, this is for illustration purposes only, and the methods and systems described herein may also be used with any other system.

[0116] For example, now refer to Figure 8 , which shows a node 810. As used herein, a node may be one or a group of electronic control units, central processing units or core controls, among other options, and may be considered a single computing unit.

[0117] exist Figure 8 In the example of , the node 810 includes a service manager 820 that can interact with a driver for a sensor to which the node is connected. For example, the node 810 can be able to access a location sensor, such as a global positioning system (GPS) chipset, as shown in block 822.

[0118] In order to allow the node 810 to interact with modules on other nodes and provide functionality for the computing system, a hardware abstraction layer (HAL) may be provided on the node 810, which includes HAL services 830. Each HAL service 830 is responsible for sensor integration and may provide various functions, including: integration with underlying sensors; standardization of sensor data; and / or, if necessary, providing a barrier between securely certified and non-certified software. Other functions of the HAL service are also possible.

[0119] exist Figure 8 In the example of , the HAL is provided for camera information, as shown in box 832.

[0120] Although Figure 8 The example of shows a node 810 with a single service and a single HAL, but this is for illustration purposes only. Node 810 can have a single service without a HAL, a single HAL without a service, multiple services without a HAL, multiple HALs without a service, and / or a combination of services and HALs.

[0121] An example of a system in which node 810 may be used is an application development environment for a vehicle. Such an application development environment may develop applications for user experience (including comfort, navigation, infotainment, etc.), applications for safety, applications for fleet management; applications for performance monitoring; or other such applications for a vehicle environment. In particular, vehicles provide multiple sensors, and different makes, models, or brands may use different sensors with different data formats or values, thereby generating fragmented sensor readings from such sensors. This fragmentation hinders the cultivation of an application ecosystem that utilizes vehicle data. In addition, low-level sensor data is often too granular to be easily used in applications.

[0122] In this regard, a hardware abstraction layer can be used to provide a hardware-independent sensor interface / abstraction that can encapsulate the interaction with the underlying sensor driver. The use of hardware abstraction in various computing nodes creates a scalable platform that can provide barriers between modules, for example, enforcing safety authentication systems to be separate from other systems, among other options.

[0123] Applications do not interact directly with sensor hardware to access sensor data, but instead utilize the Hardware Abstraction Layer. This separation provides a clear separation of responsibilities between the HAL (sensor integration and normalized sensor data) and other abstraction layers, such as the Vehicle Abstraction Layer (VAL), for managing access to vehicle data and providing value-added insights.

[0124] Specifically, insights can leverage sensor data from multiple HALs in order to provide vehicle abstractions and value-added insights. Vehicle insight services in the VAL can control access to vehicle data in a standardized form and provide value-added inferences. Examples of insight services may include location services, which can provide coordinate location data in a consistent format as well as insights such as geo-fencing; seat services, which can provide a myriad of seat information such as seat belt status, weight, location, and child lock status; camera services, which can provide video streams for cameras in the cabin and may have functions such as conversion and / or clipping; battery services, which can provide insights and access to the battery, such as charge status / consumption / estimated remaining hours / estimated range; door services, which can provide abstractions for doors and door states; and so on.

[0125] Insight services can leverage sensor data from multiple HALs to provide vehicle abstractions and value-added insights. Higher-level data insights enable application developers to create the automotive experience of the future. Insight is the term used to describe any value-added interpretation of basic sensor data. Insights can be as simple as data aggregation or correlation or as complex as artificial intelligence and machine learning. For example, for a temperature sensor, providing high and low watermarks for notifications can be considered an "insight". For location services, geo-fencing is an insight, and for cameras, passenger identification can be considered an insight.

[0126] Therefore, this application development environment requires Figure 8 Node with services and HAL manager shown. In many systems, node 810 will need to communicate with other nodes, such as other ECUs, CPUs, or computing systems, where such ECUs, CPUs, or computing systems may use a different operating system than node 810.

[0127] Such a system can use a modified VSS system to look up data objects and data object associations with vehicles. In this regard, the vehicle abstraction layer can easily provide information regardless of the specific make and model of the vehicle whose information is sought.

[0128] Example computing system

[0129] The above network elements, nodes, computing devices and other computing platforms can be implemented using any computing device. Fig. 9 A simplified diagram of a computing device is shown. Fig. 9 The computing device may be any fixed or mobile computing device.

[0130] exist Fig. 9In the embodiment, the device 910 includes a processor 920 and a communication subsystem 930, wherein the processor 920 and the communication subsystem 930 cooperate to perform the method of the above embodiment. The communication subsystem 930 allows the device 910 to communicate with other devices or network elements and can vary based on the type of communication being performed. In addition, the communication subsystem 930 can include a variety of communication technologies, including any wired or wireless communication technology.

[0131] Processor 920 is configured to execute programmable logic that may be stored on device 910 along with data and may be used to perform operations such as performing a programmable logic operation on the device 910. Fig. 9 In the example of , the memory 940 is shown. The memory 940 can be any tangible, non-transitory computer-readable storage medium that stores instruction codes that, when executed by the processor 920, cause the device 910 to perform the method of the present disclosure. The computer-readable storage medium can be a tangible or transient / non-transitory medium, such as an optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flash drive, hard drive, or other memory known in the art.

[0132] As an alternative or in addition to memory 940 , device 910 may access data or programmable logic from an external storage medium, such as through communication subsystem 930 .

[0133] exist Fig. 9 In the example of , one or more internal sensors 970 or external sensors 972 can be associated with the computing device. However, this is optional, and in some cases, the computing device 910 will not be associated with a sensor.

[0134] In one embodiment, communication between the various elements of device 910 may occur via internal bus 960. However, other forms of communication are possible.

[0135] The embodiments described herein are examples of structures, systems or methods with elements corresponding to the elements of the technology of the present application. This written description can enable those skilled in the art to make and use embodiments of alternative elements with elements similar to the technology of the present application. Therefore, the intended scope of the technology of the present application includes other structures, systems or methods that are not different from the technology of the present application described herein, and also includes other structures, systems and methods that are not substantially different from the technology of the present application described herein.

[0136] Although operations are depicted in a particular order in the accompanying drawings, this should not be understood as requiring that such operations be performed in the particular order shown or in sequence or that all of the operations shown be performed to achieve the desired results. In some cases, multitasking and parallel processing may be employed. In addition, the separation of various system components in the above implementations should not be understood as requiring such separation in all implementations, and it should be understood that the described program components and systems may generally be integrated into a single software product or packaged into multiple software products.

[0137] In addition, techniques, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations may be combined or integrated with other systems, modules, techniques, or methods. Other items illustrated or discussed as coupled or directly coupled or communicating with each other may be indirectly coupled or communicating through some interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples may be ascertained and changes, substitutions, and alterations may be made by those skilled in the art.

[0138] Although the above detailed description has shown, described and pointed out the basic novel features of the present disclosure as applied to various implementations, it should be understood that various omissions, substitutions and changes in the form and details of the system shown may be made by those skilled in the art. In addition, the order of the method steps is not implied by the order in which they appear in the claims.

[0139] When a message is sent to or from an electronic device, such an operation may not be immediate, nor may it be sent directly from a server. They may be delivered synchronously or asynchronously from a server or other computing system infrastructure supporting the device / method / system described herein. The above steps may include synchronous / asynchronous communication with the device / infrastructure in whole or in part. In addition, the communication from the electronic device may be to one or more endpoints on the network. These endpoints may be served by servers, distributed computing systems, stream processors, etc. A content delivery network (CDN) may also provide communication with an electronic device. For example, in addition to typical server responses, a server may also supply or indicate data to a content distribution network (CDN) to wait for downloading by an electronic device at a later time, such as subsequent activities of an electronic device. Therefore, data may be sent directly from a server or other infrastructure (such as a distributed infrastructure or CDN) (which is part of the system or separated from the system).

[0140] In general, the storage medium may include any one or some combination of the following: a semiconductor memory device, such as a dynamic or static random access memory (DRAM or SRAM), an erasable programmable read-only memory (EPROM), an electrically erasable programmable read-only memory (EEPROM), and flash memory; a disk, such as a fixed disk, a floppy disk, and a removable disk; another magnetic medium, including magnetic tape; an optical medium, such as a compact disk (CD) or a digital video disk (DVD); or another type of storage device. Note that the above instructions may be provided on one computer-readable or machine-readable storage medium, or alternatively, may be provided on multiple computer-readable or machine-readable storage media distributed in a large system that may have multiple nodes. Such a computer-readable or machine-readable storage medium is considered to be part of an article (or product). An article or product may refer to any manufactured single component or multiple components. One or more storage media may be located in the machine that runs the machine-readable instructions, or may be located at a remote site from which the machine-readable instructions may be downloaded over a network for execution.

[0141] In the above description, many details are set forth to provide an understanding of the subject matter disclosed herein. However, implementations may be practiced without these details. Other implementations may include modifications and variations to the above details. The appended claims are intended to cover such modifications and variations.

Claims

1. A method at a computing device, comprising: sending a request to a vehicle communication subsystem to determine a number of charging ports on the vehicle; receiving a response providing the number of the charging ports on the vehicle; sending a request to the vehicle communication subsystem to find a battery associated with each charging port; as well as A response is received identifying a battery associated with each charging port. 2 . The method of claim 1 , wherein the number of charging ports is defined as a property of the vehicle.

3. The method of claim 1 , wherein the batteries associated with each charging port are returned in the response as an enumerated list of battery addresses.

4. The method according to claim 3, further comprising: For each battery in the enumerated list of battery addresses, a request is sent to the vehicle regarding the status of the battery and a response is received.

5. The method of claim 4, wherein the charging port has a plurality of traction batteries associated therewith.

6. The method of claim 1, wherein the request to the vehicle communication subsystem to determine the number of the charging ports on the vehicle comprises a vehicle signal specification (VSS) request, wherein Vehicle.ChargingPort.PortCount is a property of the vehicle.

7. The method of claim 6, wherein each charging port is identified as Vehicle.ChargingPort.PortX, where X is an integer between 1 and a port count value.

8. The method of claim 1, wherein the battery is associated with more than one charging port.

9. The method of claim 1, wherein the number of charging ports is greater than or equal to 2, and wherein the battery associated with a first charging port comprises a traction battery and the battery associated with a second charging port comprises an emergency equipment battery for the vehicle.

10. A computing device comprising: processor; as well as Communication subsystem, The computing device is configured to: sending a request to a vehicle communication subsystem to determine a number of charging ports on the vehicle; receiving a response providing the number of the charging ports on the vehicle; sending a request to the vehicle communication subsystem to find a battery associated with each charging port; as well as A response is received identifying a battery associated with each charging port. The computing device of claim 10 , wherein the number of charging ports is defined as a property of the vehicle.

12. The computing device of claim 10, wherein the batteries associated with each charging port are returned in the response as an enumerated list of battery addresses.

13. The computing device of claim 12, wherein the computing device is further configured to, for each battery in the enumerated list of battery addresses, send a request to the vehicle regarding a status of the battery and receive a response.

14. The computing device of claim 13, wherein the charging port has a plurality of traction batteries associated therewith.

15. The computing device of claim 10, wherein the request to the vehicle communication subsystem to determine the number of the charging ports on the vehicle comprises a vehicle signal specification (VSS) request, wherein Vehicle.ChargingPort.PortCount is a property of the vehicle.

16. The computing device of claim 15, wherein each charging port is identified as Vehicle.ChargingPort.PortX, where X is an integer between 1 and a port count value.

17. The computing device of claim 10, wherein the battery is associated with more than one charging port.

18. The computing device of claim 10, wherein the number of charging ports is greater than or equal to 2, and wherein the battery associated with a first charging port comprises a traction battery and the battery associated with a second charging port comprises an emergency equipment battery for the vehicle.

19. A non-transitory computer readable medium for storing instruction codes which, when executed by a processor of a computing device, cause the computing device to: sending a request to a vehicle communication subsystem to determine a number of charging ports on the vehicle; receiving a response providing the number of the charging ports on the vehicle; sending a request to the vehicle communication subsystem to find a battery associated with each charging port; as well as A response is received identifying a battery associated with each charging port.

20. The non-transitory computer readable medium of claim 19, wherein the number of charging ports is defined as a property of the vehicle.

Images