Method and system for data object identification in a vehicle

Abstract

Embodiments of the present disclosure relate to methods and systems for data object identification in vehicles. A method at a computing device for finding associations between data objects in a structure, the method comprising selecting a coordinate location from a grid, the grid defining locations within the structure; finding whether a data object having a data object type is located at the coordinate location; when the data object is located at the coordinate location, associating the data object with other data objects at the coordinate location; and when the data object is not located at the coordinate location: determining that a data object at a second location serves the first location by an explicit association; and associating the data object with the coordinate location.

Description

Technical Field

[0001] This disclosure relates to vehicle systems, and more particularly to objects within such vehicle systems. Background Technology

[0002] Modern vehicles have numerous components and sensors. These components and sensors can be referred to as data objects and can be queried and combined to provide insights into the vehicle and its operation.

[0003] However, using the current tree structure to define data objects is rigid and results in large, difficult-to-create data files. Furthermore, such a tree-like data structure grows exponentially based on the relationships between data objects. Attached Figure Description

[0004] This disclosure will be better understood with reference to the accompanying drawings, in which:

[0005] Figure 1 This is a diagram illustrating a tree structure used to classify objects.

[0006] Figure 2 This is a block diagram illustrating an example mesh structure used to position objects within a structure.

[0007] Figure 3 This is a block diagram illustrating another example mesh structure used for locating objects within a structure.

[0008] Figure 4 It is a flowchart used to assign data objects to a grid structure and define the associations for the data objects.

[0009] Figure 5 It is a process diagram used to determine whether a driver's seat is occupied based on a vehicle definition using a grid structure.

[0010] Figure 6 It is a process diagram used to determine whether passenger windows are open in vehicle definitions based on a grid structure.

[0011] Figure 7 It is a process diagram used to find which HVAC system service seats are based on the vehicle definition using a grid structure.

[0012] Figure 8 It is a process diagram used to find which HVAC system service seats are based on the span defined within the vehicle using a grid structure.

[0013] Figure 9 It is a flowchart used to find which data object serves another data object or location based on the vehicle definition using a grid structure.

[0014] Figure 10 This is a block diagram illustrating the computation node of an example vehicle.

[0015] Figure 11 This is a block diagram of a simplified computing device that can be used with embodiments of the present disclosure. Detailed Implementation

[0016] This disclosure provides a method for finding associations between data objects in a structure at a computing device, the method comprising: selecting coordinate locations from a grid that defines locations within the structure; determining whether a data object of a data object type is located at the coordinate location; when the data object is located at the coordinate location, associating the data object with other data objects at the coordinate location; and when the data object is not located at the coordinate location: determining that a data object at a second location serves a first location by explicit association; and associating the data object with the coordinate location.

[0017] This disclosure also provides a computing device configured to find associations between data objects in a structure, the computing device including: a processor; and a communication subsystem, wherein the computing device is configured to: select coordinate locations from a grid, the grid defining locations within the structure; determine whether a data object having a data object type is located at the coordinate location; when the data object is located at the coordinate location, associate the data object with other data objects at the coordinate location; and when the data object is not located at the coordinate location: determine a data object at a second location serving a first location through explicit coordinate-based association; and associate the data object with the coordinate location.

[0018] This disclosure also provides a computer-readable medium for storing instruction code that, when executed by a processor of a computing device configured to find associations between data objects in a structure, causes the computing device to: select coordinate locations from a grid that defines locations within the structure; determine whether a data object of a data object type is located at the coordinate location; when the data object is located at the coordinate location, associate the data object with other data objects at the coordinate location; and when the data object is not located at the coordinate location: determine that a data object at a second location serves a first location by explicit association; and associate the data object with the coordinate location.

[0019] In modern transportation, information from one or more physical sensors can be processed to create “insights” that may be valuable within the system. Such one or more physical sensors and their associated processing can logically be referred to as microservices or synthetic sensors (SS). The terms microservices and synthetic sensors are used interchangeably in this document.

[0020] Synthetic sensors can be used in other types of applications, including but not limited to medical applications, manufacturing applications, and Internet of Things applications, and this disclosure is not limited to transportation applications. Transportation applications are provided below for illustration.

[0021] Insight, as used in this article, describes any computer-generated sensor data based on the interpretation of a basic set of sensor data generated from objects representing vehicle components (data objects). Insights can be as straightforward as data aggregation or correlation, or as complex as artificial intelligence and machine learning. For example, temperature sensors providing high and low water level indicators for notifications can be considered an "insight." For location services, geofencing is an insight. For cameras, occupant identification can be an insight. The combined use of sensors (such as temperature sensors and cameras) with artificial intelligence models to determine if a car seat is occupied in a hot vehicle can be an insight. Many other examples of insights are possible.

[0022] In one embodiment, transportation applications can be implemented within a system that provides consistent access to transportation data and intelligent insights in a manner familiar and accessible to the developer community. Such an environment could allow cloud developers to extend their capabilities to the edge within transportation by developing synthetic sensors that derive intelligent insights from transportation data using common cloud development technologies and paradigms. This environment can provide consistent access to transportation data, enabling synthetic sensors to be programmed and deployed across a broad transportation infrastructure without customization.

[0023] However, in order to easily access such transportation data, the data objects within the transportation need to be identified and located, and the relationships between the various data objects within the transportation need to be easily identified.

[0024] This can be complicated by different naming and relational conventions used by different vehicle manufacturers. To overcome this problem, the Vehicle Signaling Specification (VSS) is currently in use. The VSS defines itself as a way to create a common understanding of vehicle signals, achieving a common language independent of the protocols or serializations used.

[0025] VSS naming conventions are described, for example, in Table 1 below.

[0026]

[0027] Table 1: Example VSS Naming Conventions

[0028] As can be seen from Table 1 above, the VSS standard uses dotted name paths to identify components, and the last component in the name path is a signal or property.

[0029] By using dotted-tag name paths, a tree structure can be constructed for various data objects within a vehicle. For example, now refer to Figure 1 .

[0030] exist Figure 1 In one embodiment, the object tree 100 has a vehicle 110 as its root. Below this root, an example in the tree might be a cabin 120.

[0031] Cabin 120 may have a door, as shown in door 130.

[0032] The gate can be defined based on the rows in the vehicle, namely row 1 140 and row 2 142.

[0033] Furthermore, the doors in each row can be specified based on their location within the vehicle. Specifically, the door in row 1, 140 could be either left door 150 or right door 152. Similarly, the door in row 2, 142 could be either left door 154 or right door 156.

[0034] The positioning of component instances within the tree structure is very strict and has various drawbacks. Specifically, vehicles have components with multiple instances. This makes the VSS tree very large. The VSS specification is also less suitable for non-standard vehicles, such as sidecar motorcycles, buses, double-decker buses, center-drive vehicles, motorized rickshaws, etc. As used in this paper, a component is a specific element of a vehicle, and the collection of sensors derived from these components can be referred to as a data object.

[0035] Furthermore, some instances of these components are associated with other components. For example, a vehicle may have multiple seats and multiple heating, ventilation, and air conditioning (HVAC) units. Seats and HVAC units may be associated with each other but not necessarily in the same location. For instance, the middle seat in the second row of a vehicle may be served by HVAC units located below the left and right front seats.

[0036] Modern transportation systems require a way to represent components and associate them with other components, so that users of the transportation service application programming interface (API) can easily query components and their associations, and thus derive data from them.

[0037] Using tree structures (such as those described with VSS), listing all the relationships between pairs becomes exponentially based on the number of components. Since modern transportation has many components, listing such relationships becomes costly.

[0038] Therefore, according to embodiments of this disclosure, a three-dimensional mesh structure is provided for defining the positioning of components. Such a mesh assigns positioning to all components.

[0039] In particular, the 3D mesh system will support any type of vehicle, from cars to double-decker buses, as well as motorcycles and oddly shaped vehicles such as McLarens. TM 3 seats.

[0040] As a result, default relationships are also created. By default, components in the same grid location can be automatically associated. For example, in the Cabin API, given a seat, an API user can find HVAC, screens, seat belts, windows, and other objects that serve the seat simply because they are located in the same grid location.

[0041] A mesh system provides three separate coordinates for locating components within a vehicle. A single mesh system for the entire vehicle or separate mesh systems for individual parts of the vehicle (such as compartments) can be implemented. The three separate coordinates can be defined as triples, such as (x, y, z) triples. However, in some other embodiments, other orderings or coordinate systems may be utilized.

[0042] In one embodiment, the first coordinate may correspond to the concept of a row, the second coordinate to the concept of a column, and the third coordinate to the concept of a layer. In other embodiments, the coordinates may represent rows, columns, and layers in a different order.

[0043] Furthermore, rows can be arranged in ascending order from front to back, columns in ascending order from left to right, and layers in some cases can be arranged in ascending order from lowest to highest. However, this is provided merely for illustrative purposes, and sorting can be performed in different ways.

[0044] Furthermore, when defining a coordinate system, the origin can be specified. In some cases, the index can be, for example, zero or one. In other cases, it is necessary to determine whether negative indices are supported.

[0045] These and other components are described below.

[0046] Now for reference Figure 2 .exist Figure 2 In the middle, the vehicle 200 has a grid system 210 for identifying the location of data objects within the vehicle. From Figure 2 As can be seen in the embodiments, grid 210 includes two rows and three columns. Furthermore, a single layer exists within grid 210.

[0047] exist Figure 2In the example, the grid is organized as a numbered system from the front to the rear of the vehicle. Therefore, the (x, y, z) triplet identifying each location within the grid uses the "x" value to represent the row, the "y" value to represent the column, and the "z" value to represent the layer. The "x" values ​​are counted from the front to the rear of the vehicle, starting with index "1". For example, this allows index "0" to indicate "all rows".

[0048] Similarly, columns are counted from left to right, starting with the index value "1".

[0049] Furthermore, in multi-level transportation vehicles, the layers will start with layer 1, which is the layer closest to the ground, then layer 2 for the next layer, and so on.

[0050] Various components or data objects can be defined within grid 210. For example, Figure 2 The embodiment illustrates an HVAC system 220 located at grid location (2,2,1) in the rear middle seat. As described below, HVAC system 220 can be automatically associated with the rear middle seat based on the fact that it is co-located with the rear middle seat in the grid system. However, HVAC system 220 can also serve the left rear seat at grid location (2,1,1), as shown by association 222, and the right rear seat at grid location (2,3,1), as shown by association 224.

[0051] Similarly, HVAC system 226 can serve such a seat based on the fact that it is co-located with a seat at grid location (1,1,1). HVAC system 228 can serve such a seat based on the fact that it is co-located with a seat at grid location (1,3,1).

[0052] Display system 230 can be found at grid position (2,1,1). In this respect, display system 230 can serve the seat at grid position (2,1,1).

[0053] Display system 232 can be found at grid position (2,3,1). In this respect, display system 232 can serve the seat at grid position (2,3,1).

[0054] The rear center seat at grid position (2,2,1) does not have a display system at its location. However, the passenger in the rear center seat can use either display system 230 or display system 232. In this regard, association 234 is provided for display system 230 at grid position (2,2,1), and association 236 is provided for display system 232 at grid position (2,2,1).

[0055] Figure 2The examples shown are merely simplified illustrations of a grid system with various components. Each component or data object can co-address with other data components, thus creating a first implicit association between data objects in some cases, or can be associated with other grid locations using a second explicit association. Figure 2 The embodiment shown only illustrates the cabin portion of the vehicle and the grid applied to it. In other cases, the grid can be applied to the entire vehicle, or the vehicle can have multiple grid systems targeting individual spaces within the vehicle. Other options are also possible.

[0056] Mesh granularity

[0057] Although Figure 2 The implementation defines the mesh based on seats and rows within a cabin, but in some cases, the original equipment manufacturer (OEM) may decide to define a finer-grained mesh for their vehicles. For example, the chosen granularity can be made by balancing the precision or granularity level it provides with the loss of simplicity offered by co-location. Furthermore, in some cases, the implicit "service" relationships created by co-location may not be desirable, thus requiring a finer-grained mesh. That is, choosing a low-granularity mesh may create implicit associations that are not guaranteed in some cases, thus necessitating the selection of a finer-grained mesh.

[0058] For example, a window can be clearly associated with a seat. However, other components may not have a clear definition of a seat in terms of positioning.

[0059] Now for reference Figure 3 It shows a comparison Figure 2 The mesh is finer-grained for vehicle 300, mesh 310. Specifically, Figure 3 The example shows a grid with four rows, three columns, and one layer.

[0060] In this configuration, the vehicle manufacturer can assign seat positions in the second and fourth rows. Specifically, front seats 312 and 313 can be assigned to positions (2,1,1) and (2,3,1) respectively. Rear seats 314, 316, and 318 can be assigned to positions (4,1,1), (4,2,1), and (4,3,1) respectively.

[0061] Row 1 can indicate the dashboard positioning, and row 3 can be associated with the seat back or the back of the front center console. In this regard, HVAC systems 320 and 322 can be positioned at (1,1,1) and (1,3,1). Such HVAC systems are correspondingly used for seats at (2,1,1) and (2,3,1), and this is illustrated by HVAC associations 324 and 326. Those skilled in the art will understand that when... Figure 2 Compared to the previous embodiment, Figure 3 The creation of finer-grained meshes loses the implicit association between seating and HVAC units. However, it gains more specificity.

[0062] Similarly, the HVAC system 330 centered in row 3 at position (3,2,1) can be used to serve the entire following row. This is illustrated by HVAC association 332 at position (4,1,1), HVAC association 334 at position (4,2,1), and HVAC association 336 at position (4,3,1).

[0063] In some cases, for the benefit of rear passengers, transportation may include entertainment screens on the backs of the front seats. This is in Figure 3 In the embodiments, entertainment screen 340 at position (3,1,1) and entertainment screen 342 at position (3,3,1) are shown.

[0064] Screen 340 can be used by the occupant of seat (4,1,1), as shown via screen association 350. Screen 342 can be used by the occupant of seat (4,3,1), as shown via screen association 352. The occupant of seat (4,2,1) can use either screen 340 or 342, therefore seat (4,2,1) is shown as having screen associations 354 and 356.

[0065] Therefore, as Figure 2 and Figure 3 The grid system shown can be scaled to the granularity required by the vehicle manufacturer or entities that define the location of data objects within a vehicle / space / structure.

[0066] Associations / Relationships / Services

[0067] According to some embodiments of this disclosure, data objects at a specific location can be intrinsically associated with each other by being in the same grid position. Specifically, a seatbelt sensor located in the same grid position as a seat will be intrinsically associated with that seat based on its position.

[0068] However, in some cases the intrinsic relationship based on grid positioning may not be desired, and therefore the intrinsic relationship is optional in some cases.

[0069] In addition, such as regarding Figure 2 and Figure 3 As described, in some embodiments, it is necessary to create associations or relationships between components that cannot be easily expressed based on location. While a window can be easily associated with a specific seat based on both having the same coordinates, this association or relationship is not always locational. (Reference) Figure 2 and Figure 3The HVAC system for the rear seats can be positioned in the middle but oriented towards a specific seat. When the HVAC is centered at (2,2,1), queries within the calculation system (such as "which HVAC is serving the seat at (2,1,1)") cannot be answered by checking if there is an HVAC at (2,1,1).

[0070] Furthermore, in some embodiments, the "service" label may not be static, but rather conditional or dynamic. For example, in Figure 3 In one embodiment, display 340 can be tilted so that it can be seen at positions (4,1,1) and (4,2,1). Display 342 can be oriented so that it is only visible at position (4,3,1). The association at position (4,2,1) can be dynamic, for example, based on tilt sensors within displays 340 and 342.

[0071] In this regard, different approaches can be used, and in addition to co-location-based associations, OEMs can have the ability to define specific associations. (See reference...) Figure 2 and Figure 3 The association is shown as, for example, for use in Figure 2 The HVAC system 220 in the middle is associated with 222 and 224 and is used for Figure 3 The associations 332, 334, and 336 of the HVAC system 330 in the embodiments are shown. This can be accomplished using the "Services" tab in one embodiment, as described below.

[0072] express

[0073] Using the above information Figure 2 and Figure 3 The described grid method provides a mechanism that allows vehicle manufacturers or other service providers to define cabin contents and coordinate assignments. More generally, it provides a mechanism that allows data objects to be assigned locations within a grid for a service area (such as a vehicle).

[0074] Such coordinates can be encoded in various ways. The example below provides a JavaScript Object Notation (JSON) implementation. However, this JSON implementation is provided for illustrative purposes only, and those skilled in the art will understand that other notations can also be used.

[0075] In the notation below, coordinates are triples of a JSON array of three positive integers.

[0076] Furthermore, in the notation below, a grid is being created for the compartments of a vehicle. Again, this is for illustrative purposes only; a grid can be used for any number of structures. In the example below, the label "compartment" is used to indicate the root of the compartment structure. If the grid is used for other purposes, the root could be something like "chassis," "engine compartment," etc., for a vehicle grid, or "home," etc., for a home automation application.

[0077] The “coordinates” label can be used anywhere to define specific coordinates. Its value is an array of three integers, corresponding to the row, column, and layer respectively. However, in some implementations, the coordinates may be two-dimensional.

[0078] Typically, such coordinate labels are not used directly under the "cabin" label, but rather the location of such data objects is specified through other text.

[0079] For example, refer to Table 2 below:

[0080]

[0081] Table 2: Examples of coordinate labels

[0082] As shown in Table 2 above, the label for a data object is referred to as "a certain label," which refers to a data object that is predefined in the system or can be created by various end users. In this case, the coordinates of the data object are specified as a triple, indicating that the object is located in row 2, column 2, and layer 2.

[0083] In addition to providing coordinates, data objects can also have information about the location where the digital object serves. For example, referring to Table 3 below, a data object can be specified to be located at a specific coordinate position and serve various locations.

[0084]

[0085] Table 3: Examples of Service Tags

[0086] As shown in Table 3 above, the data object is located at position (2,2,2), which means it is in the second row, second column, and second level. The data object serves positions (2,1,2), (2,2,2), and (2,3,2).

[0087] In the examples in Table 3, the object's own location is listed among the locations it serves. However, in some embodiments, its own location may be omitted because the data object may serve its own location. In other cases, however, there may be situations where a component or data object does not serve its own grid location; therefore, in some embodiments, the locations served by the data object may explicitly include the data object's own location.

[0088] In the example in Table 3, service locations are provided as an array of triples. However, other notation is also possible.

[0089] In some cases, it may be beneficial to specify the size of the grid for a platform, vehicle, or service area. This can be done, for example, using the “Size” label, as shown in the examples provided in Table 4 below.

[0090]

[0091] Table 4: Examples of size labels

[0092] Therefore, according to Table 4, the "Size" label can be used to define the size and granularity of the grid used for the cabin. Such a size label can then be used by the program to find maximum values, for example, for rows or columns. This can be used to find the back row of a seat, the front passenger seat, and other options. For example, in a left-hand drive vehicle, the driver might be positioned at (1,1,1). The size can be used to find that there are 3 columns, so the passenger would be located at (1,3,1), where column 3 is the maximum value for that column.

[0093] Furthermore, in some embodiments, when the grid is used for vehicles, it may be beneficial to specify the location of the driver's seat. This can be done, for example, using a "driver" label. In standard vehicles, the driver's seat can be identified according to Table 5 below.

[0094]

[0095] Table 5: Examples of driver tags with a single driver

[0096] From Table 5, assuming the grid is specified in columns from left to right, the driver is indicated as being on the left side of the vehicle. For right-handed vehicles, assuming the grid is specified in columns from left to right, in some embodiments the driver's position will be specified as the maximum column value (assuming no additional columns are added for the area next to the seat).

[0097] However, using the grid coordinate system of this disclosure, the specification is robust enough to capture anomalies. For example, in the case of a street sweeper that may have two driving positions, this can be specified according to Table 6 below.

[0098]

[0099] Table 6: Examples of driver tags with multiple driver positions

[0100] In Table 6, the driver label is specified in two positions: the left front seat position and the right front seat position.

[0101] Similarly, seats can be specified using the "Seat" label to define the coordinates for each seat. An example is provided in Table 7 below.

[0102]

[0103]

[0104] Table 7: Examples of Seat Labels

[0105] As shown in Table 7, various seats are defined in different locations.

[0106] Similarly, doors on vehicles can be specified using the “Door” label provided in Table 8 below.

[0107]

[0108] Table 8: Examples of Door Labels

[0109] Table 8 shows examples of four-door vehicles. In two-door vehicles, the coordinates can be associated with the front seats. For example, on a bus, the door might be located near the front and center along one side of the vehicle, depending on whether the bus is right-hand or left-hand driven. Other options are also possible.

[0110] Similarly, windows can be specified using the "window" tag. Examples of such window tags are shown in Table 9 below.

[0111]

[0112] Table 9: Examples of Window Labels

[0113] In some embodiments, the windows in Table 9 may be windows that can be raised or lowered. In this case, other windows within the vehicle may not be specified. For example, this could be used to determine whether a window is rolled up or down using synthetic sensors.

[0114] In some embodiments, it may be more efficient to programmatically label at least a subset of the various digital objects within a vehicle. For this purpose, ID tags can be used. In some embodiments, the ID tags can be unique to the vehicle to allow the digital objects to be correctly addressed. For example, in Table 10 below, the rear seats of a vehicle can be provided with an ID, which the program can then use to locate a specific seat in the vehicle, find an association for a specific seat, or specify an action for a specific seat within the vehicle.

[0115]

[0116]

[0117] Table 10: Examples of ID tags

[0118] As shown in Table 10 above, the rear seats are labeled “Seat-RL”, which means the left rear seat; “Seat-RM”, which means the middle rear seat; and “Seat-RR”, which means the right rear seat.

[0119] HVAC systems can be specified using the “hvac” label, as provided in Table 11 below.

[0120]

[0121]

[0122] Table 11: Examples of HVAC Labels

[0123] Similarly, the monitor screen can be specified using the "Monitor" label, as shown below.

[0124] The information provided in Table 12.

[0125]

[0126] Table 12: Examples of Display Labels

[0127] As shown in Table 12, display labels can be provided with coordinates and identifiers.

[0128] Furthermore, various options can be implemented to define associations. In one case, an association can be explicitly defined using the "Association" tag. For example, if the ID "hvac-RM" (the intermediate HVAC system following) has been defined for the subsequent HVAC system using the tag defined in the table above, indicating the intermediate HVAC system following, then the association tag can be defined in Table 13 as follows.

[0129]

[0130]

[0131] Table 13: Examples of Associated Tags

[0132] As seen in Table 13, each row specifies a single association. In this case, the association is specified based on the seat and the component or data object serving that seat. Thus, the rear middle seat specified using the ID label “Seat-RM” is associated with the rear middle HVAC system, the left rear display system, and the right rear display system.

[0133] However, other representations of associations are possible. For example, Table 14 and below show cases where multiple associations can be provided in a single row.

[0134]

[0135] Table 14: Another example of associated tags

[0136] Therefore, in the example in Table 14, the first element in each row defines the data object being served, and the remaining data objects in that row specify the services being provided. Thus, the rear middle seat is shown as being served by the rear middle HVAC system, the left rear display system, and the right rear display system.

[0137] In other cases, a more explicit distinction between the data object being served and the data object providing the service can be enumerated in the association. For example, in Table 15 below, the data objects providing the service can be provided in an array.

[0138]

[0139]

[0140] Table 15: Another example of associated tags

[0141] Therefore, the array of data objects used to provide services / functions in Table 15 can be a single-element array, or it can have multiple elements that provide services / functions to each seat.

[0142] In a further embodiment, the notation used for association can be in reverse order. Specifically, the data object providing the functionality or service can indicate to whom such service or functionality is being provided. This is illustrated, for example, in Table 16 below.

[0143]

[0144] Table 16: Another example of associated tags

[0145] Therefore, as shown in Table 16, the data object with the ID tag "hvac-RM" is the data object with the ID tags "seat-RL", "seat-RM", and "seat-RR".

[0146] In other cases, an association can be defined as unilateral or bilateral. A unilateral association would be in a single direction, such as an HVAC service providing services to seats. A bilateral association would be each data object providing services to other data objects, and could include, for example, sensors within a vehicle.

[0147] Furthermore, in Tables 13 to 16 above, associations are defined with respect to two data objects. For example, an association indicates that an HVAC system serves a specific seat. An association can be from a data object to a specific location, rather than specifying a particular data object. An example of a one-sided association specification for a location is shown using Table 17 below.

[0148]

[0149] Table 17: Another example of associated tags

[0150] Therefore, according to Table 17, the HVAC system service locations located at (2,2,1) are (2,1,1), (2,2,1) and (2,3,1).

[0151] Although Table 17 enumerates associations as a single association on each row, in some cases, associations can be grouped. For example, as shown in Table 18.

[0152]

[0153] Table 18: Another example of associated tags

[0154] In the example in Table 18, the first element after the HVAC label can indicate the element providing the functionality or service, and the remaining elements can indicate the location where the service is being provided.

[0155] Furthermore, in some embodiments, the JSON file defining data objects within the platform can include various information together. For example, coordinates and services can be specified together, as shown in Table 19.

[0156]

[0157]

[0158] Table 19: Examples of HVAC and Display Labels for Integrated Services

[0159] Therefore, in Table 19, the coordinates of the location of a data object are specified together with the location that such a data object serves. In the examples in Table 19, components without a "service" label are assumed to serve only their own location.

[0160] Therefore, Tables 2 to 19 provide information that can be compared with... Figure 2 and 3 The grid systems are used together to provide examples of various notations for a robust system for locating and utilizing data objects within a system or platform. The notations provided in Tables 2 through 19 are for illustrative purposes only and not for limitation. Those skilled in the art will recognize that other notations can also be used, and more or fewer labels or different labels can be used in a practical system.

[0161] span

[0162] use Figure 2 In the example of HVAC, although the rear seat HVAC is located in the middle, its "area of ​​influence" is clearly the entire rear seat. Therefore, in some embodiments, it may be valuable to consider the area of ​​influence independently of location. In this case, the allocation of the HVAC system to the grid would be done based on the area of ​​influence rather than the actual location within the cabin. In this case, the concept of span can be supported.

[0163] In this situation, the vehicle manufacturer may want to... Figure 2 In the embodiments, HVAC stations are placed within the grid system at locations (1,1,1), (1,3,1), and (2,1-3,1).

[0164] The term (2,1-3,1) indicates that in row 2, layer 1, the HVAC system applies to all columns 1 through 3.

[0165] Therefore, in one case, in addition to providing an association or instead of providing an association, a span can be provided to indicate the location of the HVAC station service.

[0166] Value allocation

[0167] The above is about Figure 2 and 3 The grids provided in Tables 2 through 19 can be created by anyone responsible for a particular structure or space. For example, in a vehicle setting, the original equipment manufacturer (OEM) might be responsible for defining the grid and populating it with data objects representing various data objects for the vehicle. In other cases, the provider of the synthetic sensors might create the vehicle definition within the grid structure. Other parties may also be involved.

[0168] In some cases, a mesh can be added by a third party after it has already been created. For example, in a transportation scenario, aftermarket sales of components may trigger an update of the mesh for a specific vehicle. Other options are also possible.

[0169] A simplified example of creating vehicle definitions in a grid structure. Figure 4 It was provided in China. Figure 4 The process begins at box 410 and proceeds to box 412, where a vehicle definition entity is created. The mesh granularity can be defined for such a vehicle. For example, the entity can specify about... Figure 2 The grid shown is sufficient in some cases. In other cases, regarding Figure 3 The specified grid can be used. In other cases, other grids can also be used.

[0170] Proceeding from box 412 to box 420, each data object within the structure in box 420 can be assigned a grid position. The syntax or notation used to assign such grid positions can, for example, use the examples in Tables 2 to 19 above.

[0171] Furthermore, various data objects can be associated with or serve other regions, and such associations or service regions can be defined in box 430. Box 430 illustrates the explicit creation of associations for data objects. These associations can be between two specific data objects, between a data object and a specific location, across the span of a data object and a location, and other options.

[0172] Starting from box 430, this continues to box 440 and ends.

[0173] use

[0174] The following examples illustrate how to use the vehicle definitions of the grid system using this disclosure in practice.

[0175] Is there a driver in the driver's seat?

[0176] In one example, the system might need to know whether the driver's seat is occupied. In situations where multiple driver seats may exist, the system will be concerned with whether any driver's seat is occupied. For instance, in the case of a street sweeper, the driver's presence indication should check whether the right-hand or left-hand driver's seat is occupied.

[0177] Therefore, using the grid system of this disclosure and the example in Table 6, a query can be performed to find all driver seats, and then a system check can be performed to find out if any of them are occupied.

[0178] Now for reference Figure 5 This illustrates an example procedure for determining the presence of a driver. The procedure begins in box 510 and proceeds to box 520, where the coordinates of the seats for all possible drivers are determined. This can be based on coordinates specified under the “Driver” label, as in the example defined in Table 6 above.

[0179] Once the coordinates of the driver's seat are found, the seat itself can be identified in box 522. If multiple coordinates exist, box 522 can select the first coordinate in the list of coordinates for the driver's seat and find the seat corresponding to that coordinate.

[0180] The process then proceeds to box 530, where an inspection is performed to determine whether the seat found at box 522 is occupied. This can occur, for example, using a seat occupancy sensor (such as a pressure sensor within the seat itself). The seat occupancy sensor can be associated with coordinates for the seat or as an attribute of the seat itself.

[0181] If it is determined in box 530 that the seat is not occupied, the process proceeds to box 532, where a check is performed to determine whether the coordinates for the other driver's seat have been returned in box 520.

[0182] If so, the process returns to box 522, where another possible driver's seat coordinates are selected and a seat is found for that coordinate location.

[0183] Conversely, in box 532, if no other driver's seat is found, the process proceeds to box 540, where the indication that the driver's seat is unoccupied is returned. The process then proceeds to box 542 and ends.

[0184] Instead, starting from box 530, if the occupancy sensor for the seat detects that the seat is occupied, the process can proceed from box 530 to box 550, where the process can return that the driver's seat is occupied and provide information about which seat is occupied (in cases where there may be more than one driver's seat). Instead of returning a boolean value, a seat object or "empty" can be returned, where "empty" indicates "false" or "no driver's seat is occupied". The process can then proceed to box 542 and end.

[0185] Figure 5 The embodiments can be expressed using pseudocode as shown in Table 20 below.

[0186]

[0187] Table 20: Pseudocodes used to determine whether the driver is in the driver's seat

[0188] Therefore, Table 20 and Figure 4 An example is provided where the coordinates of which seat is the driver's seat can be specified, and a system check can be performed to determine if such a seat is occupied. This allows for situations where the vehicle is not a standard mode of transport, thus providing a flexible system.

[0189] Are the windows of the passengers in front open?

[0190] From the perspective of the vehicle abstraction layer, the front passenger window can be on the left or right side of the vehicle, depending on whether the vehicle is driven by the right or left hand.

[0191] In this regard, a grid coordinate system can be used to find the correct window and determine whether such a window is open.

[0192] Now for reference Figure 6 It shows an example process for determining whether a passenger window is open. Figure 6 The embodiment begins at box 610 and proceeds to box 620, in which the coordinates of the driver's seat can be found. This can be done, for example, by querying a configuration file for the vehicle and utilizing configurations such as those shown in Table 5 or Table 6 above.

[0193] Based on the coordinates found at box 620, the process proceeds to box 622 and finds the row and column for the driver's seat. Figure 6 In the example, the assumption is made that there is only one driver's seat. However, Figure 6 The process can be easily extended to include multiple driver seats. In this case, the passenger side window can, for example, be based on... Figure 6 The embodiment is to find the opposite side of the active driver to determine this.

[0194] The process proceeds from box 622 to box 624, where the dimensions of the grid for the vehicle or compartment are determined. This is done based on the assumption that the driver and passenger front seats are located at the edges of the grid and can utilize a configuration file for the vehicle specified by, for example, the original equipment manufacturer.

[0195] Based on the grid size and the driver's seat position, passenger seats can be located. For example, in a left-hand drive vehicle, the driver could be positioned at (1,1,1). In this case, the passenger could be positioned at the grid's maximum column width. Utilizing... Figure 2 The embodiments in the table and the dimensions specified in Table 4, for example, have a maximum column of 3, so the passenger seat will be found at (1,3,1).

[0196] Conversely, in a right-hand drive vehicle, the driver might be positioned at (1,3,1). Since the driver is at the maximum column value, it can be assumed that the passenger seat is at the minimum column value, i.e., (1,1,1).

[0197] Based on the determination at box 626, the process proceeds to box 630, where the window is selected in the driver's row and in the column opposite to the driver.

[0198] At box 640, the selected window can be checked to determine if it is open. In some embodiments, the window sensor can indicate how much the window is open, from 0% indicating the window is closed to 100% indicating the window is fully open. In this case, if the percentage is greater than 0%, the determination at box 630 may find the window is open. However, in some other cases, the check may allow for a slightly ajar window, and the check at box 640 can determine whether the window is open more than, for example, 10%. Other options are also possible.

[0199] Starting at box 640, if the window is open, the procedure proceeds to box 642 and returns true. Conversely, if it is determined that the window is closed, the procedure proceeds from box 640 to box 644, where the procedure returns false in case the window is open.

[0200] The process proceeds from boxes 642 and 644 to box 650 and ends there.

[0201] Figure 6 Examples of such implementations can be expressed, for instance, in pseudocode as shown in Table 21 below.

[0202]

[0203] Table 21: Pseudocode used to determine whether a passenger window is open

[0204] In Table 21, this column is determined as either "1" or "maxColumn" ("maximum column") based on the side where the driver is located.

[0205] Windows are classified as window objects. However, in some cases, a window may be a subset of another object (such as a car).

[0206] Figure 6 The pseudocode and examples provide the ability to easily locate the correct passenger side window using coordinates.

[0207] Which HVAC station is serving the left rear seat?

[0208] In another example use case, it is possible to determine which HVAC station is providing service to a specific seat. For example, this can be achieved using the “Association” labels provided in Tables 13 through 18 above.

[0209] Now for reference Figure 7 This illustrates an example of using association to locate HVAC systems associated with seats. Specifically, the process begins at box 710 and proceeds to box 720, where the coordinates of the seat of interest are found.

[0210] The system then proceeds to box 722, where any HVAC systems with the same coordinates are acquired.

[0211] The process then proceeds to box 740, where a check is performed to determine if any HVAC systems were found at box 722. Specifically, refer to... Figure 2 If the coordinates for the seat of interest are (1,1,1), this will indicate the driver's seat and the HVAC system will be returned. Conversely, if the coordinates for the seat of interest are (2,1,1), this is the left rear seat, and no HVAC system with the same coordinates will be found.

[0212] If the check in box 740 finds one or more HVAC systems acquired at box 722, the process proceeds to box 742, where a pointer or data link to one or more HVAC systems is returned. The process then proceeds to box 750 and ends.

[0213] Conversely, if zero HVAC systems are found to be acquired at box 740, the process proceeds from box 740 to box 760, where the seat object for the coordinates is found. For example, if identifier labels are used in the association, this might involve finding the identifier labels for the seats.

[0214] The process then proceeds to box 762, where the association for the seat object is retrieved from the association list stored for the vehicle. At this point, a pointer or data link to the associated HVAC system can be returned, as shown in box 764.

[0215] The process then proceeds to box 750 and ends.

[0216] like Figure 7 As shown, the first association based on co-location can be checked. If no first association exists, a second association based on an explicit association table or list can be found. In each case, the coordinates of the seat of interest are used as the basis for the search.

[0217] For Figure 7 Example pseudocode for the embodiments is provided in Table 22 below.

[0218]

[0219] Table 22: Pseudocode for HVAC stations used to determine the right rear seat of service

[0220] As those skilled in the art will understand, Figure 7 The examples in Table 22 are simplified versions of the code that might be used in practice. Specifically, Figure 7The example relies on one-sided associations and does not handle the possibility that an identifier can be associated with more than one component. Specifically, if an identifier is associated with more than one component, it may be necessary to perform checks to find the component of interest. In some cases, this may depend on the association between the identifier and the component type.

[0221] However, Figure 7 The implementation uses coordinates to locate the data object of interest as the first check co-address. Figure 7 The implementation then uses the enumerated associations to find the associated data objects of interest.

[0222] Use the span to find which HVAC service seat.

[0223] Similar to association, span can be used to define the region where a data object serves. In this regard, in some embodiments, span can be used to find which HVAC unit serves a seat.

[0224] Now for reference Figure 8 .exist Figure 8 In one embodiment, the process begins at box 810 and proceeds to box 820, where the coordinates of the seat of interest are found.

[0225] The process then proceeds to box 822, where any HVAC units with the same coordinates are retrieved. In box 840, a check is performed to determine if an HVAC system with the same coordinates exists.

[0226] If an HVAC system with the same coordinates exists, the process proceeds to box 842, where a pointer or data reference to that HVAC system is returned. The process then proceeds to box 850 and ends.

[0227] Conversely, if zero HVAC systems with the same coordinates are found at block 840, the process proceeds from block 840 to block 860, where the HVAC span is located. The process then proceeds to block 862, where the HVACs for span-based seating coordinates are identified.

[0228] The process then proceeds to box 864, where the pointer or data link to the HVAC system found in box 862 is returned.

[0229] The process proceeds from box 864 to box 850 and then ends.

[0230] For Figure 8 The pseudocode for the example is provided below with reference to Table 23.

[0231]

[0232]

[0233] Table 23: Pseudocode for determining HVAC stations based on span

[0234] therefore, Figure 8 Table 23 provides options for creating associations using spans.

[0235] Locate the second data object associated with the first data object.

[0236] Figures 5 to 8 The implementation examples can be generalized to find relationships between data objects. In particular, reference is now made to... Figure 9 .

[0237] exist Figure 9 In this embodiment, the process begins at box 910. Typically, this occurs when the abstraction layer or program needs to know which data object is associated with a particular data object or a particular location. As mentioned above, this could be "what HVAC system serves this seat," but could include "what audio source serves these speakers" and other options. Such a question can be generalized to "what second data object serves this first data object."

[0238] The process proceeds to box 920, where the coordinates of the first data object are found. As those skilled in the art will understand, if the question posed by the program or abstraction layer is not "the first data object," but rather "what second data object serves that coordinate location," then box 920 may be optional because the coordinates are already known.

[0239] The process then proceeds to box 922, where checks are performed to determine whether the second data object shares an address with the first data object. Specifically, coordinates can provide a first implicit association between the data objects.

[0240] The process then proceeds to box 940, where a check is performed to determine if any second data object has been found. If one or more data objects are found, the second data object can be returned at box 942 based on coaddress. Returning the second data object may involve options such as pointers, data references, etc.

[0241] The process proceeds from box 942 to box 950 and then ends.

[0242] Conversely, if zero second data objects are found to co-address with the first data object at box 940 (or zero second data objects are found at a specific coordinate location), the process proceeds to box 960, where the association for the first data object or location can be found. Such a finding at box 960 can be used in the explicit association defined in the vehicle definition utilizing the mesh structure of this disclosure.

[0243] The process then proceeds to box 964, where the associated second data object can be returned. This can be accomplished using pointers, data references, and other options.

[0244] The process proceeds from box 964 to box 950 and then ends.

[0245] Example transportation system

[0246] This disclosure relates to automotive systems with nodes. However, it is provided for illustrative purposes only, and the methods and systems described herein can be used with any other system.

[0247] For example, now refer to Figure 10 The diagram shows node 1010. As used herein, a node can be one or a group of electronic control units, central processing units or kernel controls, and other options, and can be considered a single computing unit.

[0248] exist Figure 10 In the example, node 1010 includes a service manager 1020 that can interact with drivers for sensors to which the node connects. For example, node 1010 may have access to location sensors, such as a Global Positioning System (GPS) chipset, as shown in box 1022.

[0249] To allow node 1010 to interact with modules on other nodes and to provide functionality to the computing system, a Hardware Abstraction Layer (HAL) can be provided on node 1010, which includes HAL services 1030. Each HAL service 1030 is responsible for sensor integration and can provide various functions, including: integration into the underlying sensors; standardization of sensor data; and / or, if needed, providing a barrier between securely authenticated and unauthenticated software. Other functions for HAL services are also possible.

[0250] exist Figure 10 In the example, HAL is provided for camera information, as shown in box 1032.

[0251] Although Figure 10The example shows node 1010 with a single service and a single HAL, but this is provided for illustrative purposes only. Node 1010 may 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.

[0252] An example of a system that can utilize Node 1010 is an application development environment for vehicles. Such an environment can develop applications for user experience (including comfort, navigation, infotainment, etc.), safety, fleet management, performance monitoring, or other applications specific to the vehicle environment. In particular, vehicles provide multiple sensors, and different manufacturers, models, or brands can use different sensors with different data formats or values, resulting in fragmented sensor readings that depend on these sensors. This fragmentation hinders the development of an ecosystem of applications utilizing vehicle data. Furthermore, low-level sensor data is often too granular to be readily useful for applications.

[0253] In this regard, a hardware abstraction layer can be used to provide hardware-independent sensor interfaces / abstractions that encapsulate interactions with the underlying sensor drivers. Using hardware abstractions across various computing nodes creates a scalable platform that can provide barriers between modules to, for example, enforce the separation of security authentication systems from other systems, among other options.

[0254] Applications do not interact directly with the sensor hardware to access sensor data; instead, they utilize a hardware abstraction layer. This separation provides a clear distinction between the responsibilities of the HAL (sensor integration and normalization of sensor data) and those of other abstractions (such as the Vehicle Abstraction Layer (VAL), which manages access to vehicle data and provides value-added insights).

[0255] Specifically, insights can leverage sensor data from multiple HALs to provide vehicle abstractions and value-added insights. Vehicle insight services in VALs can control access to standardized forms of vehicle data and provide value-added inference. Examples of insight services can include location services, providing coordinate location data in a consistent format along with insights (such as geofencing); seat services, providing a wealth of seat information such as seatbelt status, weight, location, and child lock status; camera services, providing video streams for cabin cameras and potentially offering features (such as transitions and / or clipping); battery services, providing insights and access to the battery such as charging status / consumption / estimated remaining hours / estimated range; door services, providing abstractions for doors and door status; and so on.

[0256] Insight services can leverage sensor data from multiple HALs to provide vehicle abstractions and value-added insights. A higher level of insight into the data enables application developers to create future-oriented automotive experiences. Insight is a term used to describe any value-added interpretation of basic sensor data. Insights can be as straightforward as data aggregation or correlation, or as complex as artificial intelligence and machine learning. For example, for temperature sensors, providing high and low water level indicators for notifications can be considered an "insight." For location services—geofencing is an insight; for cameras—occupant identification can be considered an insight.

[0257] Therefore, such an application development environment needs to be like Figure 10 The node described herein has services and a HAL manager. In many systems, node 1010 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 1010.

[0258] Such a system can use a grid system with vehicles to find data objects and their relationships. In this respect, the vehicle abstraction layer can easily provide information regardless of the specific manufacturer and model of the vehicle for which the information is sought.

[0259] Example computing system

[0260] The network elements, nodes, computing devices, and other computing platforms described above can be implemented using any computing device. A simplified diagram of a computing device is shown below. Figure 11 It is shown. Figure 11 The computing device can be any fixed or mobile computing device.

[0261] exist Figure 11 In this embodiment, device 1110 includes a processor 1120 and a communication subsystem 1130, wherein the processor 1120 and the communication subsystem 1130 cooperate to perform the methods described above. The communication subsystem 1130 allows device 1110 to communicate with other devices or network elements and can vary based on the type of communication being performed. Furthermore, the communication subsystem 1130 can include various communication technologies, including any wired or wireless communication technology.

[0262] Processor 1120 is configured to execute programmable logic, which can be stored on device 1110 along with data, and Figure 11In the example, it is shown as memory 1140. Memory 1140 can be any tangible, non-transitory computer-readable storage medium that stores instruction code that, when executed by processor 1120, causes device 1110 to perform the methods of this disclosure. Computer-readable storage media can be tangible or transient / non-transitory media, such as optical (e.g., CD, DVD, etc.), magnetic (e.g., magnetic tape), flash memory drives, hard disk drives, or other memories known in the art.

[0263] Alternatively, or in addition to memory 1140, device 1110 may access data or programmable logic from an external storage medium, for example, via communication subsystem 1130.

[0264] exist Figure 11 In the example, one or more internal sensors 1170 or external sensors 1172 may be associated with the computing device. However, this is optional and in some cases the computing device 1110 will not be associated with a sensor.

[0265] In one embodiment, communication between the various components of device 1110 can be achieved via internal bus 1160. However, other forms of communication are also possible.

[0266] The embodiments described herein are examples of structures, systems, or methods having elements corresponding to the elements of the technology described herein. This written description enables those skilled in the art to make and use embodiments having alternative elements having the same elements corresponding to the technology described herein. Therefore, the intended scope of the technology described herein includes other structures, systems, or methods that are not different from the technology described herein, and also includes other structures, systems, or methods that are not materially different from the technology described herein.

[0267] Although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring the operations to be performed in the specific order shown or sequentially, or to perform all the illustrated operations to achieve the desired result. In some cases, multitasking and parallel processing may be employed. Furthermore, the separation of the various system components in the above implementation should not be construed as requiring such separation in all implementations. It should be understood that the described program components and systems can generally be integrated into a single software product or packaged into multiple software products.

[0268] Furthermore, technologies, systems, subsystems, and methods described and illustrated as discrete or separate in various implementations can be combined or integrated with other systems, modules, technologies, or methods. Other items shown or discussed as mutually coupled or directly coupled or communicating may be indirectly coupled or communicating through an interface, device, or intermediate component, whether electrically, mechanically, or otherwise. Other examples of changes, substitutions, and alternatives can be determined and made by those skilled in the art.

[0269] While the detailed description above has shown, described, and pointed out the essential novel features of this disclosure applicable to various implementations, it will be understood that various omissions, substitutions, and changes in the form and details of the illustrated system can be made by those skilled in the art. Furthermore, the order of the method steps is not implied by the order in which they appear in the claims.

[0270] When messages are sent to or from electronic devices, such operations may not be instantaneous or directly from a server. They can be delivered synchronously or asynchronously from servers or other computing system infrastructure that support the devices / methods / systems described herein. The foregoing steps may include, in whole or in part, synchronous / asynchronous communication to / from devices / infrastructure. Furthermore, communication from electronic devices can be to one or more endpoints on a network. These endpoints can be served by servers, distributed computing systems, stream processors, etc. Content Delivery Networks (CDNs) can also provide communication with electronic devices. For example, in addition to a typical server response, a server can provide or instruct data for the CDN to await later download by the electronic device, such as subsequent activities of the electronic device. Therefore, data can be sent directly from a server or from other infrastructure (such as distributed infrastructure or CDN) that is part of or separate from the system.

[0271] Typically, storage media can include any or a combination of the following: semiconductor memory devices (such as dynamic or static random access memory (DRAM or SRAM)), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), and flash memory; magnetic disks, such as fixed disks, floppy disks, and removable disks; another magnetic medium, including magnetic tape; optical media, such as optical discs (CDs) or digital video discs (DVDs); or other types of storage devices. Note that the instructions discussed above may be provided on a single computer-readable or machine-readable storage medium, or alternatively, on multiple computer-readable or machine-readable storage media distributed across a large system that may have multiple nodes. Such one or more computer-readable or machine-readable storage media are considered part of an article (or article of manufacture). An article or article of manufacture may refer to any single or multiple manufactured components. One or more storage media may be located in a machine that executes machine-readable instructions, or at a remote site from which machine-readable instructions can be downloaded for execution via a network.

[0272] In the foregoing description, numerous details have been set forth to provide an understanding of the subject matter disclosed herein. However, implementations can be practiced without some of these details. Other implementations may include modifications and variations to the foregoing details. The appended claims are intended to cover such modifications and variations.

Claims

1. A method for finding associations between data objects in a structure at a computing device, the method comprising: Assign a corresponding data object to each of the multiple components of the vehicle, and each corresponding data object has a position in a grid based on the position of the corresponding component in the vehicle, wherein the grid defines the position within the structure; Select coordinate positions from the grid; Determine whether a data object with a data object type is located at the specified coordinates; When the data object is located at the coordinate position, the data object is associated with other data objects at the coordinate position; When no data object is located at the coordinate position, a second data object at the second position is determined by explicit association to serve the coordinate position, and the second data object is associated with the coordinate position. Obtain associated data objects, wherein the associated data objects include at least one of the other data objects associated with the data object or the second data object associated with the coordinate position; Query the associated data object; as well as Receive a response including the status of the associated data object based on sensor readings.

2. The method of claim 1, wherein the selection includes: Select the data objects that interest you; as well as Locate the coordinates of the data object of interest.

3. The method according to claim 1, wherein the mesh structure comprises a three-dimensional mesh, and wherein the coordinate positions are triples.

4. The method of claim 1, wherein the explicit association includes an association between two data objects.

5. The method of claim 4, wherein the explicit association is expressed by associating a third data object being served with a second data object providing the service.

6. The method of claim 4, wherein the explicit association is expressed by associating a data object being provided with a service with at least one data object being provided with the service.

7. The method of claim 1, wherein the explicit association is directed to the second data object and at least one coordinate position to which the second data object provides services.

8. The method of claim 1, wherein the explicit association is based on the span of the grid location served by the second data object.

9. The method of claim 1, wherein the mesh definition is for different granularity levels of mesh size within the structure.

10. A computing device configured to find associations between data objects in a structure, the computing device comprising: processor; as well as The communication subsystem, wherein the computing device is configured as follows: Assign a corresponding data object to each of the multiple components of the vehicle, and each corresponding data object has a position in a grid based on the position of the corresponding component in the vehicle, wherein the grid defines the position within the structure; Select coordinate positions from the grid; Determine whether a data object with a data object type is located at the specified coordinates; When the data object is located at the coordinate position, the data object is associated with other data objects at the coordinate position; When no data object is located at the coordinate position, a second data object at the second position is determined by explicit association to serve the coordinate position, and the second data object is associated with the coordinate position. Obtain associated data objects, wherein the associated data objects include at least one of the other data objects associated with the data object or the second data object associated with the coordinate position; Query the associated data object; as well as Receive a response including the status of the associated data object based on sensor readings.

11. The computing device of claim 10, wherein the computing device is configured to be selected in the following manner: Selecting data objects of interest; and Locate the coordinates of the data object of interest.

12. The computing device of claim 10, wherein the mesh structure comprises a three-dimensional mesh, and wherein the coordinate positions are triples.

13. The computing device of claim 10, wherein the explicit association includes an association between two data objects.

14. The computing device of claim 13, wherein the explicit association is expressed by associating a third data object being served with a second data object being served.

15. The computing device of claim 13, wherein the explicit association is expressed by associating a data object being provided with a service with at least one data object being provided with the service.

16. The computing device of claim 10, wherein the explicit association is directed to the second data object and at least one coordinate location to which the second data object provides services.

17. The computing device of claim 10, wherein the explicit association is based on the span of the grid location served by the second data object.

18. The computing device of claim 10, wherein the mesh definition is for different granularity levels of mesh size within the structure.

19. A non-transitory computer-readable medium for storing instruction code, said instruction code causing the computing device, when executed by a processor configured to find associations between data objects in a structure: Assign a corresponding data object to each of the multiple components of the vehicle, and each corresponding data object has a position in a grid based on the position of the corresponding component in the vehicle, wherein the grid defines the position within the structure; Select coordinate positions from the grid; Determine whether a data object with a data object type is located at the specified coordinates; When the data object is located at the coordinate position, the data object is associated with other data objects at the coordinate position; When no data object is located at the coordinate position, a second data object at the second position is determined by explicit association to serve the coordinate position, and the second data object is associated with the coordinate position. Obtain associated data objects, wherein the associated data objects include at least one of the other data objects associated with the data object or the second data object associated with the coordinate position; Query the associated data object; as well as Receive a response including the status of the associated data object based on sensor readings.

Images