System, method, and apparatus for vehicle external communication control

Abstract

An exemplary system includes a vehicle having at least one network zone, a policy management circuit that interprets a policy including a local DNS, an authorization description, and a firewall configuration description, and a configuration circuit that configures, in response to the policy, a gatekeeper interface circuit interposed between one of the network zones and an external communication portal to coordinate communications between an endpoint in the network zone and the external communication portal.

Description

Technical Field

[0001] [Cross - Reference to Related Applications] This application claims the benefit of priority to the following provisional patent applications: U.S. Patent Application No. 62 / 903,462 (SONA - 0001 - P01) entitled "SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK" filed on September 20, 2019; U.S. Patent Application No. 62 / 911,249 (SONA - 0002 - P01) entitled "SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK" filed on October 5, 2019; U.S. Patent Application No. 62 / 911,248 (SONA - 0003 - P01) entitled "SYSTEM, METHOD AND APPARATUS FOR CLOUD - BASED INTERACTIONS WITH A MIXED VEHICLE NETWORK" filed on October 5, 2019; U.S. Patent Application No. 62 / 986,444 (SONA - 0004 - P01) entitled "SYSTEM, METHOD AND APPARATUS FOR IMPLEMENTING CONFIGURABLE DATA COLLECTION FOR A VEHICLE" filed on March 6, 2020; and U.S. Patent Application No. 63 / 024,383 (SONA - 0005 - P01) entitled "SYSTEM, METHOD AND APPARATUS TO TEST AND VERIFY A VEHICLE NETWORK" filed on May 13, 2020.

[0002] The entire contents of each of the above - mentioned applications are hereby incorporated by reference herein.

Background Art

[0003] Vehicle communication networks are used to connect sensors, actuators, controllers, and communication devices throughout a vehicle. The trend of more devices being connected, more data being passed between devices, shorter latency requirements to meet vehicle performance, safety, and emissions requirements, and additional vehicle functions is increasing the burden on these vehicle communication networks. In addition to this, consumers expect increasing connectivity and functionality, which increases the burden on vehicle communication networks. These trends are expected to continue and accelerate over the foreseeable future.

[0004] Conventional vehicle communication networks (such as CAN, LIN, FlexRay, MOST, LVDS, etc.) have several drawbacks and issues. These vehicle communication networks were developed to meet specific challenges of the vehicle environment and thus were developed separately from other networks such as computer local area networks, wide area networks, large-scale interconnected networks (e.g., the Internet), and wireless networks. Most vehicle networks consist of a data link layer and an application layer and utilize robust and dedicated devices such as a controller area network (CAN) bus with dedicated or shared wiring between devices that utilize specific data protocols (e.g., J1939, OBD, etc.). Modern vehicles may have multiple network buses where specific commands and communications are available with limited customization and data speeds available. For example, a CAN bus typically operates up to about 1 Mbps, and a high-performance CAN bus operates up to about 10 Mbps. In addition to this, a CAN bus experiences latency longer than 25 ms and generally longer from about 60 ms to 500 ms depending on factors such as configuration, traffic on the CAN, and priority for specific messages.

[0005] As the number of devices and the data rate requirements from the devices increase, conventional vehicle communication networks require the implementation of higher-performance buses. Since the automotive industry is a mass-production industry with a very low tolerance for component failures, automotive manufacturers utilize the same components over a long period of time and across a wide range of vehicles, including the sharing of components among manufacturers. In addition, changes to nominally higher-function components may introduce risks, integration costs, re-certification burdens, or other undesirable consequences to the system for a given application. Therefore, even if the vehicle communication network migrates to a higher-function network configuration, it is desirable to keep the network types separated within the system and maintain a large number of legacy devices (e.g., CAN-compatible ones) within the system over a long period of time.

[0006] Data collection from vehicles involves several additional challenges. For example, data collection operations are subject to regulations and liability risks, especially in the case of data collection that may include personal information, personally identifiable information, and / or debt-related information. Data collectors, including entities that may have ownership or possession rights to confidential data, are at risk during the time the data is held, for example, in the event of inadvertent or malicious access to the data. With respect to the vehicle data being collected, large amounts of data may be collected and there may be multiple purposes for collecting the data, increasing the risk compared to other common data storage applications. Therefore, it may be desirable to control data collection, storage, and access to reduce risks, and it may be further desirable to include verification of data access and partitioning or other elimination of data when the data is not being used.

[0007] Data collection related to vehicles becomes even more complex depending on the amount and type of data to be communicated between the vehicle and external devices, and the vehicle's network system is restricted by constraints such as mobile applications, costs, and / or bandwidth limitations suffered by high data speeds and / or high data transfers. Despite this, the increasing requirements regarding customer demands, market forecasts, vehicle operation efficiency, and the functional capabilities of data-related applications have been continuously driving up the total amount of data to be transferred, the number of external vehicle applications that utilize the transferred data, the number of purposes for which the data can be used, and the number of users or entities that have a legitimate need for each part of the transferred data. In addition to this, the applications that utilize data also continue to increase in sophistication and capabilities, raising the data requirements for the limited available transfer resources and increasing the costs and complexities of the logistic control and storage of the transferred data. For example, all of the more highly functional route designation or operation algorithms related to vehicles, the increasing automation of vehicle functions, the increasing requirements for predictive decision-making and / or maintenance support, and the increasing media streams (both the number of media streams and their quality) are driving up the increasing requirements for data speed, the amount of stored data, and the number of entities or applications accessing the stored data. SUMMARY OF THE INVENTION

[0008] The description in this specification refers to vehicle applications as non-limiting examples and for purposes of clarity of this description. However, the embodiments of this specification are applicable to other applications having similar problems and / or implementations. Without being limited to any other application, the embodiments of this specification have a plurality of end points including a plurality of data sources, controllers, sensors, and / or actuators, and may further include end points existing in clearly different network and / or distributed network environments, and / or are in the process of migrating to a network connection system or communication system having newer and / or higher functions (within a given system, as a part of the system, and / or as an industry) and are applicable to applications having a historical or legacy network connection system or communication system. Exemplary and non-limiting embodiments include one or more of industrial equipment, robot systems (including at least mobile robots, autonomous vehicle systems, and / or industrial robots), mobile applications (which may or may not be considered "vehicles"), and / or manufacturing systems. Certain features, aspects, and / or advantages of the disclosure of the present invention are applicable to any one or more of these applications, not applicable to some of the other ones of these applications, and it will be understood that the applicability of certain features, aspects, and / or advantages of the disclosure of the present invention may vary depending on the operating conditions, constraints, cost parameters (e.g., operating cost, integration cost, operation cost, data communication cost and / or storage cost, service cost, and / or downtime cost, etc.) of a particular application. Therefore, as will be understood by those skilled in the art having the benefit of the disclosure of the present invention, the disclosure of the present invention, when referring to vehicles, vehicle systems, mobile applications, industrial equipment, robot systems, and / or manufacturing systems, necessarily contemplates each of these, and may be applicable in certain embodiments or not applicable in certain other embodiments.

[0009] The disclosure of this specification, as reflected in the embodiments to be described, recognizes that the complexities and other issues listed above have a synergistic effect that makes the complexity of the vehicle data environment greater than the sum of the individual contributions from each issue.

[0010] As an example, an increase in the number of entities or applications accessing data increases the likelihood that individual data requests will repeat, for example, when multiple entities request the same or similar data. Further, an increase in the number of entities or applications accessing data increases the likelihood that the members of these access groups will share similar authorization levels so that data access by individual members of the entity group or application group will benefit from data management.

[0011] In another example, regulations regarding confidential data have been strengthening, which not only generally increases the data management requirements of the system, but also increases the likelihood that data management will be subject to multiple constraints at a given point in time and / or constraints that change over time when regulations change, and / or constraints that change based on the applicable jurisdiction that may change when the location of the vehicle changes.

[0012] In yet another example, a vehicle having a complex environment of currently known and evolving vehicle network architectures, such as a hybrid network type and / or a split network, increases the complexity of data access for individual entities, which, without using certain aspects of the present disclosure, may otherwise require determining request parameter specifications for specific data elements and updating these request parameters as the vehicle network architecture evolves. In view of the increasing number of entities requesting data access, the total cost to the automotive support market increases non-linearly as each of the entities incurs the cost of tracking request parameter specifications. In addition to this, the locus of additional entities requesting data access is moving towards entities located far from core automotive functions within the technological knowledge space, and thus the intricacy and idiosyncrasy of vehicle applications and / or automotive applications, including vehicle network configurations, specific data descriptions, data request protocols and communication protocols, and industry norms or conventions regarding providing information, is becoming increasingly unfamiliar to each new incremental entity, further increasing the cost volume function (e.g., the cost over time for a given entity, such as an automotive manufacturer and / or the vehicle market, a geographical market, and / or the automotive industry, the passenger vehicle industry, etc., to reach a desired data collection outcome). For example, consider the following: COST = number of entities * Basic learning cost * Migration adaptation cost locus * Data locus cost * Regulatory adaptation cost * Data access / storage obligation cost Consider nominal cost volume functions such as the following:

[0013] The COST function described is a non-limiting nominal example to illustrate how various issues and drawbacks regarding currently known systems interact to produce a synergistic effect that increases the cost to reach a future data collection function for vehicle applications. The cost parameters to be described are not intended to cover all costs related to the automotive data collection industry or the issues existing with currently known systems. The parameters can be an average or other complex functions, and the values of specific parameters generally will not be known by specificity. In addition to this, the unit of COST can be represented as a monetary value as resources (e.g., man-hours, computing time, etc.) to reach a data collection target over time, or as another non-monetary unit such as a carbon dioxide equivalent value, customer satisfaction, risk incurred, loss or gain of public recognition. The number of entities parameter generally reflects the number of entities accessing vehicle data over time, the basic learning cost reflects the cost for a new entity to learn the details of data collection requirements and protocols regarding a specific vehicle, vehicle type, market, etc., the migration adaptation cost trajectory reflects the cost to adapt to changing vehicle network configurations including the type and composition of the network, and the interaction with endpoints or devices on these networks, the data trajectory cost reflects the increasing requirements for data collection over time from corresponding vehicles including data communication, storage, and derived functional consequences such as the inability to support an application or cost desirable to improve the data communication infrastructure, the regulatory adaptation cost reflects the cost associated with the increasing number of regulations, increasing number of regulatory frameworks, and / or increasing number of regulatory authorities, and the data access / storage liability cost reflects the cost incurred regarding data compliance and security, and / or the losses incurred due to data breaches, unauthorized use, and premature invalidation of data.

[0014] Without being limited to any other aspect of the disclosure of the present invention, aspects of the disclosure herein reduce and / or eliminate any one or more of the costs per entity added to the data collection system, the basic learning costs for implementing applications in which new entities utilize the collected data, the adaptation costs to changing vehicle network configurations, the costs incurred to meet increasing requirements for data collection, the costs for adapting to changing regulatory environments, and / or the costs for protecting data and / or losses incurred due to infringement or unauthorized use. Certain embodiments and / or aspects of the disclosure herein can satisfy one or more of the described cost parameters. Certain embodiments and / or aspects of the disclosure herein can increase one or more given cost parameters, but nevertheless are beneficial by reducing the overall cost function with respect to the target vehicle, vehicle type, entity, industry, etc. Certain embodiments and / or aspects of the disclosure herein can increase one or more given cost parameters, but provide other benefits such as functional improvements. In certain embodiments, the functional improvements can be achieved at a lower cost than previously known systems configured to achieve similar functional improvements, although at a high cost.

[0015] Without being limited to any other aspect of the disclosure of the present invention, embodiments herein define configurations for inter-network, intra-network, and off-vehicle communication control using off-vehicle devices such as cloud applications, web-based tools or applications, manufacturing tools, OEM tools, or service tools. Embodiments herein define the execution of active diagnosis, active testing, vehicle control actions, and / or active assistance actions including aspects and / or operations involving both on-vehicle and off-vehicle devices and / or flows, applications, service groups, and / or vehicle functions. Embodiments herein include communications that move between endpoints, between networks, and / or to external devices, and further include communications involving related endpoints associated according to related flows, vehicle functions, applications, service groups, source addresses and / or destination addresses, and / or source ports and / or destination ports, defining convenient monitoring, diagnosis, and configuration of inter-network, intra-network, and off-vehicle communications. Embodiments herein define an aggregation (physical and / or logical) of off-vehicle communication control, regulation, data management, security enforcement, authorization enforcement, permission enforcement, service enforcement, and / or periodic reception enforcement. Embodiments herein define a planned implementation of policies including stages of updating policies, adjusting policies, and / or inspecting approvals for changes to policies. Embodiments herein define a planned implementation of communication service levels and / or QoS implementation for communications related to endpoints, flows, applications, vehicle functions, vehicle controllers, service groups, and / or external communication portals. Embodiments herein define a planned implementation of data utilization including the use of specific external communication portals, APNs, and / or data service providers. Embodiments herein define an adjustment of external communication portals with respect to off-vehicle communication to reduce the cost of specific external communication portals, improve service levels, and / or limit and / or reduce their data utilization, improve the overall function of off-vehicle communication to support vehicle tasks, and / or make such adjustments highly transparent to communication devices (e.g., local communication devices, and / or external devices, applications, and / or tools).

[0016] To facilitate understanding of the principles of the disclosure of the present invention, reference is now made to the embodiments illustrated in the drawings and described in the following specification. It is understood that this reference is not intended to limit the scope of the disclosure of the present invention. It is further understood that the disclosure of the present invention includes any variations and modifications to the illustrated embodiments, and that the disclosure of the present invention includes further alternative uses of the principles disclosed herein that would be generally contemplated by a person of ordinary skill in the relevant art.

Brief Description of the Drawings

[0017]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

Figure 8

Figure 9

Figure 10

Figure 11

Figure 12

Figure 13

Figure 14

Figure 15

Figure 16

Figure 17

Figure 18

Figure 19

Figure 20

Figure 21

Figure 22

Figure 23

Figure 24

Figure 25

Figure 26

Figure 27

Figure 28

Figure 29

Figure 30

Figure 31

Figure 32

Figure 33

Figure 34

Figure 35

Figure 36

Figure 37

Figure 38

Figure 39

Figure 40

Figure 41

Figure 42

Figure 43

Figure 44

Figure 45

Figure 46

Figure 47

Figure 48

Figure 49

Figure 50

Figure 51

Figure 52

Figure 53

Figure 54

Figure 55

Figure 56

Figure 57

Figure 58

Figure 59

Figure 60

Figure 61

Figure 62

Figure 63

Figure 64

Figure 65

Figure 66

Figure 67

Figure 68

Figure 69

Figure 70

Figure 71

Figure 72

Figure 73

Figure 74

Figure 75

Figure 76

Figure 77

Figure 78

Figure 79

Figure 80

Figure 81

Figure 82

Figure 83

Figure 84

Mode for Carrying Out the Invention

[0018] Referring to FIG. 1, an exemplary system schematically illustrates aspects of an embodiment of the disclosure of the present invention. The exemplary system includes an application 102 (e.g., a vehicle) having a first network 104 and a second network 106. The networks utilized herein must be understood in a broad sense and include one or more aspects such as hardware implementation (e.g., wire and wiring configuration, applicable standards, e.g., connectors, insulation, shielding, wire requirements, e.g., standard dimensions, stranded braiding, coaxial braiding, etc.), implementation of any layer (e.g., from the ISO 7-layer model, e.g., application layer, presentation layer, session layer, transport layer, network layer, data link layer, and / or physical layer, although a given network can have fewer layers and / or layers organized in a clearly different manner), and / or can be wired or wireless in whole or in part. Without being limited to any aspect of the disclosure of the present invention, exemplary and non-limiting networks include a Controller Area Network (CAN), a Media Oriented System Transport (MOST) network, a Local Interconnect Network (LIN), a FlexRay network, a Time-Triggered Protocol (TTP) network, a Low-Voltage Differential Signal Transfer (LVDS) network, and / or an Ethernet implementation network. In certain embodiments, one or more networks can be an electrical signal zone such as a sensor or actuator electrically coupled to an interpretation device (e.g., a device that provides data and / or receives commands as electrical signals such as voltage values, frequency values, and display resistance values, etc.), and the interpretation device has the function of receiving information from and / or passing information or commands to one or more electrical devices on the electrical signal zone.

[0019] The exemplary system includes a first network 104 that is of a different type than a second network 106. As used herein, two networks having different types must be understood broadly and include different protocols, at least one layer that is clearly different from each other (e.g., having a clearly different application layer, presentation layer, etc.), two networks that are not operationally compatible (e.g., a device coupled to one of these networks will not function on the second network without changes to connections, communications, or other aspects), and / or two networks that are not message compatible (e.g., messages configured for the first of the networks cannot be directly overlaid on the second of the networks due to differences such as addressing, frame structure, logical compatibility of messages). The exemplary system includes a first network 104 that is an Ethernet-implemented network and a second network 106 of a different type such as a CAN network and / or a LIN network.

[0020] The exemplary system further includes a converged network device (CND) 108 structured to be inserted between a first network 104 and a second network 106 to facilitate communication between the first network 104 and the second network 106. The CND 108 inserted between networks 104, 106 transfers communication between networks 104, 106, for example, receives communication from the first network 104 and converts the communication for the second network 106 (e.g., encapsulating all or a portion of the communication in a message for the second network 106, and / or transforming aspects of the communication such as device address, bit depth for the data, and / or unit value for the data, and / or adding or removing aspects of the communication such as priority information, message delivery requests or requirements, e.g., industry standard information such as message identifiers). In certain embodiments, the CND 108 can control other devices (e.g., switches, routers, gateways, or repeaters, etc.) that do not physically transfer communication or transfer only a portion of the communication, but instead perform operations such as adjusting, managing, granting permissions, suppressing messages, or transferring communication between networks. Thus, the CND 108 inserted between networks 104, 106 can, in certain embodiments, be physically located between networks 104, 106, and communication entering and leaving between networks 104, 106 is physically received by components of the CND 108. In certain embodiments, the CND 108 inserted between networks 104, 106 can have visibility into the communication on networks 104, 106 and a control device for regulating the transfer of messages between these networks. In certain embodiments, the CND 108 inserted between networks 104, 106 can have visibility into endpoints on networks 104, 106 and a control device for regulating the transfer of messages between endpoints of each network 104, 106.

[0021] Those skilled in the art having the benefit of the disclosure of the present invention and having information normally available when considering a particular system can easily place CND108 in accordance with one of the above-described intervention schemes and / or a combination of more than one of these intervention schemes.Certain considerations when designing an intervention scheme for CND108 for a given system include the number and type of networks on the vehicle, the function of each individual network (e.g., throughput, bandwidth, address availability, broadcast / unicast / multicast availability and desirability, confirmation response requirements and / or availability for each network and / or endpoint, and / or encryption requirements and / or availability for each network and / or endpoint), the availability, location, and / or control on the network implementing multiple controllers (e.g., the presence and ownership of switching devices, access to instructions such as firmware or buffers for available devices, and / or the connectivity of available devices to one or two or more networks, e.g., whether devices are arranged to implement desirable messages, desirable redundancy, and / or desirable failure mode responses for messages entering and leaving the network), the function of the network implementing multiple controllers (e.g., buffer sizing and availability, message speed capacity, processing capacity), hardware cost considerations for adding CND-specific components to the system, hardware cost considerations for providing functions for CND operation within other components of the system, integration cost considerations and system functions for implementing additional CND-specific components and / or adding functions for CND operation within other components of the system, the number, type, and / or message throughput of endpoints using inter-network communication, expected changes in any one or more of these aspects over the life of the vehicle (e.g., due to campaign events such as vehicle inspection, upgrade, and / or product recall events), and / or expected changes in any one or more of these aspects over the life cycle of a related group of vehicles (e.g., related vehicle fleets, vehicle model years, and / or groups of model years related to the system, e.g., multiple vehicles having a similar network infrastructure but having changes in device distribution, changes to the network, etc.).

[0022] In the example described in FIG. 1, the first external device 110 is shown as communicatively coupled to the application 102. The first external device 110 can be directly coupled to the application 102, and this coupling can include a directional wired connection (e.g., to a service port, an OBD port, or other available connections), and / or a wireless connection (e.g., a WiFi connection and / or a Bluetooth connection such as an IEEE801.11 compliant connection). The first external device 110 can be connected to a specific network (the first network 104 or the second network 106), and / or can be connected to another device (e.g., the CND 108 and / or a device adjusted thereby) that directly manages communication with the external device 110. Regardless of whether the external device 110 is coupled to any of the other devices such as the networks 104, 106 or the CND 108, in certain embodiments, the CND 108 manages communication such that the external device 110 only receives authorized communication, and further manages communication such that the external device 110 can request communication to an endpoint on any of the networks 104, 106 and receive the requested information despite such management. In certain embodiments, the first external device 110 can be a service tool, an original equipment manufacturer (OEM) tool, a manufacturer tool, a body manufacturer tool, and / or an application (e.g., an application that communicates through a computer device such as a laptop, a desktop, a mobile device, and / or a mobile phone, e.g., an application operated by an owner, an inspection and repair person, a fleet manager, or a similar person).

[0023] In the example shown in FIG. 1, a second external device 114 is shown that communicates with application 102 and / or a first external device 110 through cloud connection 112. Cloud connection 112 can be any type of connection including a mobile connection (e.g., a modem that connects using cellular data service or another data service on application 102), an Internet connection, a wide area network (WAN), and / or combinations thereof. Cloud connection 112 can form part of CND 108 and / or be accessible to application 102 through a transceiver that can be at least partially regulated by CND 108. In certain embodiments, application 102 can have more than one transceiver, in which case one or two or more or all of the transceivers are at least partially regulated by CND 108. In certain embodiments, CND 108 may regulate certain vehicle communications (e.g., from certain networks, endpoints, devices, data types, flows, and / or applications on the vehicle), but may not regulate other communications.

[0024] The endpoints used in this specification must be understood in a broad sense. An endpoint is an organized concept for accessing the vehicle networks 104, 106 and can include a specific device (e.g., an engine controller, a transmission controller, a door controller, an infotainment system, etc.), a group of devices having a single network access (e.g., multiple devices communicate with each other through a single network access point, in which case the networks 104, 106 and / or the CND 108 can have visibility to the individual devices or only have visibility to the communication from the endpoint as a group). For example, a door controller (not shown) can be an endpoint for one of the networks 104, 106, and communication regarding lower-level devices (e.g., a door position sensor, a door lock actuator and position sensor, a window actuator and position sensor, etc.) proceeds to the networks 104, 106 through the door controller endpoint. In this case, the CND 108 can have visibility to the lower-level devices (e.g., a message indicating the door position including an identifier that the door position sensor is about to send a message) or only have visibility to the door controller endpoint (e.g., it is known that a message indicating the door position is provided by the door controller, but the CND 108 does not know which lower-level device might have sent the message). A person skilled in the art having the benefit of the disclosure of the present invention and having information normally available to the contemplated system can easily determine which devices in the system are endpoints for each of the networks 104, 106.Certain considerations for determining endpoint placement include the availability of hardware ports on the network, the distribution of vehicle controllers, the messages passed between vehicle controllers, the adjustment options made available for a given endpoint (e.g., message speed, priority, data collection, message composition, ID information of components, address management with external devices between networks, etc.), the desired granularity of data control (e.g., permissions for a specific device to provide or request information, permissions for an application either inside or outside the vehicle to provide or request information, security authorizations and types, e.g., per user, per entity, per device, per application, per flow, etc.), and / or the redundancy options made available for a given system (e.g., redundancy of network communication functions, redundancy of control operations and associated devices, and / or redundancy of CND operations when CND components are distributed in more than one location of the vehicle), but are not limited to these.

[0025] The applications used in this specification must be understood in a broad sense. Exemplary applications include groups of related vehicle functions or operations, such as speed control (e.g., of the vehicle or its sub-components, such as the engine or drive train), anti-lock braking system (ABS) operation, advanced driver assistance system (ADAS), performance control (e.g., resulting in torque requests, speed requests, or other performance requests from the driver), or other vehicle functions. Exemplary applications include applications for supporting positioning and / or navigation, requesting and / or processing inspection and repair information regarding the vehicle, and / or groups of related functions outside the vehicle, such as third-party applications that interact with the driver (e.g., to find the nearest hotel, selected events, etc.). The applications can be implemented by vehicle manufacturers, suppliers, contract manufacturers, body manufacturers, third parties, drivers, inspection and repair personnel, or similar parties. The applications used in this specification provide an organized concept that can be used to associate certain data, certain endpoints, and / or related functions of the vehicle. In certain embodiments, CND108 can utilize an application to identify data sources, data destinations, permissions available to the application, or priority information regarding the application, and to perform certain data regulating operations described herein.

[0026] The flows used in this specification must be understood in a broad sense. Exemplary flows include related data groups (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related function groups (e.g., additional functions such as service operation and / or data collection, aggregation between related vehicles, and / or combinations of these for a particular system, especially within vehicle functions), related device groups (e.g., door actuators), and / or related application groups. The flows used in this specification provide an organized concept that can be used to associate certain data, certain endpoints, certain applications, and / or related functions of a vehicle or otherwise. In certain embodiments, CND108 can identify a data source, a data destination, permissions available for the flow, or priority information regarding the flow, and use the flow to perform certain data adjustment operations described herein. In certain embodiments, the use of the flow enables CND108 to perform separate operations in which the same endpoint can be involved in supporting desired network management. For example, a vehicle speed management application can have a high priority, and the speedometer endpoint may be associated with the vehicle speed management application. In this example, when the vehicle speed is communicated to support the vehicle speed management application, CND108 assigns a high priority to the vehicle speed message. However, when the vehicle speed is communicated to support a travel planning flow (e.g., there is a travel planning flow but it does not have a high priority), CND108 can assign a lower priority to the vehicle speed message. In yet another example, a vehicle controller, a failure of a part of the network, or other off-nominal conditions may result in a transfer of the vehicle speed management application to another controller within the system, whereby the vehicle speed message is communicated to support the vehicle speed management application (e.g., if the backup controller is on a different network), and CND108 can assign a high priority to the vehicle speed message.The flow and application of organizing the system components enable CND108 to adjust the same or similar information in a discriminatory manner to support various functions, providing improved performance and security for network adjustment operations (e.g., reducing unnecessary inter-network traffic, providing only necessary information, and / or adjusting communication using external devices), and supporting additional functions such as redundancy support, distributed control, and fine-grained inter-network message communication compared to systems known heretofore.

[0027] The service groups used in this specification should be understood in a broad sense. Exemplary service groups include related application groups for vehicles. The related application groups (e.g., one or more vehicle systems, functions, or other applications of the vehicle) can all be placed on the vehicle and / or on external devices (e.g., supporting processing, data collection or storage, and the service group using external source data), and can include aspects such as being web applications, web tools, cloud applications, or service applications. In certain embodiments, any group of local communication devices can be logically associated as a service group. The use of service groups to organize the system components and / or applications enables CND108 to adjust the same or similar information in a discriminatory manner to support various functions, providing improved performance and security for network adjustment operations (e.g., reducing unnecessary inter-network traffic, providing only necessary information, and / or adjusting communication with external devices), and supporting additional functions such as redundancy support, distributed control, and fine-grained inter-network message communication compared to systems known heretofore.

[0028] Adjusted components as used herein and not limited to any other aspect of the disclosure of the present invention include any system components adjusted with respect to communication including data collection, periodic reception, data requests, access to external devices and / or addresses, access to network zones, access to endpoints, utilization of communication resources (e.g., network zone bandwidth, external communication portals, total data limits or amounts, etc.). Adjusted components include, but are not limited to, endpoints, flows, applications, controllers, service groups, interface circuits, network zones, external communication portals, external devices, source addresses, destination addresses, vehicle functions, entities associated with any of these, users associated with any of these, and / or one or more of user roles associated with any of these.

[0029] Exemplary operations for adjusting communication between endpoints of a network zone and / or for adjusting communication with an external communication portal and / or an external device include, but are not limited to, operations as described below. Operations for adjustment can be performed on an endpoint, on a related group of endpoints, and / or on a network zone. Related groups of endpoints can be associated according to flows, applications, service groups, controllers, vehicle functions, source addresses for communication, and / or destination addresses for communication. In certain embodiments, applications, service groups, and / or flows can be provided with identifiers as an implementation for associating related components such as endpoints. Operations for adjustment can be performed by, but are not limited to, a CND, a network gateway, a network interface circuit, and / or a gateway interface circuit. The adjustment operations are described in the context of certain exemplary adjustment devices throughout the disclosure of the present invention, but embodiments can be configured to have other devices perform the adjustment. Exemplary communication and / or adjustment operations include: ·Providing communication (bidirectional) between a first endpoint and a second endpoint, including configuring communication (e.g., protocol, message information, metadata, parameter units, etc.) for a receiving network zone and / or an endpoint device. ·Encapsulating a message from a first network zone and providing the encapsulated message to a second network zone. ·Determining whether a requesting device (and / or related flow) on one of the network zones has permission to request communication to a device on the other of the network zones, and providing communication in response to the permission determination. ·Adjusting at least one of the data speed, request resolution, and / or request response time of communication between devices in these network zones based on a permission determination for the requesting device, the communication performance of the requesting device and / or the provider device, and / or network performance parameters of one or both of the network zones (e.g., current available bandwidth, absolute or current network capabilities, network utilization, etc.), and / or a priority value related to the communication associated with the requesting device (and / or related flow). ·Performing an upsampling operation and / or a downsampling operation on data communicated between network zones. ·Mirroring communication from a first endpoint to a port in a second network zone, including encapsulating, configuring, processing, and / or upsampling or downsampling the mirrored communication. ·Providing communication from a first endpoint to a device coupled to a second network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device, and / or the step of providing communication includes encapsulating, configuring, processing, and / or upsampling or downsampling the provided communication, and / or the provided communication can be unicast, multicast, and / or provided as a periodic receive service. ·Providing the communication from the second endpoint device to a device coupled to either the first network zone or the second network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device, and / or the step of providing the communication includes the steps of encapsulating, configuring, processing, and / or upsampling or downsampling the provided communication, and / or the provided communication can be unicast, multicast, and / or provided as a periodic reception service, ·The second network zone 1904 Providing the communication from a device coupled to the second network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device, to the first endpoint, and / or the step of providing the communication includes the steps of encapsulating, configuring, processing, and / or upsampling or downsampling the provided communication, and / or the provided communication can be unicast, multicast, and / or provided as a periodic reception service, ○For example, further providing, as a command value, the communication for performing an operation related to the task of a mobile application in which the first endpoint responds to the command value (for example, the step of setting a set value, a target value, or a threshold value that responds to the command value), ·Providing the communication from a device coupled to the second network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device, to the first endpoint, and / or the step of providing the communication includes the steps of encapsulating, configuring, processing, and / or upsampling or downsampling the provided communication, and / or the provided communication can be unicast, multicast, and / or provided as a periodic reception service, ○For example, further providing, as a test execution value, the communication for performing an operation related to the active text execution operation of a mobile application in which the first endpoint responds to the command value (for example, the step of performing a certain operation or an active diagnostic operation for an inspection and repair test), ·Providing, from a first endpoint, to a plurality of second endpoint devices, a communication that is configured to satisfy a super-set of requirements (e.g., data rate, resolution, units, etc.) of the second endpoint devices and that can be unicast, multicast, and / or provided as a periodic receive service for the provided communication. ·Parsing communication values from a first device (e.g., a first endpoint, a second endpoint, and / or a device coupled to a network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device), determining a target device (e.g., a communication destination and / or a communication provider that responds to the communication value) that responds to the parsed communication values, and configuring the communication of the target communication destination and / or the communication provider in response to the parsed communication values. For example, the communication values can include general and / or standard component identifiers (e.g., turbine temperature, front passenger door actuator, etc.), and the CND can determine respective endpoints corresponding to the component identifiers according to the current configuration of the mobile application, and further determine routing, encapsulation, and processing of the communication for performing conversion between the first device and the target device. For example, such an operation enables a device, a technician, or other requester to change the configuration and placement of devices on the network zone without the need to track the specific configuration and placement of the devices. ○In addition to or instead of this, such an operation can include storing configuration information that the CND responds to configuration changes (e.g., replacement or movement of a device from one network zone to another, changes to communication parameters or communication functions of a device, etc.), and / or performing runtime determination to establish the location, ID, configuration, communication parameters, and / or communication functions of a device that can be used during runtime operation, stored for later use, and / or stored as a default configuration for receiving further updates. · For example, when multiple devices are aggregated with respect to a single endpoint, but other endpoints or devices communicating with the network zone (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) can be treated as separate devices, the step of performing any one or more than one of the above-described operations with respect to a group or subgroup of devices. For example, when the first configuration has two (or three or more) devices using separate endpoints and the second configuration has two (or three or more) devices (and / or two devices aggregated into a single device) using a single endpoint, such an operation enables multiple configurations, updates, and / or upgrades of the mobile application. Exemplary and non-limiting embodiments include the aggregation of multiple sensors (e.g., smart sensors having network communication functions, multiplexed signals, etc.) communicating with the network zone through a single interface, and / or the step of exchanging the interfaces of multiple components behind a single network interface (e.g., a single communication device such as an edge gateway or a configurable edge gateway that interfaces as a single endpoint to a single network zone and manages communication for related devices). In yet another example, such an operation enables the device to communicate across multiple network zones regardless of configuration changes, supports upgrades and updates regarding the device's association with endpoints, and supports backward compatibility (e.g., subsequent configurations and subsequent distributed control between devices in cases where the CND operation enables a prior system with a clearly different configuration to support the latest configuration and / or distributed control between devices). In addition to or instead of this, such operations may include the step of the CND storing configuration information that responds to configuration changes (e.g., the involvement of a single endpoint between more than one device and a network zone, device aggregation, etc.), and / or the step of utilizing during runtime operation, storing for later use, and / or storing as a default configuration that may receive further updates, the location, ID, configuration, communication parameters, and / or communication functions of the device, and / or the step of performing runtime determination to establish the aggregation status of the device. · For example, when devices are distributed among more than one endpoint but other endpoints or devices communicating with the network zone (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) can process these devices as a single device, the step of performing any one or more of the above operations for a group or subgroup of devices. For example, when the first configuration includes devices using a single endpoint and the second configuration includes devices (or a portion thereof) utilizing more than one endpoint (and / or in the second configuration, devices that were previously aggregated and now constitute two or more separate devices), such operations enable multiple configurations, updates, and / or upgrades of the mobile application. Exemplary and non-limiting embodiments include the step of separating a group of sensors (e.g., smart sensors having network communication functions, multiplexed signals, etc.) that communicate with the network zone through a single endpoint into one or more sensors (and / or subgroups of multiple sensors) each having a separate endpoint. In yet another example, such operations enable the device to communicate across multiple network zones regardless of configuration changes, support upgrades and updates regarding the device's association with endpoints, and support backward compatibility (e.g., the later configuration and distributed device control between devices when the operation of the CND enables a prior system with a clearly different configuration to support the later configuration). ○In addition to or instead of this, such an operation may include the CND storing configuration information in response to a configuration change (e.g., the step of splitting a plurality of devices behind a single endpoint on a single network zone into more than one endpoint, and / or the step of splitting across more than one network zone), and / or the location, ID, configuration, communication parameters, and / or communication functions of a device that can be utilized during runtime operation, stored for later utilization, and / or stored as a default configuration to receive further updates, and / or the step of performing runtime determination to establish the aggregated status of the device. ·Implementation of a service designation architecture where the CND determines available services (e.g., data parameters available for communication, command values available for execution, and / or their configurations, such as speed information, units, resolution, accuracy, precision, availability description, dependent data, and / or operating conditions), publishes the available services, and / or determines periodic receiving clients (e.g., devices, flows, and / or endpoints) for the available services. ○In addition to or instead of this, such an operation may include the step where the CND determines permissions and / or authorizations for publishing available services, viewing available services (and / or a portion of the available services), and / or periodically receiving available services. ○In addition to or instead of this, such an operation may include the step where the CND determines periodic receiving entities as endpoints, devices, flows, and / or external devices, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices. ○In addition to or instead of this, such an operation may include the step where the CND determines the priority of service - specified communication that can depend on the device, endpoint, or associated flow to be published and / or the device, endpoint, or associated flow to be periodically received. ○In addition to or instead of this, such operations include the step in which the CND adjusts the service - specified architecture operation in response to operating conditions (such as mobile application operating conditions, network status of one or more affected network zones, communication status of one or more external devices, etc.). ○In addition to or instead of this, such operations include the step in which the CND accesses stored information indicating available services, public parameters (permissions, priorities, relevant operating conditions, etc.), and / or periodically received entity information. ○In addition to or instead of this, such operations include the step in which the CND updates stored information in response to one or more of runtime updates such as policy descriptions, service configuration descriptions (but not limited to), executed during operations such as starting or stopping a mobile application, and runtime updates from endpoints, devices, and / or flows. ○In addition to or instead of this, such operations include the step in which the CND implements the service - specified architecture based on runtime operations, with or without using the step of storing information and / or updating stored information, and / or ○In addition to or instead of this, steps enabling updates to stored information, runtime updates to stored information, and / or runtime operations implementing the service - specified architecture in response to priorities and / or permissions regarding devices, endpoints, and / or flows that require updates and / or runtime implementation. ·In addition to or instead of this, the operation of the exemplary CND includes adjusting one or more of the operations described above in response to the operating conditions of the mobile application (for example, high-power operation, high-transient operation, stop operation, start operation, selective operation mode, for example, communication operation during certain operations such as professional operation, power take-off (PTO) operation, charging operation, driving control operation, autonomous vehicle operation), and the adjustment for communication can be qualitative (for example, allowing or prohibiting a certain communication type, a certain communication priority threshold, etc. during certain operating conditions, and / or capturing a certain data value during certain operating conditions as a data capture event), quantitative (for example, controlling communication speed, network zone utilization rate, external device communication speed, etc.), or a combination thereof (for example, controlling communication speed for a certain communication type, etc.), and includes raising or lowering the communication function according to the operating conditions and / or communication type (for example, allowing the communication function of the device to decrease during the stop operation, but increasing the communication function of the external device during the stop operation, increasing the communication function of the device for a certain device or flow during the start operation, but reducing the communication function of the device for other devices or flows). ·In addition to or instead of this, the operation of the exemplary CND may be based on the degradation of the network zone (e.g., loss of yield, loss of communication with one or more endpoints of the network zone, injection of noise onto the network zone or the presence of noise on the network zone, physical failure of at least a portion of the network zone, etc.), the failure conditions of one or more devices (e.g., when the CND adjusts the data source for the failed device, when the CND adjusts the data rate for the failed device, when the CND implements a backup data source for the failed device, when the CND reroutes data to a backup data destination for the data provided to the failed device, when the CND implements an event-driven data collection scheme when the failure of the device is an event, etc.), the loss of control function of the vehicle controller (e.g., when the loss of control function indicates that the vehicle controller lacks the data values to perform its task, when the loss of control function indicates that the vehicle controller has lost communication with the network zone to which it is connected, and / or when the loss of control function is an indication by the vehicle controller or another controller in the system that the vehicle controller cannot perform its task or a part thereof). The operation of the CND further includes adjusting in response to abnormal operating conditions related to the mobile application, such as the above-mentioned conditions. Another exemplary operation of the CND includes, in response to abnormal conditions, one or more of the following: ○Providing data values to the vehicle controller from an alternative source (e.g., the data values are from different endpoints, network zones, etc., and this providing step includes encapsulating, configuring, processing, and / or upsampling or downsampling the communication of the alternative source, thereby providing communication equal to the original data values that were lost, or alternative communication sufficient as backup data values for the vehicle controller). ○ For example, when the second vehicle controller is configured to function as a backup for the vehicle controller, can fully have the function of implementing the loss control function, and / or can have the function of implementing an alternative operation (for example, having only more limited functions) instead of the loss control function, and the data value provided to the second vehicle controller can be the same as the data value provided to the vehicle controller, for replacing all or part of the loss control function of the vehicle controller, data values are provided to the second vehicle controller together with alternative source communication (for example, having clearly different data speeds, resolutions, units, precisions, etc.) or another data value (for example, when the second vehicle controller utilizes a clearly different data set to implement an operation with complete functions or an alternative operation). In addition to or instead of this, the CND provides data from any network zone to the vehicle controller and / or the second vehicle controller that may exist on any network zone, ○ For example, when a failure condition or loss of a device or endpoint indicates that one or more data values are not being utilized, when one or more data values are of low priority as determined from an abnormal condition, and / or when one or more data values are indicated as being incorrect as determined from the abnormal condition (for example, a sensor value from a sensor has a failure condition or a fault state), the stage of suppressing the communication of one or more data values in response to the abnormal condition, ○ When the endpoint and / or the device is reachable through more than one network zone (for example, corresponding to when more than one physical path is available between endpoints where these zones are logically separated but physically connected (see FIG. 15), and / or when the second vehicle controller and / or the second endpoint coupled to the second network zone has the function of implementing the operation (or a part thereof and / or its alternative operation) of the first vehicle controller and / or the first endpoint coupled to the first network zone), etc., the stage of shifting communication from the first network zone (for example, a degraded network zone) to the second network zone, Iterating communications from a first network zone (e.g., a degraded network zone) on a second network zone; When the operation of the CND includes adjusting any other operations that cause addressing operations, protocol operations, encapsulation operations, and / or endpoint shifts, for example, when the endpoint is physically connected or connectable to both the first network zone and the second network zone (e.g., when the separation between these network zones is a logical separation and / or when the endpoint is reachable through more than one network zone as shown in FIG. 15), shifting the endpoint from the first network zone (e.g., a degraded network zone) to the second network zone, further including updating the location of the shifted endpoint for other devices / endpoints in the system or converting communications with other devices / endpoints in the system without notifying the shift. Combinations of these steps, such as shifting an endpoint from a first network zone to a second network zone, shifting related communications to the second network zone, and / or iterating related communications on the second network zone; ·Adjusting communication between the end point of the first network zone (and / or one or more additional network zones) and an external device (e.g., a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, a network monitor device, a driver device, a cloud computer device, and / or a third-party application), the step of adjusting communication between the end point of the first network zone and the external device may include any one or more of the above operations and / or restricting communication according to abnormal conditions of system components (e.g., end points, devices, flows, network zones, etc.), restricting communication according to operating conditions of a mobile application, restricting communication according to permissions and / or priorities of end points, related flows, and / or external devices, aggregating according to time (e.g., daily, weekly, monthly, etc.), operating conditions (e.g., trips, events, etc.), and / or restricting communication according to an aggregated data value (e.g., corresponding to a data service provider related to communication, a group of end points, a related flow, and / or an entity related to any one or more of these) that can be aggregated when the data value includes one or more of a total data transmission / reception value, a data speed value, and / or a combination thereof, and / or restricting communication according to an external data access type (e.g., cellular, WiFi, Bluetooth, hardware / port connection, etc.), and / or ·Any one or more combinations of the above steps.

[0030] Referring to FIG. 2, an exemplary system includes a vehicle 202 having a first network 104, a second network 106, and a CND 108 inserted between these networks 104, 106. This exemplary system depicts a vehicle 202 communicatively coupled to an external device 110 and / or communicatively coupled to a second external device 114, similar to that shown in FIG. 1. The example described in FIG. 2 depicts another external device 204 communicatively coupled to the vehicle 202 through a cloud connection 112 in this example. The third external device 204 is shown as a laptop operated, for example, by a fleet service manager, an owner, and / or a vehicle dealership (e.g., a surety manager). The example described in FIG. 2 is an exemplary depiction showing additional context options and a specific use as a vehicle, but is otherwise similar to the system described in FIG. 1.

[0031] Referring to FIG. 3, an exemplary embodiment is shown that includes a vehicle 202 showing certain further details that can exist in certain embodiments. The exemplary system includes a vehicle 202 having a first network 104, a second network, and a CND 108 inserted between the first network 104 and the second network. In the example described in FIG. 3, the second network is an Ethernet network having devices (e.g., an interactive dashboard 302, a door actuator 310, and a transmission controller 320) coupled to an Ethernet switch 312. In the example described in FIG. 3, a third network 318 having a fuel tank sensor 306 coupled to the CND 108 is shown. In this example, the third network 318 can be of the same type as one of the other networks separated from the other networks, for example, to improve installation costs, risk management, or other considerations, and / or can be of a different type to support devices, such as sensors operating on a LIN network. The third network 318 can communicate with the CEG 314 of the CND 108, the Ethernet switch 312, or another device (not shown).

[0032] The example described in FIG. 3 includes a first device on the first network 104 314 (e.g., a controller for a prime mover in the example described in FIG. 3) and several devices on a second network (e.g., the interactive dashboard 302, the fuel tank sensor 306, and the door actuator 310 in the example described in FIG. 3). The system includes one of the devices 302, 310, 320 that communicates with the first device through the CND108 on the second network 314 For example, the door actuator 310 locks the door when the vehicle 202 moves and can pull vehicle movement information (e.g., engine speed, gear position, vehicle speed, and / or state parameters such as a boolean value or bitmask of "vehicle in motion") from the first device 314 The arrangement described in FIG. 3 is a non-limiting example. In addition to or instead of this, a given device (e.g., the prime mover 308) can appear as a single endpoint or multiple endpoints. For example, the controller of the prime mover 308 can provide the first network 104 with many parameters (e.g., engine temperature from an engine temperature sensor) each given an identifier and each operable as a separate endpoint, and / or can include parameters (e.g., engine temperature from an engine controller) thus provided by the controller of the prime mover 308

[0033] The arrangement described in FIG. 3 is a non-limiting example. In addition to or instead of this, a given device (e.g., the prime mover 308) can appear as a single endpoint or multiple endpoints. For example, the controller of the prime mover 308 can provide the first network 104 with many parameters (e.g., engine temperature from an engine temperature sensor) each given an identifier and each operable as a separate endpoint, and / or can include parameters (e.g., engine temperature from an engine controller) thus provided by the controller of the prime mover 308

[0034] To illustrate the example shown in FIG. 3, the first network 104 can be a CAN bus network, in which case the desired data (e.g., vehicle movement indicator) is provided as a CAN message according to the considerations regarding the CAN network. The door actuator 310 is provided on a second network, e.g., an Ethernet network, in which case the door actuator 310 is on a port of the second network. The port for the door actuator 310 can be a physical port (e.g., a dedicated Ethernet switch 312 for the door actuator 310) or a virtual port (e.g., the location of an address for the second network that can be made to exist on a physical port shared with one or more other devices). In the example shown in FIG. 3, the door actuator 310 cannot receive the CAN message indicating vehicle movement, and the CND 108 interprets the request regarding the vehicle movement indicator from the door actuator 310, retrieves this message from the first network 104, and transmits it to the door actuator 310 on the second network.

[0035] The operations performed to send a message may vary depending on the application. For example, CND108 can disclose to a device on a second network that certain parameters are available from a first network 104 (and / or a third network 318), directly provide the selected parameters to the device (e.g., provide a vehicle movement indicator to the requesting device), or disclose data values representing these parameters that are available to a device that receives them periodically (e.g., make the periodically received parameters available using a broker not shown). In certain embodiments, CND108 can limit the disclosure of available parameters to devices, endpoints, applications, and / or flows that are authorized to view these available parameters. In other words, different devices on the second network can view different lists of available parameters depending on the authorization of these devices and / or the applications or flows related to these devices. In certain embodiments, CND108 can limit the provision of these parameters to devices, endpoints, applications, and / or flows that are authorized to receive them, for example, by denying a periodic reception request for the parameters and / or suppressing the transmission of the parameters to unauthorized devices despite periodic reception. Thus, in certain embodiments, a device can confirm that a parameter is available (e.g., within the public list of available parameters), but may not be able to receive the data value of the parameter. In certain embodiments, a device can be restricted to only view available parameters that it is authorized to receive.

[0036] In certain embodiments, the device can have limited availability for receiving parameters, e.g., CND108 can limit the speed of data values to support network utilization reduction, data security considerations (e.g., limiting the accuracy, resolution, and / or data rate of parameters that require care in handling such as vehicle position), and / or proprietary considerations (e.g., limiting the ability to determine how an application can be reverse engineered or otherwise how the control operation functions, e.g., limiting the accuracy, resolution, and / or data rate of parameters that may be related to proprietary control operations).

[0037] In certain embodiments, CND108 determines which parameters to disclose and provide based on stored data that defines permissions and / or functions such as devices, endpoints, applications, and flows, and determines the conditions for providing them. In certain embodiments, CND108 further accesses stored data that defines processing operations or adjustment operations on the data, such as encapsulation operations (e.g., for passing CAN messages to an Ethernet network), unit conversions, and timestamp definitions. In certain embodiments, CND108 determines approvals for applications and / or flows that are on the vehicle, outside the vehicle (e.g., operating on external devices such as 110, 114, 204), or a combination of on and outside the vehicle. In certain embodiments, CND108 can support prioritization of data flows including the rate at which a device provides or receives information based on the prioritization of related devices, endpoints, applications, flows or other parameters. In certain embodiments, CND108 can support differential prioritization based on vehicle status or operating conditions, for example using a first priority scheme during startup operations, a second priority scheme during runtime operations, and a third priority scheme when the vehicle is in motion. In certain embodiments, CND108 can respond to any defined vehicle conditions such as charging operations, regeneration operations, post-processing operations, control plans (e.g., driving versus driver control), emergency events, fault conditions, or inspection and repair conditions.

[0038] The exemplary CND108 shown in FIG. 3 includes a first device 314 that communicates with a first network 104. The exemplary first device 314 includes a configurable edge gateway (CEG) that reads communications from the first network 104 and provides them to a second network 106. In certain embodiments, the first device 314 transforms the communications for the second network, for example, encapsulating the communications, a portion of a communication frame, and / or the payload of a communication within a message for the second network. In certain embodiments, the first device 314 has the function of requesting communications from devices on the first network 104, for example, requesting parameters that are available but not currently communicated on the first network 104. In certain embodiments, the first device 314 is not part of the CND108, but is controlled by the CND108, for example, in response to a command from the CND108, by accessing stored data that is all or partially written by the CND108, or by other operations provided throughout the disclosure of the present invention.

[0039] The exemplary CND18 shown in FIG. 3 includes a second device 312 that communicates with a second network. The exemplary second device 312 can be made configurable and includes an Ethernet switch that reads communications from the second network. In certain embodiments, the second device 312 receives a message from the first network 104 through the first device 314, for example, receives the message in a format communicable on the second network. The exemplary first device 314 includes a CEG that communicates through a port on the Ethernet switch provided for messages from the first device 314 to the Ethernet switch. Thus, FIG. 3 provides an embodiment of a second device 312 on a second network that communicates with a first device 314 via the CND108.

[0040] The exemplary system includes external devices 110, 114, 204 that communicate with the CND 108. In the example depicted in FIG. 3, the external devices 110, 114, 204 can communicate through transceiver 304 and / or via direct access to the network of vehicle 202 (e.g., using a service port, an OBD port, WiFi, Bluetooth, etc.). The external devices are structured to adjust the configuration of the CND 108 by changing stored data that defines, for example, publicly available data, associated permissions, defined applications, defined flows, defined endpoints, and defined devices. In certain embodiments, the external devices have an associated permission value and the CND 108 provides changes in accordance with the associated permission value, for example, blocking adjustments to changes regarding certain networks, devices, endpoints, applications, or flows.

[0041] The exemplary system includes a first network as a bus network, and further the bus network can be a CAN bus network. The exemplary system includes a second network as an Ethernet network that can have any alternative topology such as a data bus architecture. In certain embodiments, the Ethernet network has a data bus architecture as a hardware topology but can operate in a different logical manner (e.g., as a switched network).

[0042] Referring to FIG. 4, an exemplary system includes a CND 108 having a first network gateway device 404 and a second network gateway device 402. In the example shown in FIG. 4, the first network gateway device 404 is a CEG that accesses one or more endpoints 408, e.g., one or more CAN-based networks 406 each having a device coupled to a CAN network 406 to provide communication to and / or receive communication from each respective CAN network 406. The example shown in FIG. 4 depicts two CAN networks 406 (e.g., for splitting according to any other arrangement such as by function of vehicle components, by location within the vehicle, and / or by groups of related components communicating on a common CAN network 406) that can be arranged for convenience of integration. In this example, the first network gateway device 404 communicates with both CAN networks 406, but the CND 108 can include more than one CEG, e.g., one CEG accessing each CAN network 406 and / or each CEG accessing a subset of the CAN networks 406 on the vehicle, and / or can be configured to coordinate these CEGs. The example shown in FIG. 4 shows a bus network 406, and while the network 406 is described as a CAN network for illustrative purposes, the network 406 can be of any type described throughout the disclosure of the present invention. The endpoints 408 can be any type of endpoint having a function to communicate with the network 406, such as a controller, a smart sensor, or a smart actuator, or any other device having a function to provide communication to and / or receive communication from the network 406.

[0043] The example described in FIG. 4 represents CND108 as including network gateway devices 402, 404, but CND108 can be separate from one or both of network gateway devices 402, 404 and can be configured by, for example, adjusting data stored therein that governs the operation of network gateway devices 402, 404, adjusting stored data accessible to devices 402, 404, providing instructions to these devices, and / or performing any other operations recited throughout the disclosure of the present invention.

[0044] In the example shown in FIG. 4, the second network gateway device 402 is an Ethernet switch, and the Ethernet switch 404 accesses an Ethernet-based network 410 shown as several endpoints 412 communicating with some of its ports 414. The ports 414 are shown schematically and can be logical ports, hardware ports, or a combination thereof. The physical topology of the Ethernet network 410 can be a bus arrangement, a hub arrangement, a star arrangement, or any other type of network topology, and can be different from the logical topology of the Ethernet network 410. The second network gateway device 402 is shown as having a network interface 416 that can include a physical port connection. In certain embodiments, the second network gateway device 402 is a configurable Ethernet switch that can include a processor, computer-readable storage (e.g., storing instructions, configuration information, buffering for data communication operations and / or collection operations, and performing further similar things). Although these aspects are not shown for purposes of illustration and clarity of this description, these aspects can be present on the second network gateway device 402, present within the same housing as the second network gateway device 402, located on another device within the system and communicating with the second network gateway device 402, separate from the network interface 416 and / or separate from the remainder of the second network gateway device 402 on a separate substrate (e.g., mounted on a separate printed circuit board), such as on the first network gateway device 404, on a vehicle controller, and / or on another controller within the system, and / or can be distributed across a combination of these locations.

[0045] In the example described in FIG. 4, the first network gateway device 404 includes one or more network interfaces 418 (and / or network interface circuits) that communicatively couple it to network 406, and a conversion circuit 420 that includes messages from Ethernet network 410 for communication to network 406 and / or messages from network 406 for communication to Ethernet network 410. In addition to or instead of this, for example, if these networks 406 are of different types, utilize different protocols, or otherwise have competing source or destination information, and / or for message compatibility, to ensure the successful mission operation of the vehicle, and / or to implement any other configuration operation shown in the disclosure of the present invention, and the conversion circuit 420 is considered to have other distinct characteristics managed by the first network gateway device 404, the conversion circuit 420 includes messages for transfer from one of the networks 406 to another of the networks 406. Although the conversion circuit 420 is shown as a single device, the conversion circuit 420 can be implemented as one or more devices having some components of the conversion circuit 420 that each implement a certain type of configuration to distribute its processing operation and / or memory operation, or for any other reason according to a particular system, and interact with a certain type of network 406. In the example described in FIG. 4, the first network gateway device 404 provides a message to the Ethernet switch in response to a corresponding message on the CAN-based network 406. In the example described in FIG. 4, the first network gateway device 404 provides a message to port 414 of the Ethernet switch. In the example described in FIG. 4, any message provided from network 406 appears on Ethernet network 410 as a message on the port between the conversion circuit 420 and the network interface 416, and a message from Ethernet network 410 is received through the port between the conversion circuit 420 and the network interface 416.The conversion circuit 420 provides configuration operation between messages, and endpoints on each of the networks 406, 410 can communicate with each other adjusted by the CND108 as described above.

[0046] The example described in FIG. 4 further includes an on-board diagnostic (OBD) interface 422, which in this example communicates with a dedicated OBD port 424. The example described in FIG. 4 is for illustrative purposes and is non-limiting. The OBD interface 422 can be connected to any network or to more than one network (e.g., to support multiple OBD tools that can be connected to a vehicle). The exemplary embodiment includes an OBD interface 422 connected to the second network gateway device 402. For example, in this case, the OBD system is substantially CAN-based, and many of the OBD parameters are specific to one or more of the CAN networks 406, enabling less traffic between the conversion circuit 420 and the network interface 416. Instead, the OBD interface 422 can be present on the Ethernet network 410 or on more than one of the networks 406, 410 of the system. Regardless of the location of the OBD interface 422 and the location where the OBD-related data of the networks 406, 410 is generated, the OBD requests and information can be made available to the OBD port 424 (which can be another external connection including a physical connection, a wireless connection, or a mobile data connection) by the operation of the CND108 that authorizes and provides inter-network communication from any endpoint on the networks 406, 410. Further, the example described in FIG. 4 uses the OBD interface 422 as a non-limiting example, but any type of special dedicated and / or proprietary interface having an interface and a port that can make any data available from any endpoint on the networks 406, 410 and be subject to configurable adjustment by the CND108 can be provided in a similar manner.

[0047] The exemplary system includes a CND 108 structured to be inserted between an electrical sensor and one of networks 406, 410 to provide sensed values responsive to the electrical response of the electrical sensor onto the network. For example, one of networks 406 can be an electrical connection to a second network gateway device 402 having an associated endpoint 408 as the electrical sensor, in which case the conversion circuit 420 converts the electrical signal from the sensor for communication for each network (e.g., network 410 or another network 406). In this example, the conversion circuit 420 can perform processing operations on the electrical signal such as analog / digital (A / D) processing, determination of display bits, determination of display values, signal debouncing, signal filtering, diagnostic bit detection (e.g., determination of faults and conversion to corresponding fault values, and / or conversion from a predetermined voltage value to a corresponding fault value), saturation management (e.g., limiting the output to a predetermined value), and slew rate limiting (e.g., applying a rate of change limit to the display value). The electrical signal from the sensor can be a voltage value, a frequency value, a display resistance value, or any other type of sensor electrical value known in the art, if present.

[0048] In another example, the system includes a CND108 structured to be inserted between an electric actuator and one of the networks 406, 410 to provide command values from the network as a configured electrical response to the electric actuator. For example, one of the networks 406 can be an electrical connection to a second network gateway device 402 having an associated endpoint 408 as an electric actuator, in which case the conversion circuit 420 converts communications from each network (e.g., network 410 or another network 406) into electrical signals for the actuator. In this example, the conversion circuit 420 can perform processing operations on the electrical signals such as digital-to-analog processing, determination from display bits for corresponding values, provision of diagnostic bits, saturation management, and slew rate limiting. The electrical signal to the actuator can be, if present, a voltage value, a frequency value, a modulation value, or any other type of actuator electrical value known in the art. In certain embodiments, the electric actuator can further have sensed values (e.g., position feedback, acknowledgement response, etc.), and / or other feedback values that can be provided on the same or clearly different electrical connections and can be part of the same or clearly different networks (e.g., operation on one network 406 and feedback on a second network 406) (e.g., a certain electrical value indicating the actuator has a fault condition, is non-responsive, is in an immobile state, is in a saturated state, etc.).

[0049] It can be seen that the embodiment described in FIG. 4 enables communication between endpoints on clearly different networks without requiring knowledge of how the endpoint communicates with other endpoints or where the other endpoints are located. Without being limited to any other aspect of the disclosure of the present invention, the embodiment described in FIG. 4 provides functions for the operation of a vehicle network having distributed devices on a plurality of clearly different networks including different types of networks. Further, the embodiment described in FIG. 4 provides for the operation of the vehicle when the device moves between networks without being limited to whether the device has changed its communication function. For example, a first device on a CAN network that is moved to an Ethernet network can continue to function by virtue of the appropriate configuration of the CND108 to move the messages that this device was using from the CAN network to the Ethernet network and make them available to this device in its new location. In certain embodiments, the migrated device can continue to use the CND108 configured to encapsulate the entire original CAN message into an Ethernet message (e.g., into a frame, into a packet, and / or in a specified manner) so that the migrated device can receive the previous CAN message that was first presented and used by this same local control in accordance with the specifications of the previous CAN message, including, for example, the same local control, such as bit depth, resolution information, message speed, and floating point / fixed point data nature. Thus, the embodiment described in FIG. 4 and the principles shown with respect to FIG. 4 enable these changes, whether they occur across several vehicles (e.g., changes that occur over a design review process, model year, or the like), or within the scope of the same vehicle (e.g., inspection and repair, upgrade or change to an endpoint, upgrade, upfit, recall replacement, etc.), solely by updating the configuration of the CND108 to support these changes.In certain embodiments, the embodiments described in FIG. 4 and the principles shown with respect to FIG. 4 contemplate a range of endpoints that may be made available in more than one possible location and / or configuration of a network, and where CND 108 determines an endpoint placement on a vehicle and is thus configured to utilize a selected configuration (e.g., from among two or more available configurations), enables a change in the mixed state of endpoint devices between networks without the need to update the configuration of CND 108. Thus, the embodiments described in FIG. 4 and the principles shown with respect to FIG. 4 enable a change in the mixed state of endpoint devices between networks in at least a predetermined range of endpoint devices and configurations without any changes to the vehicle and with further intermittent or no communication with external devices for the configuration of CND 108 to support vehicle operation.

[0050] Referring to FIG. 5, the exemplary system includes a CND108 that can be physically and logically separated on the vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme) and / or that coordinates communication between a plurality of networks that can be of one or two or more different types. The embodiment depicted in FIG. 5 generally aligns with the embodiment depicted in FIG. 4 with some differences highlighted to emphasize certain aspects of the disclosure of the present invention. The example depicted in FIG. 5 includes additional interfaces 504, 506 that can be separate networks or network zones with respect to network 406. The example depicted in FIG. 5 depicts a vehicle control device interface (VCDI) 508 that can be an interface to any type of vehicle controller (e.g., engine controller, transmission controller, anti-lock braking system (ABS) controller, advanced driver assistance system (ADAS) controller, door controller, battery controller, head unit, interactive dashboard, etc.) that provides communication to endpoint 504, and / or an electrical interface to a sensor, actuator, or combination of sensor and actuator, etc. The example depicted in FIG. 5 depicts an additional interface 506 to endpoint 502 that can be a communication device of any type understood in the art or shown herein. In the embodiment depicted in FIG. 5, a network interface circuit 418 is shown between endpoints 408, 502 and conversion circuit 420 to enable interfacing with the many network types that can be present on the vehicle, 416 is shown between endpoints 408, 502 and conversion circuit 420. Interface circuit 418, 416It can be arranged together with the conversion circuit 420 or located at any other location and communicatively coupled to the relevant network and the conversion circuit 420. The example described in FIG. 5 further depicts networks 512, 514 communicatively coupled to a first network gateway device 404 through an endpoint 412 on the same network as the network interface 416. In certain embodiments, since communication to the networks 512, 514 is provided through the endpoint 412, CND108 does not have or require specific knowledge about the networks 512, 514 or the relevant endpoints 516, 518. However, CND108 is structured to provide communication from a network that communicates with a second network gateway device 402, such as a network interfaced at the networks 406 and / or endpoints 504, 506. Communication from the second network gateway device 402 can provide request information (e.g., ambient temperature, door position, vehicle speed) as, for example, an encapsulated payload that provides this information or as a proprietary message (e.g., a CAN message indicating ambient temperature, door position, vehicle speed, and / or a LIN message having relevant sensor information). Accordingly, the endpoints 516, 518 can share tunneling messages with the network 406 (or other network) in a shared format or receive information from any network on the vehicle that is subject to adjustment by CND108.

[0051] Referring to FIG. 6, an exemplary system includes a CND108 that can be on a vehicle and physically and logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme) and / or that coordinates communication between a plurality of networks that can be of one or two or more different types. The embodiment described in FIG. 6 generally aligns with the embodiment described in FIG. 4 with some differences shown to emphasize certain aspects of the disclosure of the present invention. Without being limited to any flexibility of the arrangement shown in FIG. 4, the example described in FIG. 6 depicts a conversion circuit 420 disposed in a first network gateway device 404.

[0052] Without being limited to any other aspect of the disclosure of the present invention, the collocations shown in FIG. 6, when utilized herein, can indicate physical collocation (e.g., the conversion circuit 420 is within a shared housing with the first network gateway device 404 and / or is disposed on the same substrate as the first network gateway device 404), and / or logical collocation (e.g., grouping of the operating burdens of the execution hardware, such as connections, connectivity, operating instructions, stored data, data storage, and / or processing resources). The determination of the collocation scheme depends on the purpose of the collocation (e.g., sharing hardware resources, reducing the number of external interfaces, simplifying and / or diversifying the risk profiles of the collocated components and / or other components within the system related to these components), the nature of the collocation components (e.g., hardware implementation, processing resources, and / or memory resources related to the collocation components), the division of ownership of the collocation components (e.g., manufacturer, supplier, inspection and repair personnel, vehicle owner, vehicle driver), the operating burdens of the components and / or the vehicle (e.g., certainty, operating obligations, inspection and repair, insurance, operating-time burdens, etc.), and / or the integration burdens of the components (e.g., installation, design, meeting footprint requirements, compromise between components, and / or the ability to affect these).Accordingly, in certain embodiments, the step of colocating components can include one or more of placing the components within a housing or group of housings, placing the components in a selected geometric proximity, placing the components in a selected logical arrangement (e.g., associating within the same flow or group of flows, associating within the same application or group of applications, providing operating constraints such as parameter naming, memory allocation, or execution order), placing the components in a selected risk profile arrangement (e.g., placing in the same zone of influence subject to the same failure mode (e.g., electrical influence, logical influence, failure influence, physical influence, and / or dependency on physical components such as pumps, cooling systems), the same temperature environment, the same NVH environment, the same EMI environment), placing on the same substrate, and / or placing on a location of shared memory (e.g., where computer-readable instructions are placed at a location of shared memory and / or executed by the same processor resources). In this example, NVH is a "noise, vibration, and harshness" environment and EMI is an "electromagnetic interference" environment. Those of ordinary skill in the art having the benefit of the disclosure of the present invention and having information normally available when considering a particular system can readily determine the implementation of components to be colocating as shown in the disclosure of the present invention. It can be seen that components arranged in one or more of the described colocating schemes may or may not be colocating in certain embodiments and / or may be colocating for the purpose of certain operating conditions but not for the purpose of other operating conditions.Certain considerations for determining whether components are collocated, and the collocation scheme selected for these components, include (but are not limited to) the purpose of collocation, the operating cost of resources (e.g., communication, processing resources, operating restrictions on vehicle tasks, operating impacts on vehicle tasks, e.g., cooling requirements, and power consumption, etc.), the capital cost of resources (e.g., computer power, network infrastructure, memory resources, quality requirements or functional requirements of individual components, shielding requirements, data throughput regardless of whether inside or outside the vehicle, etc.), the integration cost for components (e.g., footprint availability and cost, interface management, design flexibility and lock-down trajectory, and / or the ability to compromise and / or optimize with other aspects of the system), and / or the ability to distribute costs to other stakeholders related to the system (e.g., these stakeholders are suppliers, manufacturers, customers, and / or inspection repairers, and this ability can include the ability to distribute high costs related to high functionality and / or the ability to exchange costs among stakeholders).

[0053] In the example described in FIG. 6, the conversion circuit 420 can provide communication by, but not limited to, inputting data to and / or reading data from a memory shared with the network interface 416, and / or by communicating with the port 414 (not shown).

[0054] Referring to FIG. 7, the exemplary system includes a CND 108 that can be physically and logically separated on the vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme) and / or that coordinates communication between a plurality of networks that can be of one or two or more different types. The embodiment depicted in FIG. 7 generally aligns with the embodiment depicted in FIG. 4, with some differences highlighted to emphasize certain aspects of the disclosure of the present invention. Without being limited to any flexibility of the arrangement shown in FIG. 4, the example depicted in FIG. 7 depicts a conversion circuit 420 having a first portion 702 collocated with a second network gateway device 402 and a second portion 704 collocated with a first network gateway device 404. Each portion 702, 704 of the conversion circuit 420 can be separated for any reason including by network (e.g., which network 406 is receiving the information), by predetermined endpoint, by flow, by conversion operation (functionally managing differences by processing frame information, processing payload information, downsampling, upsampling, buffering, providing communication commands, encapsulating messages into another message format, etc.), and / or by direction of communication (e.g., the direction between selected networks, the direction between gateway devices, the direction between endpoints, the direction between flows, or combinations of these directions) to at least separate the conversion operations.

[0055] Referring to FIG. 8, the exemplary system includes a CND 108 that can be physically and logically separated on a vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme) and / or that coordinates communication between a plurality of networks that can be of one or two or more different types. The embodiment described in FIG. 8 generally aligns with the embodiment described in FIG. 4 with some differences shown to highlight certain aspects of the disclosure of the present invention. In the example described in FIG. 8, the first network gateway device and the second network gateway device are collocated and are omitted as being shown as part of the CND 108. In certain embodiments, the CND 108 described in FIG. 8 can instead be a composite gateway device that is coordinated by the CND 108 rather than forming part of it. In certain embodiments, one or two or more portions of the composite gateway device can form part of the CND 108 and other portions of the composite gateway device are coordinated by the CND 108.

[0056] Policies, as used herein and not limited to any other aspect of the disclosure of the present invention, include descriptions of the data collected such as data parameters, collection speed, resolution information, priority values (e.g., ordering data collection values in response to a selection for abnormal conditions that may not be able to provide information on all data collection parameters). In certain embodiments, the policy can further include event information defined as a parameter or a quantitative-based event (e.g., a given data value being greater than a threshold, etc.), and / or a categorical event (e.g., a specific fault code, operating condition or state, or vehicle location / jurisdiction area occurring). In certain embodiments, the policy further includes an event response such as the data values to be captured in response to the occurrence of an event, and / or other changes to the data collection scheme such as an increase or decrease in the data collection speed, or a change in the collection resolution. In certain embodiments, the event response further includes a time frame related to the event occurrence, e.g., the period for using the adjusted data collection scheme after the event occurrence, and / or the period preceding the event occurrence (e.g., providing temporary information that can be captured later when an event occurs, using a rolling buffer or other data collection operations). In certain embodiments, the change to the data collection scheme for an event can include multiple changes, e.g., changes over a period of time, further other changes based on the progression of the event (e.g., when the event severity deteriorates), and / or further other changes based on the criteria for determining that the event has been resolved. In certain embodiments, the change to the data collection scheme can be implemented based on the event-related resolution of the same or another event, e.g., until the next stop event of the vehicle, until the service technician resolves the event, during the occurrence of a selected number of stop events, or during a similar period. In addition to or in place of this, the policy can include parameters for performing any adjustment operations on any of the adjusted components enumerated throughout the disclosure of the present invention.

[0057] The use of policies herein can refer to secondary policies, such as implicit policies that will be implemented in response to a single data collection scheme from a single user, and the complete policy is prepared, verified, and communicated to the vehicle after one or more secondary policies are collected. The use of policies herein can refer to unvalidated policies, such as those after policies in response to several users are collected but the policy verification operation has not yet been completed (e.g., before it is determined whether data collection suggested by the policy can be implemented). The use of policies herein can refer to previously applied policies (e.g., policies that existed before an updated version of the policy is communicated to and / or implemented on the vehicle). The use of policies herein can refer to updated policies, such as verified policies (e.g., from CND108) waiting for communication to the vehicle and / or confirmation by the vehicle.

[0058] Referring to FIG. 9, the exemplary system includes a CND 108 that can be physically and logically separated on a vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme) and / or can adjust communications between a plurality of networks that can be of one or two or more different types. The embodiment described in FIG. 9 generally aligns with the embodiment described in FIG. 4 with some differences shown to highlight certain aspects of the disclosure of the present invention. In the example described in FIG. 9, the first network gateway device 404 and the second network gateway device 402 are not collocated, and a CND 108 communicating with the first network gateway device 404 is shown. The CND 108 can be in communication with any one or more of the network gateway devices and / or can be at least partially disposed on one or more of the network gateway devices. In addition to or instead of this, the CND 108 can adjust communications between the networks by accessing and / or adjusting a memory location (e.g., a policy, a configuration instruction, or a configuration table, etc.) available to one or more of the network gateway devices, in which case, if the CND 108 does not communicate directly with other network gateway devices, the applicable portion of the instruction (if any) can be passed to these devices. In certain embodiments (not shown), the CND 108 can utilize one or more of the networks (e.g., at port 414 of the first network gateway device 404) to communicate with one or more of the network gateway devices. In certain embodiments, the CND 108 can be at least partially disposed on one or more of the network gateway devices, collocate with one or more of the network gateway devices, and / or can be included (at least partially) within one or more components of the network gateway devices (e.g., a conversion circuit and / or a network interface circuit).

[0059] Referring to FIG. 10, an exemplary first network gateway device 404 is shown. In the example described in FIG. 10, the first network gateway device 404 is a configurable Ethernet switch that includes an Ethernet network interface 416 (or Ethernet network interface circuit) having several ports 414 for communication with an Ethernet network. The ports 414 can be physical ports, logical ports, or a combination thereof.

[0060] Referring to FIG. 11, an exemplary second network gateway device 402 is shown. In the example described in FIG. 11, the second network gateway device 402 is a configurable edge gateway (CEG) that provides conversion between a secondary network 406 and a primary network interface (e.g., an Ethernet network such as network 410). The secondary and primary references to the network merely indicate the logical arrangement of the network, in which case an interface to a non-primary network is referred to as an edge interface (e.g., interfaced to an edge gateway). In certain embodiments, the primary network can have higher capabilities (e.g., bandwidth, throughput, and / or dedicated resources), more devices or endpoints on the network, a transitioning target network over time for the endpoints (over the life of a vehicle, vehicle fleet, model year period, etc.), and / or external communication (e.g., updates via wireless communication, configuration updates, data collection, etc.), although particular embodiments may have some, all, or none of these considerations for what is considered the primary network. The example described in FIG. 11 depicts an optional OBD interface 422 that may or may not be present anywhere else in the system or in the system.

[0061] Referring to FIG. 12, a vehicle having several networks therein and with communication between these networks being coordinated by CND 108 is shown. The arrangement described in FIG. 12 is presented to illustrate certain aspects of the disclosure of the present invention and is a non-limiting arrangement. The example described in FIG. 12 includes endpoints 1612, 1204 (e.g., one or more vehicle controllers) coupled to a first network 406 and several endpoints 1206, 1208, 1210, 1212 coupled to a second network (e.g., an Ethernet network having a switch collocated with CND 108 and / or at least partially separate from CND 108). In the example described in FIG. 12, controllers 1202, 1204, 1206, 1208, 1210, 1212 can relay communication coordinated by CND 108 between heterogeneous networks of the vehicle. In certain embodiments, a given controller can be switched between networks, maintaining communication with other controllers within the vehicle and / or communication external to the vehicle, and can be maintained regardless of whether a related controller (or external controller, application, or device) has knowledge of the switch.

[0062] Referring to FIG. 13, a vehicle having several networks therein and the communication between these networks being adjusted by CND108 is shown. For illustrative purposes, the example described in FIG. 13 includes the same network and controller set as the example described in FIG. 12. In the example described in FIG. 13, controllers 1204, 1208, 1210, and 1212 are collocated at 1302, and further, controller 1204 has been moved from the first network 406 to the second network. The collocation 1302 of controllers 1204, 1208, 1210, 1212 can be any implementation including the aggregation of controllers into a smaller number of housings (1 to 3 total housing numbers instead of 4), a smaller number of circuit boards (1 to 3 total circuit board numbers instead of 4), and / or the utilization of at least partially shared computer resources (e.g., shared processing, shared memory, shared cache, and / or combinations thereof). In certain embodiments, the utilization of CND108 enables the aggregation of vehicle controllers by allowing the adjustment of communication and the maintenance of connectivity only by updating the configuration to CND108 and / or only by aggregating changes to the vehicle controllers that fit within a predetermined configuration available to CND108 (thereby enabling implementation without an update to CND108), enabling the arrangement described in FIG. 13 that includes the aggregation of vehicle controllers. Further, the aggregation of controllers can bring several advantages such as reduction of network cost, reduction of network traffic, selective risk dispersion (e.g., the placement of controller positions to lower risk or dispersed risk locations and / or network routing, and / or the reduction of risk to other system components by obtaining a footprint and / or cost savings through controller aggregation).In certain embodiments, the consolidation of controllers can enable deeper information sharing between controllers (e.g., due to large available network capacity, avoidance of network limitations by shared controllers, and / or utilization of shared memory resources), thereby providing higher-function controller operation and / or operations that were previously unavailable due to shared information between controllers not being readily available. In certain embodiments, CND108 further enables controller consolidation by separating the location of the controllers from the location of endpoints (not shown) that require distribution (e.g., it is no longer necessary to position sensors and actuators, which need to be located at certain locations to perform their functions, near their respective controllers due to the operation of CND108 and / or CEG402). In certain embodiments, controller consolidation enables low cost and / or high functionality, for example, by reducing hardware costs for shared computer resources, enabling computer resources with higher functionality (e.g., processing power and / or memory), or a combination thereof. Thus, the operation of CND108 provides consolidated operation of vehicle controllers that was previously unavailable. In certain embodiments, the example described in FIG. 13 can be illustrative of controller consolidation and / or unrelated embodiments with respect to FIG. 12.

[0063] Referring to FIG. 14, a vehicle is shown having several networks therein, with communication between these networks being coordinated by CND 108. For illustrative purposes, the example described in FIG. 14 includes the same networks and a similar set of controllers as the example described in FIG. 12. In the example described in FIG. 14, the collocation 1302 controller includes the set of controllers 1402, 1404, 1406, and CND 108 shown as a controller on the collocation 1302 controller. CND 108 can be at least partially disposed on one or more of the collocation controllers 1402, 1404, 1406, and / or can be separate as illustrated. In certain embodiments, the example described in FIG. 14 can be a further aggregation of the controllers with respect to FIG. 13, and / or an illustration of a collocation 1302 controller unrelated to the examples described in FIGS. 12 and 13.

[0064] Referring to FIG. 15, a vehicle having several networks therein and communication between these networks being adjusted by CNDs 1502, 1504 is shown. For illustrative purposes, the example described in FIG. 15 utilizes two aggregation controllers 1302, 1506, each including a set of collocated vehicle controllers enumerated throughout the disclosure of the present invention. The example described in FIG. 15 includes a first CND 1502 (or CND portion) inserted between a first network 406 and a second network (where the end point 412 is directly coupled to CND 1502 and the aggregation controller 1506 is directly coupled to CND 1502), and a second CND 1502 (or CND portion) inserted between the first network 406 and the second network (where the end point 412 is directly coupled to CND 1504 and the aggregation controller 1302 is directly coupled to CND 1502). In certain embodiments, the second network connected to the first CND 1502 can be a separate network from the second network connected to the second CND 1504, but can be the same type of network (e.g., an Ethernet network), and / or can utilize hardware that is the same or electrically coupled to each other. The example described in FIG. 15 shows a CND 1504 having a primary network adjustment for the first network 406, but the adjustment of the first network 406 can be performed such as distributing, sharing, end-point, or application, and / or adjusting according to the flow. In certain embodiments, the adjustment of the second network can be performed by only one of the CNDs 1502, 1504, and / or can be adjusted according to distributing, sharing, end-point, application, and / or flow.

[0065] Some representative embodiments described in FIG. 15 are described below, and any one or more of them can exist in a certain embodiment. The exemplary embodiments described in FIG. 15 include network adjustments shared by CND1502 and 1504. For example, when an endpoint, network, the other (or part) of the CND, and / or the controller experiences a defect, failure, or degradation of operating function, both CND1502 and 1504 have the function of fully or partially supporting the adjustment of all networks. The exemplary embodiments described in FIG. 15 include primary adjustments of the network by one of CND1502 and 1504. For example, when an endpoint, network, primary CND, and / or the controller experiences a defect, failure, or degradation of operating function, the other CND has the function of fully or partially supporting the adjustment of all networks. The exemplary embodiments described in FIG. 15 include one or both of the aggregation controllers 1302 and 1506 having the function of at least partially taking over the control operation regarding the other of these aggregation controllers when one of the aggregation controllers 1506 and 1302 loses its function or connectivity with an endpoint. In certain embodiments, CND1502 and 1504 have the function of responding and transferring parameters that were previously only available to the original controllers 1302 and 1506 by taking over the control operation by the replacement controllers 1506 and 1302. In certain embodiments, the availability of redundant network path specifications is usable by CND1502 and 1504 to at least partially provide connectivity between endpoints that have lost their connection when a part of the network fails.CND1502 and 1504 can provide equivalent parameters (e.g., another endpoint having a function to provide equivalent data), alternative parameters (e.g., an alternative endpoint having a function to provide an alternative parameter that can be at least partially used as an alternative to a loss parameter or a backup parameter), the same parameter (e.g., when data from an original endpoint or the same data value from another endpoint can be routed through the remaining network infrastructure), and / or can provide management parameters such as controller handoff communication, heartbeat communication, or status communication. In certain embodiments, one or both of CND1502 and 1504, or a CND portion can be collocated with another system component such as one of aggregation controllers 1302 and 1506. In certain embodiments, network routing is performed on these networks on the vehicle to provide clearly different risk profiles for a plurality of networks on the vehicle and to reduce the risk of a single failure that disables the vehicle with respect to such tasks and / or at least with respect to limp-home operation, controlled stop, or data capture. In certain embodiments, the location of the controller, CND, and / or aggregation controller can be selected to provide clearly different risk profiles for a plurality of associated devices and to reduce the risk of a single failure that disables the vehicle with respect to such tasks and / or at least with respect to limp-home operation, controlled stop, or data capture. In certain embodiments, network routing is performed on these networks on the vehicle to provide a lower operating cost, installation cost, integration cost, overall risk profile, or dispersion of the weight and / or footprint of components on the vehicle.

[0066] The resolution of competing priority rights can be implemented using any method such as always giving priority to the requester with the highest priority, providing a weighted response based on priority (e.g., providing more information in more cases for requests with higher priority than for requests with lower priority), and / or using a credit-based scheme that allows providing information for requests with lower priority after a certain period and / or number of requests while giving priority to higher priority requests. The resolution of competing priority rights can include a stage of meeting the service performance requirements (e.g., QoS values) for requests with higher priority and a stage of providing information for requests with lower priority to the extent possible while meeting the performance requirements for requests with higher priority.

[0067] When used in this specification, the tasks of a device (e.g., a controller, an endpoint, a vehicle, a mobile application, etc.) must be understood broadly and include, at a minimum, the relevant functions, structures, capabilities, and operations of the device that support the operation of a mobile application that implements the intended function or primary function of the mobile application. Without being limited to any other aspect of the disclosure of the present invention, the intended function or primary function of the mobile application includes one or both of the propulsion operation of the mobile application (e.g., having a specified torque, speed, responsiveness, etc.) according to the design of the propulsion function and / or the non-propulsion operation of the mobile application by the designed non-propulsion function (e.g., industrial operation, vocational operation, pumping operation, shaft power, providing a range of movement, and control thereof). In certain embodiments, the intended function or primary function of the mobile application may include abnormal operation responses that can have only functions lower than the designed propulsion or non-propulsion functions, such as operation in a limp-home mode, communication of a fault condition or fault conditions, and / or prevention of further degradation of the vehicle and / or the mobile application. In certain embodiments, the intended function or primary function of the mobile application includes transmitting and / or receiving external data, performing an update operation, facilitating a service operation, facilitating an update, and / or an upgrade operation, etc. Accordingly, the tasks of the device may vary among mobile applications according to the current operating conditions of the mobile application and / or according to the current status of the mobile application and / or components, devices, and / or their controllers. Those skilled in the art having the benefit of the disclosure of the present invention and having information normally available when considering a particular mobile application will readily understand the tasks of the mobile application, the role of the device of the mobile application, and the availability of these devices across the operating conditions and status conditions of the mobile application.

[0068] Referring to FIG. 16, an exemplary system 1600 for providing vehicle external communication control consistent with an embodiment of the disclosure of the present invention is shown. The systems described throughout the disclosure of the present invention can be provided on a mobile application such as a vehicle or as otherwise described throughout the disclosure of the present invention. The exemplary systems herein, for example, enumerate specific arrangements of a centralized network device (CND) 108, circuits, controllers, or other components. These arrangements are provided for purposes of clarity of this description, but these components can have distinctly different relevancies for purposes of forming and implementing the systems and procedures described herein as to whether they are distributed, combined, separated, and / or drawn.

[0069] The circuits, controllers, processors, or other devices shown herein are configured to functionally implement the operations described herein and can include computer components such as processors, memories, and / or communication components. In addition to or instead of this, such devices can include logic circuits, hardware configured to implement one or more functions of the device, any type of sensor, actuator, and / or display. A given circuit, controller, processor, or other such device can be distributed and / or grouped in whole or in part with other such devices.

[0070] Certain operations herein are described as interpreting or receiving parameters or obtaining parameter values using other similar language depending on the situation. Any such operation may include the step of receiving a parameter value as network communication, receiving a parameter value from a sensor, receiving a parameter value as a feedback value (e.g., actuator position, reported fault code value, etc.), receiving a parameter value from a memory location accessible to an interpretation device or a receiving device, receiving a parameter value as a command, receiving a parameter value as a response to a request from a receiving device or an interpretation device, and / or receiving a precursor value from which the parameter is at least partially determined (e.g., the step of operating a virtual sensor using other information to determine a parameter value to be interpreted or received, the step of determining a situation value based on received information if a situation value is received or interpreted for the purposes of this description, and / or the step of inferring an interpretation value using received information). Further, any such operation may include more steps than these (e.g., the step of interpreting parameter values at different times, under different operating conditions, during abnormal conditions, in a clearly different scheme depending on the source of the parameter value and / or the use or purpose of the interpreted parameter value at a given time or during certain operating conditions), and / or combinations of these steps (e.g., the step of operating a virtual sensor on received information to determine a precursor value and determining an interpreted parameter value in response to the precursor value).

[0071] Exemplary system 1600 includes a first network zone 1612 and a second network zone 1614, and vehicle 102 in which the first network zone 1612 and the second network zone 1614 are different types of networks. Without being limited to any other aspect of the disclosure of the present invention, the various types of networks described herein include differences in network functions (e.g., bandwidth, message size, latency, noise sensitivity, etc.), differences in network protocols at any layer (e.g., hardware type, message frame requirements, addressing scheme, type of acknowledgment, requirements, or functions, cast availability, e.g., unicast, multicast, and / or broadcast), network standard types (e.g., Controller Area Network (CAN), Media Oriented System Transport (MOST) network, Local Interconnect Network (LIN), FlexRay network, Time-Triggered Protocol (TTP) network, Low-Voltage Differential Signaling (LVDS) network, Audio Video Bridging (AVB)-compliant network, any one or more customized versions of these, and / or any one or more proprietary versions of these), considering any differences in the network. An exemplary network zone includes an electrical signal zone (e.g., when the corresponding network interface circuit interprets an electrical signal value as a communication and / or provides a certain electrical value indicating an endpoint of the electrical signal zone, e.g., a sensed parameter value, a diagnostic value, etc., to a sensor, and / or moves to a selected position and / or applies a selected force in response to a certain electrical value, and / or an actuator provides feedback information and / or diagnostic information on the electrical signal zone in addition to or instead of this, a network). The electrical signal for the electrical signal zone can be of any type including at least a voltage value, a frequency value, a current value, and / or a configured Pulse Width Modulation (PWM) value, e.g., duty cycle, amplitude, selective period, etc.).

[0072] The exemplary system 1600 further includes a policy manager circuit 1602 that interprets a policy 1606 including a network regulation description (not shown), and a configuration circuit 1604 including at least one network interface circuit (e.g., a first network interface circuit 1608 corresponding to a first network zone 1612 and / or a second network interface circuit 1610 corresponding to a second network zone 1614) in response to the policy 1606. For example, the policy 1606 can be provided by an external device 1618 and / or can be stored in advance (e.g., during manufacturing, assembly, and / or previous updates from the external device 1618), in which case the policy 1606 includes a network regulation description having a display of devices on the vehicle 102 selected with respect to functions for utilizing the network zones 1612, 1614, communicating between the zones, and / or communicating with the external device 1618.

[0073] The exemplary system 1600 includes a first network interface circuit 1608 provided as part of the CEG when the first network zone 1612 is a CAN bus network, and a second network interface circuit 1610 provided as part of the CES when the second network zone 1614 is provided as an Ethernet network. In this example, the first network interface circuit 1608 provides communications selected from the first network zone 1612 to the second network interface circuit 1610 at a selected port of the Ethernet network, and / or receives communications selected from the second network zone 1614 at a selected port of the Ethernet network, thereby enabling inter-network communication between the first network zone 1612 and the second network zone 1614. In this example, communications from the first network zone 1612 to the external device 1618 can be provided through the second network zone 1614 (e.g., if the external device 1618 is coupled to the second network zone 1614 and / or wirelessly connected to the vehicle 102), or provided directly to the external device 1618 (e.g., if the external device 1618 is directly coupled to the first network zone 1612 or the CAN bus).

[0074] The exemplary system 1600 includes the first network zone 1612 as a virtual local area network (VLAN) that is logically separated from the second network zone 1614 but disposed on hardware that is at least partially shared with the second network zone 1614. In this example, the first network interface circuit 1608 and the second network interface circuit 1610 can be operated as elements of a network switch or router to control communication between the endpoints of the first network zone 1612 and the endpoints of the second network zone 1614 in response to the policy 1606.

[0075] On vehicle 102, devices that are adjusted by policies include, but are not limited to, one or more of the end points of network zones, flows related to communication devices (e.g., endpoints or applications), and applications related to communication devices (e.g., endpoints). For example, the end point of the first network zone 1612 (e.g., a backup camera on vehicle 102) can request or conduct communication on the vehicle's network, but can be associated with more than one application or flow (e.g., associated with a first flow related to the reverse movement of the vehicle under a first operating condition, and associated with a second flow related to the security operation of the vehicle under a second operating condition). Thus, the communication of the backup camera on vehicle 102 can have different adjustment parameters depending on the flow associated with the operation during movement. In certain embodiments, the end point is associated with more than one application or flow and is adjusted according to the one with the highest priority among the relevant applications or flows (e.g., to reduce communication requirements such as determining the application or flow that requests immediate communication to be adjusted, and / or to shorten the processing time for determining which application or flow requests immediate communication). In certain embodiments, the end point is associated with more than one application or flow and is adjusted according to the priority of the application or flow that requests immediate communication.

[0076] In this specification, a device can be referred to as a local communication device that is on vehicle 102 and is adjusted by a policy. The local communication device includes, but is not limited to, an endpoint of a network zone, an application, a flow, a sensor device, a service group, a vehicle function (e.g., power management, in-vehicle comfort, traction control, etc.), and / or a vehicle controller (e.g., an engine controller, a transmission controller, an anti-lock braking system (ABS) controller, an advanced driver assistance system (ADAS) controller, etc.). A given component, such as an endpoint of a network zone, can be made the first local communication device during one operating condition depending on, for example, vehicle operating conditions (e.g., stopped, propulsion operation, operating while parked, etc.), and the second local communication device during another operating condition, and / or can be made the first local communication device for a first purpose (e.g., the brake controller performs an active traction control operation), and the second local communication device for a second purpose (e.g., the brake controller provides data stored for diagnostic operation). Further, it can also be seen that the distribution of communication devices among applications, flows, controllers, vehicle functions, etc. depends on design choices made by, for example, the system's programming plan, the manufacturer, or other entities having control over the design and / or configuration of the system. For example, traction control can be provided by an integrated vehicle controller for a given system (e.g., capable of processing traction control as a vehicle controller for network adjustment purposes), by a distributed controller for another system (e.g., capable of processing traction control as a vehicle function for network adjustment purposes), and / or can be processed as a logically grouped set of operations for another system (e.g., can have any hardware programming including the above-described programming, and is capable of processing traction control as an application or flow for network adjustment purposes). A person skilled in the art having the benefit of the disclosure of the present invention and having information normally available when considering a particular system can readily determine the programming scheme and network adjustment for the local communication devices of the system.The scheduling scheme for the local communication device includes inclusion and / or association of the endpoints of the network zones and / or communication with one or more of the specific endpoints, vehicle controllers, vehicle functions, applications, and / or flows of the system (including source or destination communication with the endpoints).

[0077] Certain considerations for determining the scheduling scheme include the number, type, function, and interconnection bandwidth of the network zones of the system, the available size and / or granularity for the system's policy, the processing power available for implementing the system's policy, the number and distribution of vehicle controllers and other controllers across the system, the expected changes over time of the system (e.g., availability for reconfiguring, remanufacturing, and / or specification changes of the vehicle, expected changes in the coming model years for the vehicle, and / or the available or expected consumer and / or third-party vehicle customization levels), the number and distribution of sensors and / or actuators across the system, and the connectivity of sensors and / or actuators to the network zones (e.g., aggregation to the controller and / or aggregation using smart sensors / actuators having the function of directly interfacing with the network zone), the presence, number, and distribution of multi-purpose communication elements on the system (e.g., sensors, actuators, controllers, and / or data values that provide information to multiple vehicle functions, flows, and / or applications), the presence, number, and distribution of multi-purpose data elements on the system (e.g., sensors, actuators, controllers, and / or data values that provide redundant performance to support a given vehicle function, flow, and / or application), and / or the expected utilization of network aspects (e.g., communication on the network zone, data speed of external communication and / or aggregation of communicated data, inter-network communication, etc.) related to the relevant capacity (e.g., bandwidth of the network zone, bandwidth of external communication, data limitations of external communication, inter-network communication, etc.), but are not limited thereto.

[0078] The exemplary policy management circuit 1602 interprets the policy 1606 by performing operations such as receiving a policy communication 1616 from an external device 1618 and storing the policy 1606 (e.g., storing in a memory location accessible to the policy management circuit 1602 and / or dispersing through several memory locations), and / or updating the stored policy 1606. In certain embodiments, the policy management circuit 1602 updates, for example, the number of configuration files utilized by the interface circuits 1608, 1610, adjusts the high-level description of the policy communication 1616 into commands executable by the network adjustment aspect of the system 1600 (e.g., limiting external communication data to 32 GB per month), adjusts the reference value of the policy communication 1616 (e.g., associating the local address value of an endpoint described in the policy communication 1616 when the endpoint is moved without notification to the external device 1618 and / or when specific addressing information of the local device is abstracted from the external device 1618), and configures the policy 1606 for utilization by the network adjustment aspect of the system 1600 by associating system-specific designations (e.g., the name or ID of a local parameter value, the name or ID of a flow, the name or ID of an application, etc.) with the elements of the policy description 1620.

[0079] The exemplary system 1600 includes an external device 1618 communicatively coupled to the policy management circuit 1602 through at least one of a first network zone 1612 or a second network zone 1614, for example, using a CAN bus port, an OBD port, an Ethernet port, a proprietary port, or other direct connection to the network zone. The exemplary system 1600 includes an external device 1618 communicatively coupled to the policy management circuit 1602 by a wireless connection such as a WiFi connection, a cellular connection, and / or a Bluetooth connection.

[0080] The exemplary system 1600 includes a policy management circuit 1602 that verifies a policy 1606 communicated by a policy communication 1616 before storing and / or updating it. For example, the policy management circuit 1602 can require authentication of an external device 1618 and / or determination of permissions associated with the external device 1618 before making changes to the policy 1606. In certain embodiments, the policy management circuit 1602 can determine permissions associated with the external device 1618, the entity using the external device 1618, the application or flow using the external device 1618, etc. before making changes to the policy 1606. In certain embodiments, the policy management circuit 1602 can reject the policy communication 1616 if the policy 1606 included in the policy communication 1616 is greater than the permissions associated with the external device 1618 and / or if the policy 1606 cannot be implemented (e.g., the stage of implementing the policy 1606 is considered greater than the functions of the system 1600 such as network zone bandwidth, external communication restrictions, memory storage restrictions, etc.). In certain embodiments, the policy management circuit 1602 can partially implement the policy communication 1616 if the policy 1606 included in the policy communication is greater than the permissions associated with the external device 1618 and / or if the policy 1606 cannot be fully implemented. For example, the policy management circuit 1602 can implement the approved portion of the policy communication 1616 and / or the portion of the policy communication 1616 that has functions implemented by the system 1600.In certain embodiments, the policy management circuit 1602 may implement a portion of the policy communication 1616 according to priorities such as the associated endpoint, flow, application, vehicle function of the policy communication 1616 (e.g., implement higher priority aspects until reaching a limit) if, for example, the complete implementation is larger than the system's capabilities, and / or maximize the implementation value of the policy communication 1616 (e.g., associate a value according to the described priorities, importance, advantages associated with a given aspect for each aspect, such that, for example, satisfying a group of multiple policy aspects of slightly lower priority is considered to be greater than satisfying only a single higher priority policy aspect).

[0081] The exemplary policy management circuit 1602 provides a policy notification 1620 to an external device 1618 in response to verifying a policy 1606. The exemplary policy notification 1620 includes confirmation that the policy 1606 has been updated and / or stored according to the policy communication 1616. The exemplary policy notification 1620 includes a notification that the policy 1606 has not been implemented (e.g., if the external device 1618 does not have authorization to implement the policy communication 1616). The exemplary policy notification 1620 includes the reason for the rejection of the policy communication 1616 (e.g., lack of authorization, lack of functionality, etc.). The exemplary policy notification 1620 includes one or more aspects of a partial implementation of the policy communication 1616, e.g., a description of which aspects of the policy communication 1616 have been implemented, rejected, and / or the reason for the partial implementation. In certain embodiments, the policy management circuit 1602 can provide the policy notification 1620 to a separate external device (not shown) instead of, and / or in addition to, the policy notification 1620 to the first external device 1618. In certain embodiments, the policy notification 1620 to the separate external device can have the same information or separate information. For example, the policy management circuit 1602 can provide a simple policy notification 1620 (e.g., rejection of the policy communication 1616) to the requesting external device 1618 and a more detailed policy notification 1620 (e.g., authorization that prevented the implementation of the policy communication 1616, capacity that prevented the implementation of the policy communication 1616, and / or details regarding the partial implementation of the policy communication 1616) to a separate external device. In certain embodiments, the policy management circuit 1602 can provide a more detailed policy communication 1616 to the requesting external device 1618 and a simpler policy communication 1616 to a separate external device.

[0082] In certain embodiments, the policy notification 1620 can include providing, to a user interface of an external device (not shown), a prompt that enables, for example, an authorized external device, user, entity, etc. to give permission to allow an update to the policy 1606 in response to the policy communication 1616. In yet another example, the prompt to the user interface of the external device can include a prompt to one or more of a vehicle owner, a vehicle driver, a vehicle manufacturer, an administrator related to the vehicle (e.g., a network administrator, a fleet owner, a fleet service operator, a compliance officer related to the vehicle, etc.).

[0083] Without being limited to any other aspect of the disclosure of the present invention, an exemplary aspect of Policy 1606 includes data collection parameters (e.g., data available for at least one network zone of a vehicle, e.g., any sensor, actuator, controller, and / or endpoint that is at least selectively connectable to and / or communicating with the endpoint of the network zone), data collection permission values (e.g., sampling rate or communication speed, permission to provide data values to the network zone, permission to request data values from the network zone, resolution values for data, delay permission for data, storage permission for data, e.g., authorized data storage amount, data invalidation criteria, and handling parameters for old data, e.g., compression operations and / or summarization operations performed on old data and / or when the storage amount permitted due to lack of functionality to communicate stored data externally is limited or when competing storage priorities interfere with the available storage capacity plan), service subscription permission values (e.g., planned authorization to publish to some local communication devices, external applications, etc. but not to others, authorization to publish service availability, and / or authorization to publish details of available services such as provided data parameters, available actuators), service periodic reception permission values (e.g., published services visible to related local communication devices, details of services available to related local communication devices, and / or permission to periodically receive services for related local communication devices), and / or external communication permission values (e.g., data speed, related parameters, possible external addresses, possible APNs, aggregated data communication permission, etc.). Policy 1606 includes any one or more of the above-described ones related to local communication devices (e.g., endpoints, controllers, vehicle functions, flows, applications, etc.) and external devices (e.g., specific devices or device categories, entities, and / or applications).In certain embodiments, a given flow, application, or vehicle function can include aspects related to a local communication device and other aspects related to an external device (e.g., a route prediction application that utilizes the local communication device in combination with an external application such as a cloud-based application or a web-based application).

[0084] Referring to FIG. 17, an exemplary system 1700 for providing vehicle external communication control consistent with embodiments of the present disclosure is shown. The exemplary system includes a vehicle 102 having a first network zone 1612 and a second network zone 1614, where the second network zone 1614 is of a different type than the first network zone 1612. The exemplary system 1700 includes a CND 108 inserted between the first network zone 1612 and the second network zone 1614. The CND 108 inserted between the network zones 1612, 1614 includes a physical intervention (e.g., communication between the network zones 1612, 1614 passes through a device such as the CND 108 and / or a CEG, CES, or other network interface circuit controlled thereby), and / or a logical intervention (e.g., when communication between the network zones 1612, 1614 passes through a device controlled by the CND 108, and / or when the CND 108 adjusts communication between the network zones 1612, 1614, such as passing data values, configuring data values, data speed, upsampling and / or downsampling of data, encapsulation operations, frame inclusion, and / or processing of passing communication).

[0085] The exemplary system 1700 further includes a policy management circuit 1602 that interprets a policy 1606 including an active diagnostic description 1705, and a diagnostic execution circuit 1702 that provides a diagnostic command value 1712 responsive to the active diagnostic description 1705 to endpoints of network zones 1612, 1614. The exemplary system 1700 includes an endpoint (endpoint 1708) of a first network zone 1612 and an endpoint (endpoint 1710) of a second network zone 1614. In the exemplary system 1700, the endpoints 1708, 1710 include devices responsive to the diagnostic command value 1712. Exemplary and non-limiting diagnostic command values 1712 include commands to collect one or more data values, commands to actuate an actuator, and / or commands to actuate a vehicle function (e.g., provide engine speed, power level, or execute a higher level function such as a regeneration mode, a planned test operation, etc.). The exemplary system 1700 enables successful execution of an active diagnostic test requested by an external device, regardless of a dispersion of endpoints 1708, 1710 across multiple vehicle networks, including cases where the endpoints move between networks and / or where a given diagnostic command value 1712 is utilized to perform an active diagnostic test across various vehicle networks having various network configurations and various dispersions of endpoints 1708, 1710.

[0086] Referring to FIG. 18, an exemplary endpoint 1708 includes a device control circuit 1802 that interprets a diagnostic command value 1712 and provides an actuator command value 1804 in response to the diagnostic command value 1712. The exemplary endpoint 1708 includes or is connected to an actuator 1806 that responds to the actuator command value 1804. For example, the diagnostic command value 1712 can include commands such as "lock the driver's door", "close the exhaust gas recirculation valve", "raise the motor temperature to 80 ° C", and the abstraction between the diagnostic command value 1712 and the response of the actuator 1806 enables the acquisition of the diagnostic command value 1712. In addition to or instead of this, the diagnostic command value 1712 can be associated with complex operations or continuous operations such as an entire test sequence, and thus can be associated with many endpoints 1708, 1710, and / or a plurality of actuators 1806 across the system 1700 can be involved by a single diagnostic command value 1712.

[0087] The exemplary system 1700 further includes a diagnostic execution circuit 1702 that determines whether vehicle operating conditions 1720 are consistent with diagnostic command value 1712 before providing diagnostic command value 1712 to endpoints 1708, 1710. For example, diagnostic command value 1712 can include a diagnostic test that adjusts the torque delivery of the vehicle's prime mover, and the relevant vehicle operating conditions 1720 can include parameters such as ensuring that the vehicle's gear is in neutral, ensuring that the vehicle is not in the prime power mode, and / or ensuring that the vehicle is in a selected test mode. In certain embodiments, the vehicle operating conditions 1720 for a given diagnostic command value 1712 can be indicated within the active diagnostic description 1705, enabling active control of vehicle operating conditions 1720 for test execution (e.g., target temperature, specific conditions to be diagnosed, such as vehicle start, high altitude operation, etc.), and / or conditions outside the test (e.g., impact on driver or inspection and repair personnel safety, fuel consumption, or emissions, network communication speed, processing requirements, and / or memory storage amount, etc.). In certain embodiments, the vehicle operating conditions 1720 for a given diagnostic command value 1712 can be enforced by another flow, application, vehicle function, etc. related to the vehicle (e.g., the torque command cannot be adjusted separately from the driver command unless the specified vehicle state 1720 exists). The exemplary system 1700 includes a policy 1606 that includes diagnostic execution conditions 1706, and the diagnostic execution circuit 1702 further determines whether vehicle operating conditions 1720 are consistent with diagnostic command value 1712 in response to diagnostic execution conditions 1706.

[0088] The exemplary system 1700 further performs a diagnostic data collection operation in response to the active diagnostic description 1705, and includes a diagnostic execution circuit 1702 that stores a diagnostic data set 1714 in response to the diagnostic data collection operation. For example, the active diagnostic description 1705 can include some data parameters to be collected, the status of the monitored vehicle, and / or determined parameter thresholds (e.g., a temperature greater than the threshold). The stored diagnostic data set 1714 can include the collected data, the status of the vehicle determined based thereon, or a combination thereof. The collected data can be from endpoints 1708, 1710 in response to the diagnostic command value 1712 (e.g., confirmation that the actuator responded to the command, diagnostic data or fault codes related to the responding actuator), or from endpoints 1708, 1710 other than those in response to the command (e.g., observation of temperature, pressure, speed values not directly related to the operating endpoints 1708, 1710, status confirmation, etc.).

[0089] The exemplary diagnostic execution circuit 1702 performs a processing operation on the data collected in the diagnostic data collection operation and stores a diagnostic data set 1714 in response to the processing operation. For example, the stored diagnostic data set 1714 can include situation information, virtual sensor information, negative information (e.g., storing only data related to the operation when the threshold is not met), values obtained by upsampling and / or downsampling the collected data, and / or any other processing operation shown throughout the disclosure of the present invention. Exemplary and non-limiting processing operations on the collected data or a portion thereof include compressing the collected data, summarizing the collected data, operating a virtual sensor using the collected data, determining vehicle operating conditions in response to the collected data, determining a diagnostic data set in response to the determination of vehicle operating parameters, performing an upsampling operation on the collected data, and / or performing a downsampling operation on the collected data.

[0090] The exemplary diagnostic execution circuit 1702 further communicates a diagnostic data set 1714 responsive to a diagnostic data collection operation to an external device (e.g., 1618). The external device that receives the diagnostic data set 1714 can be the same or a different external device as the external device that supplies the active diagnostic description 1705. The exemplary diagnostic execution circuit 1702 further processes the collected data before communicating it to the external device, and this processing can include an initial process that determines the diagnostic data set 1714 to be stored, and / or yet another processing operation on the stored diagnostic data set 1714 before communicating it to the external device. For example, the diagnostic execution circuit 1702 can store the diagnostic data set 1714 and transmit a portion of the diagnostic data set 1714 (e.g., selected parameters, active diagnostic results, etc.) to the external device. Next, the exemplary diagnostic execution circuit 1702 performs selected operations such as a stage of further processing (e.g., for reducing external data communication in response to data selected for transmission by the external device) before communicating the diagnostic data set 1714 to the external device, and / or communicates the diagnostic data set 1714 to the external device (e.g., in response to the availability of external communication such as a WiFi connection, a connected external device, etc., and / or as required from the external device for all of the diagnostic data set 1714), and / or communicates an additional selected portion of the diagnostic data set 1714 (e.g., data requested by the external device), and / or holds the diagnostic data set 1714 and / or a further processed form of the diagnostic data set 1714 stored over a selected period, and / or deletes the diagnostic data set 1714 after the diagnostic execution operation (e.g., in accordance with the results of an active diagnostic test and / or in accordance with a request from the external device).The operation of system 1700 can enable active diagnostic operations by external devices (e.g., service tools, service applications, cloud-based applications, fleet service computer devices, and / or third-party applications) involved in endpoints on the vehicle over a hybrid network, can support multiple configurations of the vehicle without the need for knowledge of the location and / or composition of the endpoints on the vehicle, and / or can enable diagnostic operations that support changes in the vehicle's configuration. In addition to or in place of this, the operation of system 1700 can enable planned data transmission including reduction of transmitted data while acquiring a powerful active diagnostic function, and can further enable planned consumption of resources for processing, memory, and inter-network communication on the vehicle while acquiring this powerful active diagnostic function.

[0091] Exemplary system 1700 includes a diagnostic verification circuit 1704 that determines a diagnostic confirmation value 1716 based on the response of an actuator to a diagnostic command value 1712 (e.g., checks whether the actuator performed the commanded function and / or whether the vehicle performed an active diagnosis according to the active diagnostic description 1705 across a group of actuators). Exemplary diagnostic verification circuit 1704 stores the diagnostic confirmation value 1716 (e.g., as part of the diagnostic data set 1714) and / or communicates the diagnostic confirmation value 1716 to an external device. In certain embodiments, diagnostic verification circuit 1704 adjusts the storage and / or communication of diagnostic data set 1714 in response to the diagnostic confirmation value 1716, e.g., to ensure that the diagnostic data set 1714 is relevant to the performance of an active diagnosis. In certain embodiments, diagnostic execution circuit 1702 stores all or a portion of diagnostic data set 1714 as a data rolling buffer and can save a selected portion of diagnostic data set 1714 in response to diagnostic verification circuit 1704 providing the diagnostic confirmation value 1716 (e.g., when the diagnosis has a time value or actuator position as part of the diagnostic execution and enables the diagnosis to be fully determined when a timer or other cumulative state is complete).

[0092] The exemplary active diagnostic description 1705 includes a target device description 1718 (e.g., a fueling actuator, an engine controller, a door actuator, a mirror position adjustment actuator, etc.), and the target device description 1718 does not identify on which of the network zones 1612, 1614 its corresponding endpoint is located. The exemplary system includes a configuration circuit 1604 that determines a network address value 1722 (e.g., a port number for an Ethernet network, a message ID for a CAN network, etc.) for an endpoint that responds to the target device description 1718, and the diagnostic execution circuit 1702 further provides a diagnostic command value 1712 to the endpoint that responds to the network address value 1722. For example, the target device description 1718 can include a standardized description regarding the endpoint (e.g., engine speed, ambient temperature, passenger seat occupancy sensor, etc.), and the configuration circuit 1604 is accessible to a configuration table that associates the standardized description with a local network address for the component that intends the standardized description. In addition to or instead of this, the target device description 1718 can have a description that matches a baseline product (e.g., the 2020 LX version of a given vehicle), a description that matches the original version of the vehicle (e.g., when the vehicle was configured after manufacture), and / or a description that matches an earlier version of the vehicle (e.g., when the vehicle includes a certain date point in time). In certain embodiments, the configuration table or other information utilized by the configuration circuit 1604 to determine the network address value 1722 can be one or more configuration files maintained by the network interface circuit, a configuration file maintained by the policy management circuit, a configuration file maintained by the CND, and / or a configuration file maintained as part of the policy 1606.

[0093] The exemplary active diagnosis description 1705 includes a target device description 1718 (e.g., a fueling actuator, an engine controller, a door actuator, a mirror position adjustment actuator, etc.) that identifies that the endpoint is on one network zone (e.g., the first network zone 1612), and the configuration circuit 1604 determines, in response to the target device description 1718, that this endpoint is on another network zone (e.g., the second network zone 1614). For example, the configuration circuit 1604 can determine that the target device description 1718 indicates a wrong device or a non - existent device, and / or further determine that an external device is using a different and / or standardized configuration file than the previous one to provide the target device description 1718. The configuration circuit 1604 uses the local configuration file to determine the appropriate network address value and / or network zone for the endpoint specified by the target device description 1718. In certain embodiments, the configuration circuit 1604 uses other information from the target device description 1718, such as parameter names, intended functions, etc., to determine the appropriate network address value and / or network zone for this endpoint. Similarly, the configuration circuit 1604 can correct the target device description 1718 that indicates an incorrect address, such as another address on the first network zone if the correct address is an address on the first network zone, in addition to an incorrect network zone.

[0094] The operation of the constituent circuit 1604 enables the simplification of the active diagnosis description (e.g., an external device does not require system-unique information related to the location of the end point and the distribution of the network), the adaptation of diagnostic execution when the end point of the vehicle and / or the local communication device is moved and / or upgraded, and / or enables an abstraction layer between the external device and the vehicle configuration. Simplification and / or abstraction of the active diagnosis definition from the vehicle network configuration enables cost reduction in the development and product launch of active diagnosis, and the expansion of the user base demanding active diagnosis development (e.g., with enhanced protection of confidential information such as vehicle configuration information and / or data partitioning), thereby improving the overall diagnostic function, improving the usage experience of the vehicle driver, and enhancing competition and implicit competition regarding the development and implementation of active diagnosis.

[0095] Referring to FIG. 19, an exemplary system 1900 includes a vehicle 102 having a first legacy network zone 1902 and a second high-capability network zone 1904. For example, the first legacy network zone 1902 can be a first network type such as a CAN bus, and the second high-capability network zone 1904 can be a second network type such as an Ethernet network. In certain embodiments, the second high-capability network zone 1904 can be of the same type as the first legacy network zone 1902, but can be a higher-capability version such as a high-speed CAN bus, a faster Ethernet network, etc. In certain embodiments, a system 1900 as shown in FIG. 19 can exist when the vehicle migrates to an upgraded network type, e.g., during the transition over several vehicle model years, when new components utilizing a higher-capability network are added to the vehicle, and similar times.

[0096] The exemplary system 1900 includes a CND 108 inserted between a first legacy network zone 1902 and a second high - performance network zone 1904. The CND 108 includes a policy management circuit 1602 that interprets a policy 1606 including an external communication value 1906, and an external communication control circuit 1908 that adjusts communication between an external device 1618 and the endpoints of the first legacy network zone 1902 and / or the endpoints of the second high - performance network zone 1904 in response to the external communication value 1906. For example, to reduce traffic generated by communication to and from the external device 1618 on the first legacy network zone 1902, and / or due to the protection requirements of the endpoints on the first legacy network zone 1902 (e.g., when vehicle control and / or proprietary information is maintained on the first legacy network zone 1902 and / or when the security protocol associated with the first legacy network zone 1902 is more severely restricted than those available in the second high - performance network zone 1904), the external communication between the endpoints of the first legacy network zone 1902 can be restricted. In another example, devices that may have been recently added to the vehicle (and thus have no long known usage history, security pre - reviews, and / or vehicle operation impact data), and / or devices added by entities, which are not as tightly controlled as the providers of devices on the first legacy network zone 1902 (e.g., devices such as entertainment providers that may be provided by third parties and are involved in recently developed vehicle functions and / or not involved in core vehicle functions). Due to potentially numerous devices on the second high - performance network zone 1904, the external communication between the endpoints of the second high - performance network zone 1904 can be restricted to reduce external transmissions from the vehicle (e.g., those that use a specific data provider via the vehicle's transceiver) (e.g., when the higher - function devices on the second high - performance network zone 1904 can have functions that generate high data speeds).The reasons presented regarding restricting external traffic between endpoints on various networks and external devices are non-limiting and are presented for illustrative purposes. However, the external communication control circuit 1908 can adjust communication between an endpoint in any network zone and any external device for any reason.

[0097] The exemplary system 1900 includes active diagnostic descriptions, such as diagnostic operations and / or data collection performed as diagnostic operations, commands to any endpoint on any network zone of the vehicle, data collected from these endpoints, and / or an external communication value 1906 that can include communication with these endpoints. The exemplary system 1900 includes active test descriptions, such as test operations (e.g., testing of any endpoint, actuator, sensor, flow, application, vehicle function, and / or vehicle controller on the vehicle), commands to any endpoint on any network zone of the vehicle, data collected from these endpoints, and / or an external communication value 1906 that can include communication with these endpoints. The exemplary system 1900 includes an external communication value 1906 that includes data request values (e.g., data parameter collection from any endpoint and / or including processing of data parameters) and / or vehicle command values (e.g., commands to any actuator, display, controller, etc. attached to any endpoint). Exemplary and non-limiting external devices 1618 include service tools, manufacturer tools, seller tools, and / or cloud-based tools.

[0098] The exemplary external communication value 1906 includes a target device description that includes identification information of a target endpoint (e.g., network zone, local address, sensor name, actuator name, data parameter name, etc.), and the external communication control circuit 1908 determines that the endpoint has a configuration different from the identification information indicated within the target device description (e.g., different network zone, local address, sensor name, actuator name, data parameter name, etc.). In certain embodiments, the external communication control circuit 1908 can include or utilize a configuration circuit 1604 (see, e.g., FIGS. 16, 17, and related descriptions) for determining appropriate identification information for the target endpoint. The exemplary external communication value 1906 does not include identification information of the target endpoint, and the external communication control circuit 1908 provides appropriate identification information for the target endpoint based on the external communication value 1906 (see also FIGS. 16, 17, and related descriptions including the operation of the configuration circuit 1604). It can be seen that the operation of the system 1900 enables the external device 1618 to operate across several vehicle configurations without having specific knowledge of the location of the endpoint, parameter name, local address, etc. for performing active diagnosis, testing, and data collection. Vehicle configurations can represent changes to the vehicle after inspection and repair, replacement of components (e.g., endpoints), changes to the vehicle after upgrading executable instructions stored on a component and / or computer-readable medium, changes over multiple model years, and / or changes to the vehicle due to campaigns, upgrades, and / or remanufacturing.

[0099] Referring to FIG. 20, an exemplary apparatus 2000 is shown for providing a network external view of one or more networks of a vehicle having a hybrid network. The exemplary apparatus 2000 can be used in combination with any of the vehicles described throughout the disclosure of the present invention, and multiple aspects of the apparatus 2000 can be arranged on the vehicle, on an external device that at least selectively communicates with the vehicle, on a cloud server, and / or on a web application.

[0100] The exemplary apparatus 2000 includes a vehicle communication circuit 2002 that interprets vehicle communication data 2016, which can be data collected from the vehicle and / or data provided to the vehicle. Further, the exemplary apparatus 2000 includes a visualization circuit 2004 that generates visualization data 2018 in response to the vehicle communication data 2016. The exemplary visualization data 2018 includes a first network identifier (e.g., a network zone, an endpoint, or other network identifier for the corresponding data) and a second network identifier. The exemplary visualization data 2018 can include network identifiers that support each of at least two distinct network zones of the vehicle and / or each of at least two distinct endpoints of the vehicle. The exemplary network identifiers include Ethernet-based protocols and / or CAN-based protocols. Another exemplary network identifier includes one or more of cellular-based protocols, WiFi-based protocols, and / or Bluetooth-based protocols.

[0101] The exemplary device 2000 further includes a display interface circuit 2006 that transmits visualization data 2018, provides visualization data 2022 stored in the electronic display 2012, and / or provides visualization data 2018. The transmission of the visualization data 2018 can include any one or more operations selected from operations such as transmitting the visualization data 2018 from the vehicle to the tool, transmitting the visualization data 2018 from the vehicle to the cloud server, transmitting the visualization data 2018 from the vehicle to a display device (e.g., the electronic display 2012, e.g., a vehicle display, a service tool, an external computer device, e.g., a driver device, a service device, a manufacturer device, a fleet owner device or a service device, a vehicle communication manager device, and / or a third - party device, etc.), transmitting the visualization data 2018 from the cloud server to the tool, transmitting the visualization data 2018 from the cloud server to the display device, and / or transmitting the visualization data 2018 from the first cloud server to the second cloud server (e.g., enabling distributed storage criteria between cloud servers including data anonymization, data aggregation, and partitioning of data aspects for the stored visualization data 2022). In certain embodiments, the transmission of the visualization data 2018 can include transmitting the visualization data 2018 to on - vehicle storage (e.g., dedicated memory space available for the visualization data 2022 stored for later access, access requests, and / or later transmission to off - vehicle locations), and / or storage coupled thereto (e.g., a USB device coupled to a vehicle, a mobile device such as a driver's mobile phone, and / or a computer device performing short - range wireless communication such as a WiFi connection or a Bluetooth connection).In addition to or instead of this, the transmission of the visualization data 2018 can include any one or more operations selected from operations such as storing the visualization data 2018 on the vehicle's shared storage, storing the visualization data 2018 on the vehicle's shared storage and selectively transmitting the stored visualization data 2022 to an external device, transmitting the visualization data 2018 to a secure cloud storage, and / or transmitting the visualization data 2018 to a secure cloud storage and providing selected access to the stored visualization data 2022 to a monitoring tool, an external application, a service tool, and / or a user device.

[0102] The exemplary device 2000 includes an electronic display 2012 that interprets and displays the visualization data 2018. The exemplary electronic display 2012 accesses the stored visualization data 2022 and displays at least a portion thereof and / or processed visualization elements determined from the visualization data 2018 and / or the stored visualization data 2022. The exemplary visualization data 2018 includes topology data (e.g., depicting a network and / or selective endpoints connected to each of them) corresponding to the network topology of the first network and / or the second network. The topology data can include its visual presentation, a table list, or other visualization.

[0103] The exemplary visualization circuit 2004 is further structured to include within the visualization data 2018 a portion of the metadata of the vehicle communication data 2016. Exemplary and non-limiting metadata of the vehicle communication data 2016 includes data such as source address, destination address, timestamp, operating conditions or status conditions of the vehicle, fault code information, endpoint, flow, application, and / or status parameters related to vehicle functions. In certain further alternative embodiments, the metadata of the vehicle communication data 2016 includes information regarding the trajectory of the vehicle communication data 2016 through the vehicle network, for example, frame data related to the original communication (e.g., frame data from the communication on the first network 2008 when the communication is encapsulated and passed from the second network 2010 to the vehicle communication circuit 2002), processing information related to the payload and / or frame of the vehicle communication data 2016 (e.g., processing operations performed on the payload and / or frame of the communication, such as an explanation of processing operations, upsampling, and / or downsampling that enable inverse calculation of the processing). In certain embodiments, the metadata has predetermined values, for example, a first data value related to a first processing operation (e.g., filtering, resolution change, etc.), a second data value related to a second processing operation, whereby a processing operation (or other operation) can be communicated according to the value (e.g., designated bits) of a selected portion of the vehicle communication data 2016.

[0104] Exemplary apparatus 2000 includes an input monitor circuit 2014 that interprets data filtering values 2020 (e.g., selection of a certain endpoint and / or local communication device, selection of a certain network zone, communication satisfying specified criteria, downsampling description for selected communication, endpoints with associated fault values, communication related to abnormal conditions such as flows, vehicle functions, and / or applications, and / or communication related to endpoints with packet loss, high or low communication speed predictions). Exemplary and non-limiting data filtering values 2020 include network address association, vehicle control device association, vehicle system association, network protocol type, endpoint identifier, data type, application association, and / or flow association. Exemplary and non-limiting data filtering values 2020 include references to systems such as engine systems, steering systems, braking systems, fuel systems, prime mover systems, anti-lock braking systems, traction control systems, and / or drive transfer system control systems. Yet another exemplary and non-limiting data filtering values 2020 include references to systems such as security systems, lighting systems, safety systems, environmental control systems, ADAS, and / or infotainment systems.

[0105] Exemplary apparatus 2000 includes a visualization circuit 2004 that filters vehicle communication data 2016 based at least in part on data filtering values 2020 to generate visualization data 2018. In certain embodiments, data filtering values 2020 can be provided within a policy 1606 communicated from an external device 1618 and / or received through a user interface that operates on an electronic display 2012, an external tool 2014, and / or a user device, e.g., a device of a vehicle owner or driver, a maintenance technician, a manufacturer, a fleet owner, a fleet maintenance technician, a vehicle communication administrator, and / or through interaction with a cloud-based or web-based application.

[0106] Referring to FIG. 22, an exemplary user interface for extracting and filtering vehicle communication data 2016 is shown. The exemplary user interface can be implemented on an external device, a web application, a cloud-based application, an external tool, etc. In the example described in FIG. 22, "Switch 0" corresponds to the first network zone, "Switch 1" corresponds to the second network zone, and allows the user to select the monitored endpoints from each network zone. In this example, the filter options allow narrowing down from the monitored endpoints (e.g., the options on the left) according to filtering criteria that include only, for example, the selected endpoints, flows, applications, etc. (the options on the right). In the example described in FIG. 22, the monitored parameters can be further downsampled (the option at the bottom). In the example described in FIG. 22, the selected mirroring timeout can be set (e.g., when the monitoring is performed using port mirroring). The exemplary user interface described in FIG. 22 shows certain aspects of the network monitoring operation and filtering operation described herein and is not limited to the disclosure of the present invention.

[0107] The exemplary apparatus 2000 includes visualization data 2018 including traffic monitor visualization. For example, the traffic monitor visualization can provide visualization corresponding to an endpoint on one of the first network or the second network (e.g., indicating incoming traffic and / or outgoing traffic to the endpoint), a vehicle system, an application, a flow, a vehicle controller, a vehicle function, a selected one of the first network or the second network, or one or more of the ports of one of the first network or the second network. The exemplary visualization data 2018 includes, for example, port counter visualization that displays message communication traffic corresponding to a port of one of the network zones (physical port or logical port). The exemplary visualization data 2018 includes, for example, visualization of an endpoint data flow monitor that displays message communication traffic corresponding to an endpoint of one of the network zones.

[0108] Referring to FIG. 23, exemplary visualization data 2018 including traffic monitor visualization is shown. The example described in FIG. 23 depicts network traffic (e.g., messages, bits, etc.) related to a first end point 2302 and a second end point 2304. The example described in FIG. 23 is a non-limiting example, and the traffic monitor can be depicted in any manner, for example, according to any grouping such as per network, per port, all traffic related to an application, all traffic related to a flow, all traffic related to a vehicle function, all traffic related to a service group.

[0109] The exemplary apparatus 2000 includes visualization data including a network activity profile provided for one or more of an end point on one of the first network or the second network, a vehicle system, an application, a flow, a vehicle controller, a vehicle function, a selected network zone, and / or a selected port of one of the network zones.

[0110] Referring to FIG. 24, illustrative visualization data 2018 including a network activity profile is shown. The example described in FIG. 24 depicts the network bandwidth utilization for a selected network zone using several utilization plots 2402, 2404, 2406, 2408 each related to an endpoint of the selected network zone. Referring to FIG. 25, illustrative visualization data 2018 including a network activity profile for a selected network zone is shown. The example described in FIG. 24 shows the total activity related to the network zone in the upper section, the network bandwidth utilization related to specific devices (e.g., ISL0, ISL1) in the middle section, and the network bandwidth utilization related to vehicle controllers (e.g., head-up display and head unit) in the lower section. The network bandwidth utilization related to the vehicle controllers further depicts the utilization related to several specific breakout devices (e.g., various cameras in this example). The examples described in FIGS. 24 and 25 are non-limiting, and the network activity profile data can be determined and displayed in any manner and can be grouped and / or subgrouped in any manner by endpoints, flows, applications, vehicle functions, vehicle controllers, etc.

[0111] The exemplary vehicle communication circuit 2002 interprets vehicle communication data 2016 by performing one or more operations such as interpreting vehicle communication data 2016 from a policy 1606 stored on a memory disposed on the vehicle and communicatively coupled to the vehicle communication circuit 2002, receiving vehicle communication data 2016 from a service tool communicatively coupled to the vehicle communication circuit 2002, receiving vehicle communication data 2016 from an application communicatively coupled to the vehicle communication circuit 2002, or receiving vehicle communication data 2016 from a monitoring tool communicatively coupled to the vehicle communication circuit 2002.

[0112] In certain embodiments, the step of extracting vehicle communication data 2016 including messages corresponding to traffic monitors, network activities, and / or endpoints of network zones and / or ports of network zones includes mirroring traffic from a first port of a network zone to a second port of the network zone and monitoring the second port of the network zone to determine vehicle communication data 2016. For example, the first port of the second network zone 2010 can be the endpoint to be monitored corresponding to and in this case, the operation of extracting vehicle communication data 2016 includes mirroring the first port of the second network zone 2010 to the second port of the second network zone 2010 (e.g., when a monitoring tool such as vehicle communication circuit 2022 and / or external tool 2014 is communicatively coupled to the second port), and monitoring the second port of the second network zone 2010 to determine vehicle communication data 2016.

[0113] Referring to FIG. 26, illustrative visualization data 2018 including data flow among selected network participants (e.g., endpoints, flows, applications, vehicle controllers, etc.) is shown. The example described in FIG. 26 shows the data flow between selected endpoints, and in this example, it depicts the data flow associated with "EP1" (an endpoint such as a head unit) and other endpoints (e.g., in this example, ADAS-related components, EP3, EP5, EP10 such as a parking controller). The example described in FIG. 26 enables monitoring of the network to determine whether an expected data flow is occurring, whether an abnormal data flow is occurring, etc. Referring to FIG. 27, illustrative visualization data 2018 showing all network activities (upper part) related to a selected network zone and data path tracing (data paths in the lower part) from a selected endpoint to other endpoints within the system is shown. In this example, for example, a user interface element can be provided that offers selection of the time (shown in the upper part) used for the data path tracing shown in the lower part, selection of a target endpoint (e.g., EP1 on the left), and / or selection of whether to depict transmission, reception, or both. In certain embodiments, the visualization data 2018 can be provided as a user interface that, for example, offers the user to select components and has the associated data flow shown. Visualizations such as those shown in FIGS. 26 and 27 can be seen to be useful for verifying expected operation and diagnosing problems (e.g., diagnosing degradation of component operation, network problems, and / or detecting abnormal operating conditions such as shown by increased communication between components communicating more during certain abnormal operating conditions). In addition to or instead of this, visualizations such as those shown in FIG. 26 can be used to improve network topology design, hardware selection, and / or protocol selection, to aggregate applications, flows, vehicle functions, etc. on a vehicle controller (e.g., to reduce network traffic requirements), and / or to identify potential redundant or unnecessary network communications.

[0114] Referring to FIG. 21, an exemplary local address table 2100 is shown that schematically illustrates configuration information consistent with various embodiments of the disclosure of the present invention. The exemplary local address table 2100 can be part of policy 1606 and / or a configuration file (e.g., accessible in whole or in part by an interface circuit and / or a configuration circuit). The local address table 2100 can be provided as a data structure in a memory location accessible to an interface circuit, a configuration circuit, and / or other implementation components described throughout the disclosure of the present invention. A portion of the local address table 2100 can be provided as a distributed data structure provided as a data structure in a memory location accessible to an implementation component. The exemplary local address table 2100 is shown to provide an embodiment of the type of local address information that can be utilized to implement aspects of the disclosure of the present invention, but the details of the stored information and the organization of the data structure implementing the local address table 2100 can be configured according to the embodiment being implemented. The exemplary local address table 2100 includes an endpoint identifier 2102 that can be a local identifier of an endpoint present in the system. In yet another example, for example, an external device can include a non-local endpoint identifier (not shown) that enables the external device to refer to an endpoint using industry-standard terminology or other selected terminology. The exemplary local address table 2100 includes a network zone identifier 2104 that indicates, for example, which network zone a given endpoint is considered to be part of. Further, the exemplary local address table 2100 includes a local address value 2106 that indicates, for example, how each endpoint is addressed on an appropriate network zone. In certain embodiments, the exemplary local address value 2106 can be a TCP / IP address, a port number, or other identifier. In certain embodiments, the local address value 2106 can include a message identifier, such as a value contained within a message on a logical bus architecture, such as a CAN bus, that indicates the intended destination (or source) of a message to or from an endpoint.The exemplary local address table 2100 can include an external address value 2108 that includes, for example, an address utilized by an external device to identify an endpoint.

[0115] The utilization of the external address value 2108 enables an external device to extract knowledge of local address designations and / or related network zones from the act of utilizing and / or collecting data from the associated endpoint. It can be seen that it is possible to include further different information such as additional external address values within the local address table 2100 (for example, enabling multiple external addresses to be associated with a given endpoint of the system), and / or the inclusion of one or more additional non-local endpoint identifiers (for example, enabling multiple industry standards, proprietary designations, informal designations, etc. to be successfully associated with a given endpoint of the system). In certain embodiments, one or more of the external address 2108 and / or non-local endpoint identifiers can further be associated with a version (for example, interface version, vehicle model description, etc.), and when a change occurs within the vehicle (for example, the endpoint moves between network zones and / or addresses), or when a change occurs outside the vehicle (for example, an external application that is no longer applicable to a particular vehicle of the system is updated for an updated vehicle configuration), the implementing components that use the local address table 2100 are enabled to interpret data commands and / or requests from external applications, algorithms, etc. and properly associate the desired endpoint with these data commands and / or requests.

[0116] The use of the local address table 2100 can further be seen to enable support for multiple addressing to the vehicle's endpoints, for example, providing addressing for both IPv4 and IPv6 to the vehicle's endpoints. In certain embodiments, the local address table 2100 can be extended or alternatively a separate data structure can be maintained to enable association with endpoints and applications, flows, vehicle functions, vehicle controllers, APNs, external data routing paths, or the trajectories of network zones, etc. Thus, a given application such as "route management" can be associated with a plurality of specific endpoints of the vehicle, and these associations can persist from the start to the end of the movement of the endpoints (e.g., from one network zone to another). The use of the local address table 2100 and / or the extended or alternative data structure described herein provides a configuration for priorities, permissions, periodic reception management (both service disclosure and service periodic reception), and / or any other communication coordination activities shown herein.

[0117] In certain embodiments, the local address table 2100 can be extended or, alternatively, a separate data structure can be maintained that enables the addresses of external devices to be configured according to endpoints, applications, flows, vehicle functions, and / or vehicle controllers. For example, access to a given external resource for a given vehicle function (e.g., a route specification function that accesses an external resource and has a map, traffic report, etc.) can be permitted, and the associated external address for providing access to the external resource is associated with the vehicle function. In this example, it is possible to not permit access to this given external resource for other vehicle functions, and instead, the associated external address is associated with the vehicle function (and / or the association with these other vehicle functions is lost depending on the implementation) such that when these other vehicle functions request access to this external resource, a default address, protected space, null communication, or other selected behavior is implemented. Thus, a first application of a vehicle that requests access to an external resource such as https: / / www.google.com can receive the expected general access to the external IP address corresponding to the Google website, and in this case, a second application of the vehicle that requests access to the same external resource may receive an access denied indication, a default external resource indication (e.g., a cloud-based resource within a protected space indicating that the requested resource is not permitted), or other selected responses from the system. Thus, the local address table 2100 and / or its extended or alternative version can be utilized as a local DNS and / or an external DNS. In certain embodiments, for example, when access to an external resource is requested and the external DNS does not have an address for this resource and the requester (e.g., an endpoint, application, flow, vehicle function, and / or vehicle controller) is denied access to this external resource, it is accessible to an external DNS (e.g., one on a cloud server, from an Internet provider, etc.) that is outside the vehicle and provides an external address.In certain embodiments, the external DNS on the vehicle can be updated based on an address retrieved from an external DNS outside the vehicle.

[0118] Referring to FIG. 28, an exemplary system 2800 is shown that includes a vehicle 102 having a first network zone 1612 and a second network zone 1614, where the first network zone 1612 and the second network zone 1614 are of different types. The example described in FIG. 28 includes a CND 108 inserted between the network zones 1612, 1614. The exemplary CND 108 includes a policy management circuit 1602 that interprets a policy 1606 including network adjustment descriptions, and a configuration circuit 1604 that includes a first network interface circuit 1608 that responds to the network adjustment descriptions, where the first network interface circuit 1608 adjusts communications between an endpoint of the first network zone 1612 and an endpoint of the second network zone 1614. In addition to or instead of this, the configuration circuit 1604 configures a gatekeeper interface circuit 2802 that adjusts communications between an endpoint of at least one of the network zones 1612, 1614 and an external communication portal and / or an external device 1618 in response to the network adjustment descriptions. The exemplary first network interface circuit 1608 includes a CEG, and the first network zone 1612 is not a main network (e.g., the first network zone 1612 is a CAN network and the second network zone 1614 is an Ethernet network), and the first network interface circuit 1608 is communicatively coupled to a port of the second network zone 1614 to transmit and receive communications passed between the network zones 1612, 1614.

[0119] Referring to FIG. 29, the exemplary network adjustment description 2904 includes a data request permission description 2906 that includes data values 2910 for data requesters 2908 (e.g., endpoints each on one of network zones 1612, 1614). The exemplary first network interface circuit 1608 adjusts communications between endpoints of the first network zone 1612 and endpoints of the second network zone 1614 in response to the data request permission description 2906, for example, restricting related data requesters 2908 to authorized data values 2910 and / or preventing related data requesters 2908 from accessing unauthorized data values 2910. In certain embodiments, the first network interface circuit 1608 further adjusts communications between endpoints of the first network zone 1612 (e.g., from a first endpoint to a second endpoint both on the first network zone 1612) in response to the data request permission description 2906.

[0120] The exemplary system 2800 further includes a configuration circuit 1604 that includes a second network interface circuit 1610 in response to a network adjustment description, where the second network interface circuit 1610 adjusts communications between endpoints of the second network zone 1614. Referring again to FIG. 29, the exemplary second network interface circuit 1610 adjusts communications between endpoints of the second network zone 1614 and endpoints of the first network zone 1612 in response to the data request permission description 2906, for example, restricting related data requesters 2908 to authorized data values 2910 and / or preventing related data requesters 2908 from accessing unauthorized data values 2910. In certain embodiments, the second network interface circuit 1610 further adjusts communications between endpoints of the second network zone 1614 (e.g., from a first endpoint to a second endpoint both on the second network zone 1614) in response to the data request permission description 2906.

[0121] The exemplary system 2800 further includes a configuration circuit 1604 including a gatekeeper interface circuit 2802 in response to a network adjustment description 2904, where the gatekeeper interface circuit 2802 coordinates communications between endpoints of both a first network zone 1612 and a second network zone 1614 and an external device 1618. The exemplary external device 1618 can be coupled to the first network zone 1612, the second network zone 1614, or both. In addition to or instead of this, the external device 1618 can be coupled to a transceiver (not shown) of the vehicle 102 that can be a cellular, WiFi, and / or Bluetooth transceiver. In certain embodiments, the transceiver can be communicatively coupled to a port over a network zone, e.g., one of the network zones. In certain embodiments, the first network zone 1612 is a non-primary network zone and the second network zone 1614 is a primary network zone, and the transceiver is communicatively coupled to the second network zone 1614. In yet another exemplary embodiment, the second network zone 1614 is an Ethernet network, and the transceiver is coupled to the second network zone 1614 by communicating with the second network interface circuit 1610 through a port of the CES including the second network interface circuit 1610.

[0122] Exemplary and non-limiting external device 1618 includes one or more of cloud server-based applications, web-based applications, and / or mobile device applications. Referring again to FIG. 29, exemplary data request permission description 2906 includes data access permissions 2914 associated with each of several external communicators 2912. External communicator 2912 includes identified external device 1618, external application, external flow, external entity (e.g., inspector, manufacturer, owner, driver, etc.), external address, and the like. Exemplary and non-limiting data access permissions 2914 include permissions to communicate with specific endpoints, flows, applications, vehicle functions, network zones, vehicle controllers, and the like. In certain embodiments, data access permissions 2914 can be explicitly different for transmission communication and reception communication. For example, a given external communicator 2912 may not have permission to request data from a first endpoint on the vehicle, but the first endpoint on the vehicle may have permission to send data to this given external communicator 2912. Exemplary data request permission description 2906 includes data access permissions associated with one or more of external devices, external communicators, endpoints, flows related to external devices and / or external communicators, vehicle functions related to endpoints, external devices, and / or external communicators, and / or applications related to endpoints, external devices, and / or external communicators. Exemplary and non-limiting data access permissions 2914 include one or more of the ability to request, send, and / or disclose data, the ability to request, send, and / or disclose specific data values, and / or external communication bandwidth limitations (e.g., data speed, aggregated data volume per unit time, and / or sharing of available bandwidth). Exemplary system 2800 further includes a gatekeeper interface circuit 2802 that adjusts communication between endpoints of network zones 1612, 1614 and external device 1618 (and / or external communicator 2912) in response to data request permission description 2906 and / or data access permission 2914.

[0123] Furthermore, the exemplary gatekeeper interface circuit 2802 further performs one or more of the following steps: adjusting in response to a flow associated with the communication with the external device 1618 (and / or the external annunciator 2912) to an adjusted communication (e.g., adjusting the permission based on the priority of the relevant flow, the role of the relevant flow, and / or the current operating conditions, etc.), adjusting in response to the data type related to the adjusted communication (e.g., raising or lowering the priority of a certain data type, restricting a certain data type to a certain communication state such as the availability of high-speed data communication, classifying the data according to criteria such as the age of the data, and adjusting the permission accordingly), adjusting in response to the data service provider related to the adjusted communication (e.g., configuring the data speed, bandwidth, and / or aggregated data value in response to the data service provider related to the data), adjusting in response to the vehicle function related to the adjusted communication (e.g., prioritizing a certain vehicle function), and / or adjusting in response to the connection type of the communicable connection with the external device 1618 (and / or the external annunciator 2912) (e.g., enabling a high communication speed when a high-speed and / or inexpensive data connection is available).

[0124] The exemplary system 2800 receives a policy update that includes a change to the network tuning description 2904 (e.g., from the policy management circuit 1602), and includes a configuration circuit 1604 that updates the configuration of the first network interface circuit 1608, the second network interface circuit 1610, and / or the gatekeeper interface circuit 2802 in response to the change to the network tuning description 2904. In yet another example, the policy management circuit 1602 interprets an authorization associated with the policy update based on, for example, permission from an external device 1618 and / or an external annunciator 2912 that provides the policy update. The exemplary policy management circuit 1602 suppresses the policy update in whole or in part in response to the authorization indicating that the requesting unit (e.g., the external device 1618 and / or the external annunciator 2912) is not authorized to make a change to the network tuning description of the policy update. In certain embodiments, the policy management circuit 1602 can, in addition to or instead of this, provide one or more policy notifications 1620 to the requesting unit, and / or another external device 1618 or external annunciator 2912 in response to suppressing or partially suppressing the policy update (see, e.g., FIG. 16 and related description). Exemplary and non-limiting requesting units include one or more of an entity related to the policy update, an application related to the policy update, a flow related to the policy update, a vehicle function related to the policy update, an identifier of an external device that communicates the policy update, and / or an identifier of an external annunciator related to the policy update.

[0125] Referring again to FIG. 28, the exemplary policy management circuit 1602 interprets a policy 1606 that includes a network usage permission description 3004 (see FIG. 30). The exemplary network usage permission description 3004 includes an external data access description 3006, in which case the configuration circuit 1604 further configures the gatekeeper interface circuit 2802 in response to the external data access description 3006, and the gatekeeper interface circuit 2802 adjusts communication with the external device 1618 in response to the external data access description 3006. The exemplary external data access description 3006 includes, for example, an external access permission 3014 associated with an identified external device 1618, an external application, an external flow, an external entity (such as an inspector, a manufacturer, an owner, a driver, etc.), an external communicator 3012 such as an external address. In certain embodiments, the external communicator 3012 includes one or more local communication devices that request external communication, such as a vehicle flow, an application, a vehicle network zone, an end point of a network zone, etc. For example, the exemplary gatekeeper interface circuit 2802 adjusts external communication based on the flow association of the communicating ones among the endpoints of the first network zone and / or the second network zone (e.g., limits external communication to communication permitted according to the external access permission 3014, and / or permits external communication not excluded by the external access permission 3014). The exemplary gatekeeper interface circuit 2802 adjusts external communication based on the application association of the communication device (such as the external device 1618 and / or the end point), e.g., limits external communication to communication permitted according to the external access permission 3014 and / or permits external communication not excluded by the external access permission 3014.The exemplary gatekeeper interface circuit 2802 adjusts external communications based on the network zone association of the communication device (e.g., the network zone or source zone associated with the endpoint requesting external communication and / or the network zone or destination zone that is the target of the external communication), for example, restricting the external communication to the communication permitted according to the external access permission 3014 and / or permitting the external communication not excluded by the external access permission 3014. In certain embodiments, the first network zone and the second network zone can be separate virtual local area networks of the vehicle and can have separate external access permissions 3014.

[0126] The exemplary policy 1606 includes an external data quantity description (not shown), in which case the configuration circuit 1604 includes a gatekeeper interface circuit 2802 that responds to the external data quantity description. The exemplary external data quantity description includes data restrictions for the application, in which case the gatekeeper interface circuit further adjusts the external communication based on the association between the communicating device and the application. The application can be an application related to vehicle operation (e.g., an application operating on the vehicle and / or an application operating on an external device in an interactive situation communicable with the vehicle) or an application not related to vehicle operation (e.g., an infotainment application, a driver application, web browsing using the vehicle's network zone, a third-party application communicating with the vehicle, etc.). The exemplary external data quantity description includes data restrictions for an endpoint of one of the network zones, and the gatekeeper interface circuit adjusts the communication based on the source endpoint or destination endpoint of the adjusted communication. The exemplary external data quantity description includes data restrictions for the flow, and the gatekeeper interface circuit adjusts the external communication based on the association between the communicating device and the flow.

[0127] Exemplary and non-limiting data restrictions include the amount of communication data related to the selected period (e.g., MB per hour, GB per month, etc.), the amount of communication data related to the selected vehicle operating conditions (e.g., MB per trip, data speed during idling operation, data speed at rated operation, data speed during rapid transient operation, etc.), the amount of communication data corresponding to the data provider for the application, endpoint, and / or flow, the bandwidth allocation of the transceiver used for communication, the bandwidth volume of the transceiver used for communication, the bandwidth allocation of the transceiver channels (e.g., if the transceiver includes more than one channel and the bandwidth allocation is restricted with respect to the channels providing external communication for the application, endpoint, and / or flow), and / or the bandwidth volume of the transceiver channels (e.g., if the transceiver includes more than one channel and the bandwidth volume is restricted with respect to the channels providing external communication for the application, endpoint, and / or flow), including one or more of the above.

[0128] Referring to FIG. 31, exemplary network usage permission description 3004 includes network usage description 3102 for network zone 3104 corresponding to and local communication devices such as endpoints, flows, vehicle functions, and / or applications corresponding toIt includes the communication device description 3106. In this example, the gatekeeper interface circuit 2802 further adjusts external communication based on the network usage description 3102 and the communication device associated with the adjusted communication (e.g., corresponding to the communication device description 3106). The exemplary network usage description 3102 determines the priority 3108 for the communication device to adjust external communication, the related flow 3110, the related vehicle function 3112, the related application 3114, and / or the related state or event 3116 (e.g., a trigger event for implementing an aspect of the policy 1606, a vehicle condition or other state that enables the implementation of an aspect of the policy 1606, and / or a vehicle condition or other state that adjusts or suppresses an aspect of the policy 1606 if it exists). The network usage description 3102 can include one or more of the bandwidth of the network zone 3104 available for use to support external communication, the data speed of the network zone 3104 available for use to support external communication, the bandwidth limit of the network zone 3104 (e.g., these external communications can be suppressed or reduced if the external communication is considered to cause a general overrun), and / or the data speed limit of the network zone 3104 (e.g., these external communications can be suppressed, reduced, or delayed if the external communication is considered to cause a general overrun). In certain embodiments, the priority 3108 or information regarding external communication can be compared with the priority of the in-vehicle communication using the network zone, and the external communication can be prioritized over the in-vehicle communication, and the in-vehicle communication can be suppressed, reduced, or delayed until the external communication is provided. In certain embodiments, service requirements (e.g., QoS parameters) for endpoints, flows, applications, vehicle functions, etc. (e.g., local communication devices) on the vehicle can be considered to determine the external communication permission, and the external communication can be permitted while the service requirements are satisfied.

[0129] Referring to FIG. 32, the exemplary vehicle 102 includes a first network zone 3202 and a second network zone 3204 of a different type. The exemplary vehicle includes a gatekeeper interface circuit 3206 inserted between the first network zone 3202 and the external device 3210 and between the second network zone 3204 and the external device 3210. The gatekeeper interface circuit 3206 can be physically inserted, for example, when communication between zones 3202, 3204 and the external device 3210 passes through the gatekeeper interface circuit 3206, or can be logically inserted, for example, when communication between zones 3202, 3204 and the external device 3210 is regulated by the gatekeeper interface circuit 3206. In the example depicted in FIG. 32, a transceiver 3208 provides a communicative coupling with the external device 3210, and the gatekeeper interface circuit 3206 is inserted between zones 3202, 3204 and the transceiver 3208. Although the transceiver 3208 depicted in FIG. 32 is shown as a single device, a given vehicle can have several transceivers (not shown). The exemplary gatekeeper interface circuit 3206 regulates communication between a selected number of zones 3202, 3204 on the vehicle 102 and the selected transceiver 3208. For example, but not limited to, the operation of the gatekeeper interface circuit 3206 can limit external communication with the selected zones 3202, 3204 to ensure the security of vehicle data and operations, to ensure the protection of personal and / or proprietary information, and to maintain the functions of the vehicle that perform the selected tasks (e.g., restricting external network traffic and / or malicious network traffic on the selected zones 3202, 3204). In another example, but not limited to, the operation of the gatekeeper interface circuit 3206 can limit the utilization of the selected transceiver 3208 to maintain the external communication bandwidth, limit the amount and / or speed of data passing through the transceiver 3208, and / or ensure that external data communication is attributed to an appropriate local communication device and / or data service provider.

[0130] Referring to FIG. 33, in certain embodiments of the disclosure of the present invention, an exemplary CND108 is shown that is consistent with the example described in FIG. 32. The exemplary CND108 includes a gatekeeper interface circuit 3206, and further includes a policy management circuit 3302 that interprets a policy 1606 including a network adjustment description, and a configuration circuit 3304 including a first network interface circuit 3306 and / or a second network interface circuit 3308 in response to the policy 1606. The network circuits 3306, 3308 adjust communications between endpoints of their respective network zones (intra-network communications) and / or communications between endpoints across their respective network zones (inter-network communications). The example described in FIG. 33 shows two network interface circuits 3306, 3308, but the operation of the gatekeeper interface circuit 3206 can be implemented with respect to only one network interface circuit, a subset of available network interface circuits, or all network interface circuits. Referring to FIG. 34, the exemplary CND108 includes a second network interface circuit 3308, and the gatekeeper interface circuit 3206 adjusts communications between the second network zone 3204 and the external device 3210. In the example described in FIG. 34, external communications from the first network zone 3202 are provided to the second network zone 3204 through the first network interface circuit 3306, and as a result, are adjusted as communications on the second network zone 3204 by the gatekeeper interface circuit 3206. In addition or alternatively, external communications from a network zone (such as the first network zone 3202) may not be adjusted by the gatekeeper interface circuit 3206, and / or external communications from a network zone (such as the first network zone 3202) may not be possible.

[0131] Referring to FIG. 35, the exemplary vehicle 102 includes a vehicle controller 3502, in which case the gatekeeper interface circuit 3206 is disposed on the vehicle controller 3502. The exemplary gatekeeper interface circuit 3206 coordinates external communication between the selected network zones 3204, 3202 and the external device 3210. The exemplary gatekeeper interface circuit 3206 and / or the vehicle controller 3502 can be the terminus of the second network zone 3204. Referring to FIG. 36, the exemplary gatekeeper interface circuit 3206 is distributed between two vehicle controllers 3502, 3602, each provided as the terminus of the second network zone 3204. In certain embodiments (not shown), the vehicle controllers 3502, 3602 can be the termini on separate network zones 3204. In the example where the gatekeeper interface circuit 3206 is distributed, each partial gatekeeper interface circuit 3206 can coordinate a portion of the external communication, such as communication with the connected network zone, and / or can have the function of coordinating all external communication of the selected network zone to enable a redundant function in the event that communication with, for example, one of the partial gatekeeper interface circuits 3206 is lost or degraded. Referring to FIG. 37, the example gatekeeper interface circuit 3206 is distributed between a first portion on the CND 108 and a second portion on the vehicle controller 3702. The exemplary vehicle controller 3702 is the terminus on the second network zone 3204. Similar to the example described in FIG. 36, each partial gatekeeper interface circuit 3206 can coordinate a portion of the external communication, such as communication with the connected network zone, and / or can have the function of coordinating all external communication of the selected network zone to enable a redundant function in the event that communication with, for example, one of the partial gatekeeper interface circuits 3206 is lost or degraded.

[0132] Referring to FIG. 38, the exemplary policy 1606 includes an external data path specification description 3802, in which case the configuration circuit 1604 configures a gatekeeper interface circuit in response to the external data path specification description 3802. The exemplary external data path specification description 3802 includes one or more of a local DNS 3804, an external DNS 3806, and / or one or more external data path specification paths 3808.

[0133] Referring to FIG. 39, the exemplary local DNS 3804 includes several local address values 3904 for the endpoints 3902 of network zones, each corresponding to at least one non-local address value 3906. The exemplary local DNS 3804 can be stored as part of the policy 1606 as a data structure, and can be included together with the local address table 2100 (see FIG. 21) or as a separate data structure. The exemplary local DNS 3804 can be used in network address translation (NAT) operations. The exemplary non-local address values 3906 include addresses used by external devices (e.g., an IPv4 address or an IPv6 address directed to an endpoint, in which case the IPv4 address or the IPv6 address may not match the local address value 3904, but can be a value from a previous configuration, a value normally used by an entity related to the external device, etc.). The exemplary non-local address values 3906 include standard values for endpoints (e.g., industry standards, customary values, values used by a standardization body such as SAE). The exemplary non-local address values 3906 include proprietary values for endpoints (e.g., values normally used by a manufacturer, an aftermarket entity, etc.). The exemplary non-local address values 3906 include previous local address values for endpoints (e.g., local address values 3904 such as those used when the vehicle was manufactured, used for a previous configuration of the vehicle, used for a previous configuration of a related vehicle such as a previous model year). The use of the local DNS 3804 enables an external device to specify the address of the vehicle endpoint 3902 using a separate non-local address value 3906 without the need for knowledge of the network configuration, location, or other information regarding the vehicle endpoint 3902. Further, the use of the local DNS 3804 enables changes to the vehicle configuration, such as movement of endpoints between network zones, aggregation of endpoints, and / or any other changes to the vehicle endpoint and / or the vehicle network topology, while allowing external devices, applications, etc. to function properly without change.The use of the local DNS 3804 further enables separation from external applications of knowledge about the vehicle, enables more users to access vehicle information, isolates external users from vehicle information, and reduces the development time and / or resource requirements of external applications. The use of the local DNS 3804 further provides ease of gradual change to the vehicle's network topology, such as the migration of endpoints from a first network zone to a second network zone over several model years or other configurations of repetition.

[0134] The illustrated policy management circuit 1602 determines address changes for endpoints in the first network zone and / or the second network zone and updates the local DNS 3804 accordingly. For example, the policy management circuit 1602 detects a movement of an endpoint between network zones (e.g., detects communication from the endpoint and / or receives an identifier from the endpoint in the new location and / or receives a change notification from the endpoint, service tool, etc.), and can update the local DNS 3804 with a local address value 3904 corresponding to the new location (e.g., network zone, address value, etc.) in response to the movement. In another example, the policy management circuit 1602 can detect a change in the non-local address value 3906 for an endpoint and update the local DNS 3804 accordingly. For example, a change to the policy 1606 from an external device indicates that a change in the non-local address value 3906 has occurred (e.g., "AmbTempSens" is now "Ambient Temperature Sensor"), and / or the public list of non-local address values 3906 can be updated (e.g., the public list is a list provided on the memory of a cloud server, in which case the policy management circuit 1602 traverses the list periodically and / or in response to an event regarding the change). The illustrated policy management circuit 1602 determines authorization of an external device that enables a change in the non-local address value 3906, for example, only authorized devices, entities, applications, etc. are allowed to adjust the non-local address value 3906. The operation of the policy management circuit 1602 to update the non-local address value 3906 does not need to include individual vehicles when changing proprietary or standard references to endpoints, enabling advantageous compliance with industry standards, manufacturer preferences, and / or systematic changes to several vehicles. It can be seen that the operation of updating the non-local address value 3906 can improve memory utilization because the associated vehicle group can reduce the size of the local DNS 3804 (and / or the local address table 2100) over time with respect to the received address value, eliminating unnecessary associations of non-local address values 3906 that are no longer in use.

[0135] Referring to FIG. 40, an exemplary external data path specification description includes an external DNS 3806 that includes several external address values 4004 for external network access locations, each corresponding to a local communication device 4002. The external DNS 3806 enables the gatekeeper interface circuit 2802 to control access to the external network access location for the local communication device 4002. In certain embodiments, the external DNS 3806 is operative to allow only permitted external access (e.g., when an external address value 4004 is provided). In certain embodiments, the external DNS 3806 is operative to prevent external access (e.g., when access to the external address 4004 listed cannot be made). In certain embodiments, both access permission and / or access type can be adjusted according to the local communication device 4002. For example, when an external address value 4004 is available, certain endpoints, flows, applications, vehicle functions, etc. can be limited to external access, and external access can be enabled for other endpoints, flows, applications, vehicle functions, etc., except when a particular external address value 4004 is described as access-prevented in the list. In certain embodiments, the external DNS 3806 includes an IP address corresponding to a non-local address value 3906, e.g., an external address value 4004 that can be a common name such as a website address described in the list in the description language. The use of the non-local address value 3906 enables fast external access without the need to use an external DNS (e.g., from a cloud server and / or an Internet provider), and further enables a differential response to the local communication device 4002 for a given external address value 4004 (e.g., enabling some local communication devices to access a given external web address and redirecting other local communication devices to a selected location). Exemplary and non-limiting exemplary network access locations include one or more of Internet access, wide area network address, and / or an identifier of an external device and / or an external application.

[0136] The exemplary external data path designating path 3808 includes a network zone trajectory of the external communication to be adjusted corresponding to the local communication device. The exemplary network zone trajectory includes a data configuration for communication such as one or more of an upsampling description, a downsampling description, an encapsulation description, a data processing description, a communication frame processing description, and / or a data rate description. For example, this network zone trajectory enables providing communication by adding selected communication processing including its payload and / or frame and / or providing at a selected data rate. The selected data rate can be made to follow the data rate requirement from the external device and / or follow the data rate limitation for the external communication (for example, for limiting network utilization, transceiver utilization, data transmission regarding the data provider, etc.). This network zone trajectory, in addition to or instead of this, for example, enables a message to pass through an involved network zone before being transmitted outside the vehicle (for example, a CAN message from a first network zone passes as an Ethernet message on a second network zone).

[0137] The exemplary network zone trajectory further includes an external communication portal 4102 for regulated communication (see, e.g., FIG. 41 and related description), in which case the gatekeeper interface circuit 3206 further regulates communication between a local communication device (e.g., an endpoint of the network zone) and the external communication portal 4102. Exemplary and non-limiting external communication portals 4102 include transceiver options (e.g., when more than one transceiver is available), access point name (APN) options, hardware port options (e.g., a hardware port of the network zone, an OBD port, a proprietary communication port, a USB port, etc.), a WiFi adapter, a Bluetooth adapter, and / or cellular communication. The exemplary network zone trajectory enables the gatekeeper interface circuit 3206 to utilize the lowest cost, the lowest impact on vehicle and / or network performance, attribute external communication to an appropriate service provider, guarantee QoS parameters for the local communication device, and / or guarantee the security of external communication. The exemplary gatekeeper interface circuit 3206 adjusts the network zone trajectory in response to vehicle operating conditions (e.g., vehicle stop, service mode, idling, operation under rated conditions, available external communication portal 4102, etc.). The exemplary gatekeeper interface circuit 3206 adjusts the network zone trajectory in response to operating conditions of the network zone and / or transceiver (e.g., current utilization rate, connectivity, fault status, etc.).

[0138] Exemplary external data path designations include an APN for regulated communications (e.g., specifying a data service provider for the communications). Exemplary gatekeeper interface circuit 3206 adjusts the APN in response to vehicle, network zone, and / or transceiver operating conditions (e.g., where the communications support more applications, vehicle functions, and / or flows than does adjusting the APN in response to vehicle operating conditions and enables attributing the regulated communications to the “primary consumer” of the communications). Exemplary gatekeeper interface circuit 3206 aggregates regulated communications from several local communication devices (e.g., where the communications support more endpoints, applications, vehicle functions, and / or flows than one) and distributes the aggregated regulated communications among more than one APN for the local communication devices (e.g., where the communications support multiple consumers and the aggregated traffic can be distributed across multiple APNs, enabling reduction of all external communications by avoiding redundancy while attributing all external communications). In certain embodiments, the operations of adjusting the APN, aggregating the regulated communications, and / or distributing the aggregated regulated communications among APNs are performed in response to the attribution description of policy 1606.

[0139] The exemplary policy management circuit 1602 determines, for example, changes to an external data path designating path imposed by an external device 1618 and updates the external data path designating description in response to the change to the external data path designating path. The exemplary policy management circuit 1602 determines authorization of an external device providing the change to the external data path designating path and suppresses all or a portion of the change to the external data path designating path in response to determining that the change is not authorized or is not fully authorized. The exemplary policy management circuit 1602 changes the external data path designating path in response to a change to a local communication device (e.g., changes the path designation in response to an endpoint moving from one network zone to another network zone). Exemplary and non-limiting changes to the local communication device include flow changes including movement of an endpoint from one of a first network zone or a second network zone to the other of the first network zone or the second network zone, changes to priority, periodic reception, or permission, application changes including changes to priority, periodic reception, or permission, and / or changes to the amount, composition, or type of data communicated by the local communication device, including one or more of the foregoing.

[0140] Referring to FIG. 41, exemplary vehicle 102 includes a gatekeeper interface circuit 3206 that coordinates communication between a local communication device and an external device 1618. Exemplary vehicle 102 includes a local communication device (transmit / receive local communication device 4104) targeted to transmit and / or receive communication from external device 1618, and in response to the transmitted or received communication and further in response to a policy 1606 that includes an external data path designation path, permissions regarding the local communication device, and / or permissions regarding external device 1618, gatekeeper interface circuit 3206 provides routed external communication 4108. In certain embodiments, gatekeeper interface circuit 3206 selects an external communication portal 4102 for the routed external communication 4108, and this selection includes selecting the device through which the routed external communication 4108 will pass when it is communicated to external device 1618. Exemplary external communication portal 4102 includes one or more of a first transceiver 4110 and / or an APN selection branch 4122 therefor (e.g., enabling selection of a data provider for communication 4108), a second transceiver 4112, APN selection branch 4122, and / or a channel selection branch 4124 for second transceiver 4112 (e.g., enabling selection of a data provider and / or channel for transceiver 4112), a second network zone connection 4114 (e.g., a port for an Ethernet network zone), a WiFi adapter 4116 (e.g., utilizing a WiFi connection if available), a Bluetooth adapter 4118 (e.g., utilizing a Bluetooth connection if available), and / or a first network zone connection 4120 (e.g., a port for a CAN network zone). The example depicted in FIG. 41 shows a first transceiver 4110 and a second transceiver 4112 for purposes of illustration to show whether the transceivers 4110, 4112 can have channels, but a given vehicle 102 can have any number of transceivers 4110, 4112 that can either have some that have channel passing operation or all that have channel passing operation or none that have channel passing operation.The example described in FIG. 41 shows a single connection to each network zone for the convenience of explanation to show that any network zone can have a connection, but a given network zone may have no connection (such as an OBD port and a proprietary port) or more than one connection. Without being limited to any other aspect of the disclosure of the present invention, the gatekeeper interface circuit 3206 can be based on an available external communication portal 4102, vehicle operating conditions, network operating conditions, permission of any entity in the communication chain, priority of any entity in the communication chain, service requirements of any entity related to the vehicle, and / or data speed and / or data volume limit to adjust the routing operation.

[0141] Referring to FIG. 42, exemplary policy 1606 includes an external data service description 4202, in which case configuration circuit 1604 includes a gatekeeper interface circuit 3206 in response to external data service description 4202. Exemplary external data service description 4202 includes several local communication devices 4204, each corresponding to a QoS value 4206. Exemplary and non-limiting QoS values 4206 include priority values, packet delay values (e.g., maximum, average, or other packet delay descriptions), packet loss rate values (e.g., maximum, average, longest gap time, or other packet loss descriptions), data rate values, maximum dropout time values, acknowledgment values (e.g., whether an acknowledgment for communication corresponding to a related local communication device is required if available), data buffering priority values (e.g., which can be used to determine buffer size, buffer priority, and / or data invalidation parameters for buffered target data), data buffering size values (e.g., data buffer size, buffering time, or other storage size-related parameters), and / or data life cycle descriptions (e.g., storage life, invalidation time, and / or deletion priority for related data), including one or more of these. Without limiting to any other aspect of the disclosure of the present invention, local communication devices include one or more of a network zone endpoint, an application, a flow, a vehicle function, and / or a vehicle controller. In certain embodiments, gatekeeper interface circuit 3206 adjusts external communication using QoS value 4206 corresponding to local communication device 4204 for adjusted communication. In certain embodiments, for example, when more than one local communication device 4204 is related to adjusted communication (e.g., an endpoint and a flow), gatekeeper interface circuit 3206 utilizes the QoS value 4206 related to the highest priority one of these local communication devices 4204 and / or applies a superset of applicable QoS values 4206 that satisfy the highest service value for all related local communication devices 4204.

[0142] The exemplary policy management circuit 1602 determines, for example, a change in the external data service description due to an update of a policy from an external device, and the configuration circuit 1604 updates the configuration of the gatekeeper interface circuit 3206 in response to the updated policy. The exemplary policy management circuit 1602 determines the authorization of an external device that provides a change in the external data service description, and suppresses all or a part of the change to the external data service description in response to determining that the change is not authorized or is not fully authorized.

[0143] Referring again to FIG. 40, the exemplary external data path specification description includes an external DNS that includes several external address values 4004 for external network access locations, each corresponding to a local communication device 4002 (e.g., an endpoint of a network zone). The exemplary gatekeeper interface circuit 3206 further accesses an external DNS outside the vehicle (not shown) as required by an endpoint that communicates using the external address value, in which case the requested external address value is not found on the external DNS 3806. The exemplary gatekeeper interface circuit 3206 further updates the external DNS 3806 in response to accessing the external DNS outside the vehicle.

[0144] Referring again to FIG. 28, the exemplary vehicle 102 includes a first network zone 1612 and a second network zone 1614 of a different type. The exemplary vehicle 102 includes a policy management circuit 1602 that interprets a policy 1606 including an external data path specification description and an external data service description. The exemplary vehicle 102 includes a configuration circuit 1604 including a gatekeeper interface circuit 2802 in response to the external data path specification description and the external data service description. In this example, the gatekeeper interface circuit 2802 is inserted between the first network zone and at least one external communication portal 4102 (see, e.g., FIG. 41) selectively connectable to an external device 1618, and is further inserted between the second network zone and the at least one external communication portal 4102. The gatekeeper interface circuit 2802 coordinates communication between the endpoints of the network zones 1612, 1614 and the external communication portal 4102. The exemplary external data path specification description includes several local communication devices each corresponding to an external data path specification path. The exemplary external data path specification path includes a network zone trajectory of the coordinated communication. The exemplary network zone trajectory includes a data configuration such as an upsampling description, a downsampling description, an encapsulation description, a data processing description, a communication frame processing description, and / or a data rate description. The exemplary network zone trajectory includes at least one external communication portal 4102 for the coordinated communication.

[0145] Exemplary external data service descriptions each include several local communication devices, each corresponding to one or more QoS values. In yet another example, the external communication portal 4102 includes a first transceiver and a second transceiver, in which case the gatekeeper interface circuit further distributes the communication adjusted in response to the external data service description between the first transceiver and the second transceiver. In another example, the external communication portal 4102 includes a first channel connected to a transceiver and a second transceiver connected to this transceiver, in which case the gatekeeper interface circuit distributes the communication adjusted in response to the external data service description between the first channel and the second channel.

[0146] Exemplary external communication portal 4102 includes one or more external access points such as a transceiver, a wireless transceiver, a Bluetooth transceiver, a hardware port on a first network zone, a hardware port on a second network zone, an on-board diagnostic (OBD) port, a proprietary network port, an external network using wireless communication with a vehicle (e.g., in this case, communication with an external device is routed to the external network and / or tunneled through the external network), an external network using cellular communication with a vehicle, an Ethernet network using Bluetooth communication with a vehicle (e.g., in this case, communication with an external device is routed to the external network and / or tunneled through the external network), more than one transceiver channel, more than one transceiver, and / or several channels distributed across at least two transceivers.

[0147] Exemplary gatekeeper interface circuit 2802 further distributes the adjusted communication between at least two external access points. In yet another example, the QoS values include service descriptions such as a priority value, a packet delay value, a packet loss rate value, a data rate value, a maximum dropout time value, an acknowledgment value, a data buffering priority value, a data buffering size value, and / or a data lifetime cycle description.

[0148] Certain aspects of the disclosure of the present invention are shown as procedures for performing operations related to the disclosure of the present invention. The operations can be performed by any controller, circuit, device, component, sensor, actuator, logic circuit, or other aspect shown in the disclosure of the present invention, but are not limited thereto. The procedures are shown as embodiments, and the operations can omit all or part thereof, combine them, divide them, and / or change the order. In certain embodiments, one or more operations of the first procedure can be combined with one or more operations of another procedure.

[0149] Referring to FIG. 43, an exemplary procedure 4300 for coordinating communication between different types of networks on a vehicle is shown. The exemplary procedure 4300 includes an operation 4302 of interpreting a policy including a network coordination description and an operation 4304 of coordinating communication between an endpoint of a first network and an endpoint of a second network in response to the network coordination description.

[0150] Referring to FIG. 44, an exemplary procedure 4400 for coordinating communication between different types of networks on a vehicle is shown. The exemplary procedure 4400 includes an operation 4302 of interpreting a policy that includes a network coordination description, and an operation 4402 of receiving policy communication from an external device. The procedure 4400 includes an operation 4404 of determining whether the policy is verified, for example, whether the external device is authorized to update the policy, whether the system has a function to implement according to the policy, whether the policy violates any security criteria, whether the implementation of the policy is considered to be greater than the data storage limit or communication limit, etc. In response to the operation 4404 indicating "YES", the procedure 4400 includes an operation 4406 of storing and / or updating the policy, and an operation 4304 of coordinating communication between an endpoint of a first network and an endpoint of a second network in response to the network coordination description. In response to the operation 4404 indicating "NO", the procedure 4400 optionally includes an operation 4408 of providing a notification to the external device (and / or other external devices), and an operation 4304 of coordinating communication between an endpoint of a first network and an endpoint of a second network in response to the network coordination description (for example, using a previous policy, a default policy, etc.).

[0151] Referring to FIG. 45, an exemplary procedure 4500 for coordinating communication between different types of networks on a vehicle is shown. The exemplary procedure 4500 includes an operation 4302 for interpreting a policy that includes a network coordination description, and an operation 4402 for receiving policy communication from an external device. The procedure 4500 includes an operation 4404 for determining whether the policy is verified, for example, whether the external device is authorized to update the policy, whether the system has a function to implement according to the policy, whether the policy violates any security criteria, whether the implementation of the policy is considered to be greater than the data storage limit or communication limit, etc. In response to operation 4404 indicating YES, the procedure 4500 includes an operation 4502 for updating the local configuration file of one or more of the network interface circuit, CEG, CES, and / or gateway interface circuit. In response to operation 4404 indicating NO, the procedure 4500 optionally includes an operation 4408 for providing a notification to the external device (and / or other external devices). The procedure 4500 includes an operation 4504 for coordinating in-network communication, inter-network communication, and / or external communication using the network interface circuit, CEG, CES, and / or gateway interface circuit (for example, regardless of whether it has been updated).

[0152] Referring to FIG. 46, an exemplary procedure 4600 for commanding an actuator in response to a diagnostic command value is shown. The exemplary procedure 4600 includes an operation 4602 for interpreting a policy that includes an active diagnostic description, an operation 4604 for providing a diagnostic command value in response to an active diagnostic condition as an end point, and an operation 4606 for commanding the actuator in response to the diagnostic command value.

[0153] Referring to FIG. 47, an exemplary procedure 4700 for commanding an actuator in response to a diagnostic command value is shown. The exemplary procedure 4700 includes an operation 4702 for interpreting a policy including an active diagnostic description and diagnostic execution conditions, and an operation 4704 for determining whether the vehicle operating conditions match the diagnostic execution conditions and / or the diagnostic command value (e.g., determined from the active diagnostic description). In response to the operation 4704 determining YES, the procedure 4700 includes an operation 4604 for providing a diagnostic command value in response to the active diagnostic conditions as an end point, and an operation 4606 for commanding the actuator in response to the diagnostic command value.

[0154] Referring to FIG. 48, an exemplary procedure 4800 for commanding an actuator in response to a diagnostic command value is shown. The exemplary procedure 4800 includes an operation 4602 for interpreting a policy including an active diagnostic description, and an operation 4802 for performing a diagnostic data collection operation in response to the active diagnostic description. Further, the exemplary procedure 4800 includes an operation 4604 for providing a diagnostic command value in response to the active diagnostic conditions as an end point, and an operation 4606 for commanding the actuator in response to the diagnostic command value.

[0155] Referring to FIG. 49, an exemplary procedure 4802 for performing a diagnostic data collection operation is shown. The exemplary procedure 4802 includes an operation 4902 for processing the collected data (e.g., processing the message payload and / or frame information of the collected data), an operation 4904 for storing the collected and processed data, and an operation 4906 for communicating at least a portion of the stored data to an external device.

[0156] Referring to FIG. 50, an exemplary procedure 5000 for storing and / or communicating a diagnostic confirmation value is shown. The exemplary procedure 5000 includes an operation 4602 for interpreting a policy including an active diagnostic description, an operation 4604 for providing a diagnostic command value in response to the active diagnostic conditions as an end point, and an operation 4606 for commanding the actuator in response to the diagnostic command value. Further, the exemplary procedure 5000 includes an operation 5002 for determining the diagnostic confirmation value, and an operation 5004 for storing the diagnostic confirmation value and / or communicating it to one or more external devices.

[0157] Referring to FIG. 51, an exemplary procedure 5100 for commanding an actuator in response to a diagnostic command value is shown. In addition to the operations enumerated with respect to FIG. 46 and earlier, exemplary procedure 5100 includes an operation 5102 of determining whether the target device description indicates a network address value for a target endpoint with respect to the actuator that received the command (e.g., if the target device description does not indicate a network address value or indicates an invalid network address value, operation 5102 determines NO). In response to operation 5102 determining YES, procedure 5100 proceeds to operation 4604. In response to operation 5102 determining YES, procedure 5100 includes an operation 5104 of supplying or adjusting the network address value for the target endpoint, and then proceeds to operation 4604.

[0158] Referring to FIG. 52, an exemplary procedure 5200 for adjusting communication between an external device and an endpoint of a network zone towards a vehicle is shown. Exemplary procedure 5200 includes an operation 5202 of interpreting a policy including an external communication value and an operation 5204 of adjusting communication between the endpoint of the network zone and the external device in response to the external communication value.

[0159] Referring to FIG. 53, an exemplary procedure 5204 for adjusting communication between an external device and an end point of a network zone towards a vehicle is shown. The exemplary procedure 5204 includes an operation 5302 to determine the type of an external communication value. In response to operation 5302 determining the type as an active diagnostic description, the procedure 5204 includes an operation 5304 to perform an active diagnostic operation. In response to operation 5302 determining the type as an active test description, the procedure 5204 includes an operation 5306 to perform an active test operation. In response to operation 5302 determining the type as a vehicle control command, the procedure 5204 includes an operation 5308 to perform a vehicle control operation. In response to operation 5302 determining the type as an active assistance operation, the procedure 5204 includes an operation 5310 to perform an active assistance operation. Exemplary and non-limiting operation 5310 includes one or more of the stages where the inspection and repair person contacts the driver of the vehicle, the stage where the inspection and repair person commands a specified active diagnostic operation 5304, the stage where the inspection and repair person commands a specified active test operation 5306, and / or the stage where the inspection and repair person commands a specified vehicle control operation 5308. The exemplary procedure 5204 further includes an operation 5312 to determine whether the external communication value indicates yet another operation, and includes the stage of returning to operation 5302 in response to operation 5312 indicating YES.

[0160] Referring to FIG. 54, an exemplary procedure 5400 for adjusting communication between an external device and an end point of a network zone for a vehicle is shown. The exemplary procedure 5400 includes an operation 5402 to interpret a policy including an external communication value and a target device description. The exemplary procedure 5400 further includes an operation 5404 to determine whether the target device description indicates a network address value for a target end point. In response to operation 5404 determining YES, the exemplary procedure 5400 includes an operation 5408 to adjust communication between the external device and the end point of the network zone in response to the external communication value. In response to operation 5404 determining NO, the exemplary procedure 5400 includes an operation 5406 to supply or adjust a network address value for the target end point and operation 5408.

[0161] Referring to FIG. 55, an exemplary procedure 5500 for transmitting visualization data is shown. The exemplary procedure 5500 includes an operation 5502 for interpreting vehicle communication data, an operation 5504 for generating visualization data in response to the vehicle communication data, and an operation 5506 for transmitting the visualization data.

[0162] Referring to FIG. 56, an exemplary procedure 5600 for transmitting visualization data is shown. The exemplary procedure 5600 includes an operation 5502 for interpreting vehicle communication data, an operation 5602 for interpreting data filtering values, and an operation 5604 for filtering at least a portion of the vehicle communication data based at least in part on the data filtering values. The exemplary procedure 5600 further includes an operation 5504 for generating visualization data in response to the vehicle communication data and an operation 5506 for transmitting the visualization data.

[0163] Referring to FIG. 57, an exemplary procedure 5700 for adjusting communication between networks, within a network, and / or outside a vehicle is shown. The exemplary procedure 5700 includes an operation 5702 for interpreting a policy including network adjustment descriptions, an operation 5704 for configuring a network interface circuit in response to the network adjustment descriptions, and an operation 5706 for adjusting inter-network communication and / or intra-network communication using the configured network interface circuit. The exemplary procedure 5700 further includes an operation 5708 for configuring a gatekeeper interface circuit in response to the network adjustment descriptions and an operation 5710 for adjusting communication outside the vehicle using the configured gatekeeper interface circuit.

[0164] Referring to FIG. 58, an exemplary procedure 5800 for adjusting communication between networks, within a network, and / or outside a vehicle is shown. In addition to the operations shown with respect to procedure 5700, the exemplary procedure 5800 includes an operation 5802 of receiving policy communication from an external device, and an operation 5804 of determining whether the policy is verified, for example, whether the external device is authorized to update the policy, whether the system has a function to implement according to the policy, whether the policy violates any security criteria, whether the implementation of the policy is considered to be greater than data storage limits or communication limits, etc. In response to the operation 5804 determining YES, this exemplary procedure includes an operation 5806 of storing and / or updating the policy, an operation 5704 (which may further include the step of configuring a gatekeeper interface circuit), and an operation 5706 (and / or operation 5710). In response to the operation 5804 determining NO, the exemplary procedure 5800 optionally includes an operation 5807 of providing a notification to one or more external devices and proceeds to operation 5704.

[0165] Referring to FIG. 59, an exemplary procedure 5900 for adjusting communication outside the vehicle is shown. The exemplary procedure 5900 includes an operation 5902 of interpreting a policy including a network usage permission description and / or an external data access description, an operation 5904 of configuring a network interface circuit in response to the network usage permission description, and an operation 5906 of adjusting communication within and / or between networks using the network interface circuit. The exemplary procedure 5900 includes an operation 5908 of configuring a gatekeeper interface circuit in response to the external data access description, and an operation 5910 of adjusting communication outside the vehicle using the gatekeeper interface circuit.

[0166] Referring to FIG. 60, an exemplary procedure 6000 for adjusting communication between networks, within a network, and / or outside a vehicle is shown. The exemplary procedure 6000 includes an operation 6002 of determining authorization regarding adjusted communication for a local communication device, an operation 6004 of configuring a network interface circuit and / or a gatekeeper interface circuit in response to the authorization, and an operation 6006 of adjusting communication within a network, between networks, and / or outside a vehicle using the network interface circuit and / or the gatekeeper interface circuit.

[0167] Referring to FIG. 61, an exemplary procedure 6100 for adjusting communication outside a vehicle is shown. The exemplary procedure 6100 includes an operation 6102 of interpreting a policy including an external data volume description, an operation 6104 of configuring a gatekeeper interface circuit in response to the external data volume description, and an operation 6106 of adjusting communication outside a vehicle using the gatekeeper interface circuit.

[0168] Referring to FIG. 62, an exemplary procedure 6200 for adjusting communication outside a vehicle is shown. The exemplary procedure 6200 includes an operation 6202 of interpreting a policy including an external data path designation description, an operation 6204 of configuring a gatekeeper interface circuit in response to the external data path designation description, and an operation 6206 of adjusting communication outside a vehicle using the gatekeeper interface circuit.

[0169] Referring to FIG. 63, an exemplary procedure 6300 for adjusting communication outside a vehicle is shown. The exemplary procedure 6300 includes an operation 6302 of interpreting a policy including an external data path designation path corresponding to each of several local communication devices, an operation 6304 of configuring a gatekeeper interface circuit in response to the external data path designation path, and an operation 6306 of adjusting communication outside a vehicle using the gatekeeper interface circuit.

[0170] Referring to FIG. 64, an exemplary procedure 6400 for adjusting vehicle external communication is shown. The exemplary procedure 6400 includes an operation 6402 of interpreting a policy including an external data service description, an operation 6404 of configuring a gatekeeper interface circuit in response to the external data service description, and an operation 6406 of adjusting vehicle external communication using the gatekeeper interface circuit.

[0171] Referring to FIG. 65, an exemplary procedure 6500 for providing information in response to a data request including access to an external device is shown. The exemplary procedure 6500 includes an operation 6502 of interpreting a data request including access to an external device, and an operation 6504 of determining whether an external DNS includes the external device. In response to the operation 6504 determining YES, the exemplary procedure 6500 includes an operation 6506 of providing information in response to the data request using an external address value from the external DNS. In response to the operation 6504 determining NO, the exemplary procedure 6500 includes an operation 6508 of accessing an external DNS outside the vehicle to determine an external address value for the external device, and an operation 6510 of providing information in response to the data request using the external address value from the external DNS outside the vehicle.

[0172] Referring to FIG. 66, an exemplary procedure 6600 for providing vehicle external communication using a selected network zone trajectory is shown. This exemplary procedure includes an operation 6602 of providing vehicle external communication using the selected network zone trajectory, and an operation 6604 of performing a data configuration operation on the vehicle external communication based on the network zone trajectory. The exemplary operation 6604 includes one or more of an upsampling operation, a downsampling operation, a data processing operation, a payload processing operation, a frame processing operation, an encapsulation operation, and / or a data rate management operation.

[0173] Referring to FIG. 67, an exemplary procedure 6700 for providing vehicle external communication using a selected QoS value is shown. The exemplary procedure 6700 includes an operation 6702 for providing vehicle external communication using the selected QoS value and an operation 6704 for performing distribution of communication between an external communication portal and / or an APN based on the QoS value.

[0174] Referring to FIG. 68, embodiments of some embodiments of message conversion and / or message encapsulation are shown. The example described in FIG. 16 is illustrative of certain aspects of the disclosure of the present invention and does not limit the disclosure of the present invention. In certain embodiments, the operations shown in FIG. 68 can be performed in whole or in part by CEG, CES, a conversion circuit, and / or CND, and in certain embodiments, can be adjusted by CND. The first exemplary message conversion 6802 includes a message from a first network having a payload 6810 and other frame information 6808. The other frame information can include a header, subsequent aspects, and / or end bits, and can be further determined by relevant protocols, network types, source endpoints, destination endpoints, or other aspects known in the art. In certain embodiments, the payload 6810 can be considered to be message data, data values represented by the message, or other information that is the content of the message. However, in certain embodiments, the payload 6810 can be any other aspect of the message during certain operating conditions for certain operations and / or with respect to certain endpoints. For example, network monitoring operations can utilize a timestamp, acknowledgment information, source and / or destination information, or other portions as the payload of the message. The exemplary message conversion 6802 includes separating the payload 6810 and packaging the payload in a new frame (or packet) 6812 within information configured to match the target network. In addition to or instead of this, the new frame 6812 can include information that enables adjustment of identifiers (e.g., source or destination), a timestamp, or extraction of endpoints on heterogeneous networks from knowledge of each other. In certain embodiments, the payload 6810 can be processed to, for example, change the unit of utilization, change the bit depth (e.g., 2 bytes to 4 bytes), change the representation accuracy, or change conversions such as floating point or fixed point.

[0175] The second exemplary message conversion 6804 includes the original messages 6808, 6810 and, for example, is fully encapsulated within a new frame 6812 in order to provide the original messages provided by the original source to a target endpoint (e.g., enabling previously developed algorithms to operate as is without the need to convert to a new message, enabling certain network monitor operations that utilize the complete original message, and further enabling similar things). In certain embodiments, either the original payload 6810 or the message frame 6808 can be processed, e.g., the payload is processed as described above and converted to a new decision-making source identifier, timestamp, etc. for extracting endpoints from each other, but otherwise providing equivalent information or information adjusted methodologically.

[0176] The third exemplary message conversion 6806 includes the original messages 6808, 6810 having an adjusted payload 6814. The adjustment to the payload 6814 can include conversion of the payload 6814 in any manner (e.g., value correction, virtual sensing or modeling of values based on the original payload 6810, upsampling or downsampling of the payload 6810, etc.), and in addition to or instead of this, can include processing of the payload. The third exemplary message conversion 6806 describes an adjusted payload 6814, but adjustments can be made in addition to or instead of this to other parts of the message frame 6808. In the third exemplary message, a new frame 6812 is applied for another communication.

[0177] Referring to FIG. 69, a schematic diagram of the operation of downsampling message sequence 6902 is shown. In the example described in FIG. 69, message sequence 6902 (e.g., a series of five communications in this example) is received, for example, at the network interface circuit of one of the network gateway devices. In the example described in FIG. 69, the downsampling operation is in response to any of the downsampling operations described herein, for example, to match the data rate of the receiving endpoint, to provide the data represented by message 6902 at a planned rate, to manage the bandwidth for the vehicle's network and / or for off-vehicle communications, to maintain a buffer memory, or for any other purpose related to any of the downsampling operations of the present disclosure. In the example described in FIG. 69, a downsampling device 6904, which can be a conversion circuit, a network interface circuit, a CND, a circuit connected to the CND, a circuit adjusted by the CND, etc., generates a converted message sequence 6908 (e.g., processed as shown in FIG. 16 and the related disclosure and / or processed according to any other message conversion and / or message processing operations shown herein). The example described in FIG. 69 depicts the converted message sequence 6908 for purposes of clarity of explanation. However, not all of the converted message sequence 6908 may be present at the same time. For example, when a message is converted and transmitted, these messages can be removed from the cache, deleted, invalidated, etc. The message sequence 6908 is shown to illustrate aspects of the present disclosure. In addition to or instead of this, for example, to reduce the utilization of processing resources, the conversion of message 6908 can be performed after the downsampling operation is carried out. For example, a portion of the messages can be excluded as part of the downsampling before the conversion operation (e.g., partial frame or metadata exchange, encapsulation, payload and / or partial frame processing, etc.) is performed.In the example described in FIG. 69, the downsampled message sequence 6906 is provided and communicated to, for example, different network gateway devices, different vehicle networks that are the source of the first message sequence 6902, external devices (such as service tools, cloud servers, the driver's mobile device, etc.) and / or stored on a memory storage device on the vehicle (such as, for example, as part of the stored vehicle data for later data collection operations). In this example, five messages of the original sequence 6902 are downsampled to three messages of the downsampled sequence 6906. The downsampling operation can include the step of converting the messages selected from the original sequence 6902, for example, changing the original 10 ms data stream 6902 to a downsampled 20 ms data stream 6906 by using every other data message. The downsampling operation can, in addition to or instead of this, include interpolation of the data messages between the original values. For example, when the original data stream 6902 is a 40 ms data stream and the downsampled data stream 6906 is a 100 ms data stream, the downsampling can include the step of using either the one that adopts the message closest in time or the one that performs an interpolation operation (for example, linear fitting, spline fitting, polynomial fitting, or other interpolation operations applied to the interpolated data points) as the downsampled message 6906.

[0178] When used in this specification, an interpolated data point or interpolated data value indicates a data value that is not temporally aligned with the corresponding original data message 6902 within the downsampled message 6906. When used in this specification, a non-interpolated data point or non-interpolated data value indicates a data value that is temporally aligned or synchronized with the corresponding original data message 6902 within the downsampled message 6906. The message of the original data message 6902 and the message of the downsampled message 6906 can, in addition to or instead of this, have a phase difference. Thus, in certain embodiments, it will be understood that any or all of the original data messages 6902 may be non-interpolated messages. In certain embodiments, even if there is a phase difference between the original data message 6902 and the downsampled message 6906, for example, to provide a baseline downsampled message 6906 that follows the trajectory characteristics (e.g., within the time domain) of the stream of the original data message 6902 and / or when any phase difference can be ignored for the purpose of a device or operation that utilizes the downsampled message 6906 (e.g., when such a device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference), certain messages of the original data message 6902 can be processed as non-interpolated data messages or synchronized data messages.

[0179] In yet another example, synchronous data values (e.g., every fifth data value when transitioning from 40 ms to 100 ms) can be used directly, or a fitting function can be utilized (e.g., to provide a smoothly filtered or otherwise processed data value stream). In certain embodiments, minor transient behavior from various time steps is either not relevant to how the downsampled data value 6906 is utilized, or timestamp data is further communicated with the message, such that in either case where the differential time steps between messages can be considered in the process of utilizing the downsampled data 6906, it may be desirable to use the actual data value provided from the first data stream 6902 as the downsampled data value 6906. In certain embodiments, it may be desirable to use smoothed data values that simulate the time response behavior of the underlying data, and these data values can be controlled using interpolation data with respect to the interpolated data values (e.g., a process that responds to the rate of change of the downsampled data 6906, such as a threshold check against the rate of change). In certain embodiments, for example, when downstream processing is particularly susceptible to the time variation of the data message 6902 (e.g., the derivative part of a PID controller), it may be desirable to ensure that all downsampled data messages 6906 are generated from the same process and that an interpolation operation (or smoothing, filtering, or moving average) can be performed to generate both interpolated and non-interpolated data values 6906. In certain embodiments, the downsampled data message 6906 can further include metadata or other embedded information indicating whether it directly corresponds to the original data message 6902 or is a processed message (e.g., enabling more than one use of the downsampled data message 6906, diagnostic operations related to the device providing the original data message 6902, and / or any other purpose).

[0180] The downsampling operation described in FIG. 69 can be seen to enable communication between devices and / or procedures having different data rate capabilities, expectations, and / or usage rates of the downsampled data. Further, the downsampling operation described in FIG. 69 provides sufficient data to perform using the time domain response (e.g., differential behavior, integral behavior, step change response, etc.) expected for proper functioning of devices and procedures where the function intended by the device and / or procedure may depend on the time dynamics of the communication data values, while enabling reduction of network utilization. The downsampling operation described in FIG. 69 enables a progressive update of the communication mode (e.g., components, devices, procedures, and / or operations that each interact with the network and / or other components, devices, procedures, and / or operations by communication) of a mobile application having a combination of hybrid network configurations and / or conventional communication modes (e.g., having lower data rate capabilities and / or data rate expected values, and / or clearly different network protocols, characteristics, message types, etc.) to the latest communication mode (e.g., higher data rate capabilities and / or data rate expected values, and / or clearly different network protocols, characteristics, message types, etc.).

[0181] Referring to FIG. 70, a schematic diagram of the operation of upsampling message sequence 7002 is shown. In the example described in FIG. 70, a message sequence 7006 (for example, a series of three communications in this example) is received at the network interface circuit of one of the network gateway devices, for example. In the example described in FIG. 70, the upsampling operation is in response to any of the upsampling operations described herein, for example, for matching the data rate of the receiving endpoint, providing the data represented by message 7006 at a planned rate, managing the bandwidth for the vehicle network and / or for off-vehicle communications, maintaining a buffer memory, or for any other purpose related to any of the upsampling operations of the disclosure of the present invention. In the example described in FIG. 70, an upsampling device 7004, which can be a conversion circuit, a network interface circuit, a CND, a circuit connected to the CND, a circuit adjusted by the CND, etc., generates a converted message sequence 7008 (for example, processed as shown in FIG. 16 and related disclosures and / or processed according to any other message conversion and / or message processing operations shown herein). The example described in FIG. 70 depicts the converted message sequence 7008 for purposes of clarity of explanation. However, not all of the converted message sequence 7008 may be present at the same time. For example, when a message is converted and transmitted, these messages can be removed from the cache, deleted, invalidated, etc. The message sequence 7008 is shown to illustrate aspects of the disclosure of the present invention. In addition to or instead of this, for example, to reduce the utilization of processing resources, the conversion of message 7008 can be performed after the upsampling operation has been carried out.

[0182] For example, some of the messages can be excluded or adjusted as part of the upsampling before the conversion operations (e.g., partial frame or metadata exchange, encapsulation, payload and / or partial frame processing, etc.) are performed. In the example described in FIG. 70, the upsampled message sequence 7002 is provided and communicated to, for example, different network gateway devices, different vehicle networks that are the source of the first message sequence 7006, external devices (e.g., service tools, cloud servers, driver's mobile devices, etc.) and / or stored on a memory storage device on the vehicle (e.g., as part of the stored vehicle data for later data collection operations). In this example, three messages of the original sequence 7006 are upsampled to five messages of the upsampled sequence 7002. The upsampling operation can include the step of converting the messages selected from the original sequence 7006, for example, changing the original 50 ms data stream 7006 to the upsampled 20 ms data stream 7002 by inserting one or more generated messages 7010. The upsampling operation can include, in addition to or instead of this, interpolation and / or extrapolation of the data messages between the original values. For example, when the original data stream 7006 is a 50 ms data stream and the upsampled data stream 7002 is a 20 ms data stream, the upsampling can utilize, as the upsampled message 7002, either the one that adopts the temporally closest message or the one that performs interpolation operations and / or extrapolation operations (e.g., applying linear fitting, spline fitting, polynomial fitting, moving average, and / or low-pass filter sequences between available data points and / or between available data points and the next expected data point).

[0183] When used herein, an interpolated data point or interpolated data value indicates a data value that is not temporally aligned with the corresponding original data message 7006 within the upsampled message 7002. When used herein, a non-interpolated data point or non-interpolated data value indicates a data value that is temporally aligned or synchronized with the corresponding original data message 7006 within the upsampled message 7002. The message of the original data message 7006 and the message of the upsampled message 7002 can, in addition to or instead of this, have a phase difference. Thus, in certain embodiments, it will be understood that any or all of the original data messages 7006 may be non-interpolated messages. In certain embodiments, even if there is a phase difference between the original data message 7006 and the upsampled message 7002, for example, to provide a baseline upsampled message 7002 that follows the trajectory characteristics (e.g., within the time domain) of the stream of the original data message 7006 and / or for the purpose of a device or operation that utilizes the upsampled message 7002, any phase difference can be ignored (e.g., if such a device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference), certain messages of the original data message 7006 can be processed as non-interpolated data messages or synchronized data messages.

[0184] In yet another example, synchronous data values (e.g., every other data value when transitioning from 50 ms to 20 ms, e.g., 0 ms phase value and 100 ms phase value) can be used directly, or a fitting function can be utilized (e.g., to provide a smoothly filtered or otherwise processed data value stream). In certain embodiments, for example, minor transient behavior from various time steps may not be relevant to how the upsampled data values 7002 are utilized, or timestamp data is further communicated with the message, and thus, in either case where it can be considered whether differential time steps between messages are considered in the process of utilizing the downsampled data 7002, it may be desirable to use the actual data values provided from the first data stream 7006 as the upsampled data values 7002. Thus, in certain embodiments, each message of the upsampled data values 7002 can directly correspond to one or more of the values of the first data stream 7006 (e.g., selecting the synchronized, closest, and / or most recent of the values of the first data stream 7006 (e.g., while holding the communicated value until the next value becomes available)).

[0185] In certain embodiments, it may be desirable to utilize smoothed data values that simulate the time response behavior of underlying data (e.g., the original message 7006), and these data values can be controlled using interpolation / extrapolation data with respect to interpolated data values (e.g., processing in response to the rate of change of upsampled data 7002, such as threshold checking against the rate of change) and / or can also be controlled with respect to non-interpolated data values. In certain embodiments, for example, when downstream processing is particularly susceptible to the time variation of data message 7006 (e.g., the derivative part of a PID controller), it may be desirable to ensure that all upsampled data messages 7002 are generated from the same process and that interpolation / extrapolation operations (and / or smoothing, filtering, and / or moving average values) can be performed to generate both interpolated and non-interpolated upsampled data values 7002. In certain embodiments, non-interpolated upsampled data values 7002 are used directly (e.g., to provide a stream of upsampled data 7002 having the actual content of data message 7006 as much as possible), and interpolated upsampled data values are processed as described herein. In certain embodiments, all original messages 7006 are provided within a stream of upsampled data 7002, and additional non-interpolated messages are added to provide the data rate of the stream of upsampled data 7002 (e.g., to provide all of the original message 7006 and further support the upsampling rate). In certain embodiments, the upsampled data message 7002 can further include metadata or other embedded information indicating whether it directly corresponds to the original data message 7006 or is a processed message (e.g., enabling more than one use with respect to the upsampled data message 7002, diagnostic operations regarding the device providing the original data message 7006, and / or any other purpose).

[0186] In certain embodiments, the interpolated upsampled data value 7002 can be determined based on an expected value between non-interpolated data values, and this determination can be performed based on a virtual sensor (e.g., a model of a value that utilizes other information available within the system) and / or an extrapolation fitting operation. In certain embodiments, the determination of the interpolated upsampled data value 7002 includes, in addition to or instead of this, an expected value and / or an interpolation / extrapolation value that gives a rate of change representation of the interpolated upsampled data value 7002 adjusted according to the characteristics of the device, component, operation, and / or procedure that utilizes the data value 7002 determined and / or upsampled according to the original data value 7006. For example, the upsampling operation can include performing an expectation operation and / or interpolation / extrapolation to determine a rate of change with respect to the value, and a step of giving a final interpolated upsampled data value 7002 that gives an expected rate of change for the interpolated upsampled data value 7002. In certain embodiments, the operation of giving the interpolated upsampled data value 7002 determines a rate of change (or derivative) determination operation within the device that utilizes the interpolated upsampled data value 7002, adjusts the rate of change of the interpolated upsampled data value 7002 in response to a rate of change parameter determination within the device, and interprets, for example, data regarding a time step (e.g., ΔT / 5 ms or every 5 milliseconds per temperature change) and / or a time constant (e.g., the time constant of a low-pass filter, the time constant inherent in a moving average calculation, etc.) utilized in the derivative operation, where the interpolated upsampled data value 7002 is adjusted to give a desired response in the rate of change calculation to be performed on it. For example, when the upsampling operation has a significant time step difference (e.g., 50 ms vs. 5 ms) between the original data value 7006 and the interpolated upsampled data value 7002, operations such as linear interpolation / extrapolation of data values can give significant distortion to the output of, for example, a low-pass filter operated by a device that utilizes the interpolated upsampled data value 7002 configured to process true 5 ms data.Therefore, in this example, the operation of upsampling the original data value 7006 can include the step of adjusting the original data value 7006 according to the expected response of the 5 ms device that determines the value, thereby giving a significant difference compared to simple linear extrapolation, moving average, etc. to the trajectory of the upsampled data value 7002 between the non-interpolated data points. The operation of adjusting the rate-of-change representation can be performed or omitted with respect to the upsampled data 7002 and / or the downsampled data 6906.

[0187] In certain embodiments, whether the original non-interpolated data values 6902, 7006 are directly utilized, metadata stored together with the upsampled data and / or downsampled data 7002, 6906, interpolated data values, and / or processing operations performed on non-interpolated data values, whether all of the original data values 6902, 7006 are communicated, operations providing a rate of change representation of the upsampled data and / or downsampled data 7002, 6906, and / or rate of change determination parameters (e.g., filter constants, differential operations, etc.) within a device that utilizes the upsampled data and / or downsampled data 7002, 6906, such as configuration information regarding the upsampling operation and / or downsampling operation, can be provided to a memory storage location accessible to a controller and / or circuitry that performs the upsampling operation and / or downsampling operation. Any such configuration information can be provided, in whole or in part, during design time, for example, when including a device that communicates with a mobile application and its various networks, and / or can be provided or updated during runtime operation. In certain embodiments, one or more aspects of the configuration information regarding the upsampling operation and / or downsampling operation can be provided as part of a policy, as configuration instructions, and / or as a configuration table that can be made accessible to a CND108 that regulates communication between devices on a separate network of a mobile application. In certain embodiments, one or more aspects of the configuration information regarding the upsampling operation and / or downsampling operation, including configuration instructions and / or a configuration table as part of a policy, can include default values that can be adjusted and / or updated.

[0188] Referring to FIG. 71, an exemplary system for controlling inter-network communication, intra-network communication, and / or extra-vehicle communication using a planned policy scheme is shown. The exemplary system includes a vehicle 102 having a policy management circuit 7106 that interprets a policy 7108 including external data communication parameters such as at least one network (in the example shown in FIG. 71, a first network zone 7102 and a second network zone 7104), an external data path designation description, and / or an external data service description. The exemplary system includes a gatekeeper interface circuit 7120 in response to the policy 7108, and a configuration circuit 7110 that adjusts communication between the endpoints of the network zones 7102, 7104 and an external communication portal 7116. The external communication portal 7116 is selectively coupled to an external device 7118. The external communication portal 7116 includes the external communication portal 7116 shown in this specification including at least any one or two or more of the examples shown with respect to FIG. 41 and the related description. In the example shown in FIG. 71, a gatekeeper interface circuit 7120 coupled to the external communication portal 7116 is shown. However, the gatekeeper interface circuit 7120 can adjust communication in any manner, for example, by further configuring the network interface circuits 7112, 7114 to provide selected communication and / or enable communication having any other adjustment description described throughout the disclosure of the present invention, such as selected processing, encapsulation, data file format, communication protocol, authorization, and / or. In the example shown in FIG. 71, a policy management circuit 7106, a configuration circuit 7110, and network interface circuits 7112, 7114 disposed on the CND 108 are shown. As described elsewhere in this specification, the CND 108 can provide instructions to components or otherwise adjust the components, and the illustrated components (and / or the CND 108) can be distributed at any other location, all or in part, separately from the CND 108 on the vehicle 102.

[0189] Referring to FIG. 72, exemplary policy 7108 includes one or more of secondary policy value 7206, primary policy value 7204, and / or default policy value 7202. Exemplary configuration circuit 7110 responds to default policy value 7202 when there is no (and / or not valid) primary policy value 7204 and / or secondary policy value 7206 (and / or when primary policy value 7204 and / or secondary policy value 7206 is not valid), responds to primary policy value 7204 when there is no (and / or not valid) secondary policy value 7206, and uses secondary policy value 7206 when it exists (and is valid) to include gatekeeper interface circuit 7120. Exemplary configuration circuit 7110 applies the policy in the order that explains it when the policy exists (and / or is determined to be valid) (e.g., uses secondary policy value 7206 if it exists and ignores any remaining policy values 7204, 7202). Exemplary configuration circuit 7110 applies more than one policy value when the policy values are compatible and / or consistent (e.g., applies secondary policy value 7206 and further applies the portion of primary policy value 7204 that does not conflict with secondary policy value 7206). In the example described in FIG. 72, default policy value 7202 can be a permanent storage policy (thus, for example, a policy stored with executable instructions stored on a computer-readable medium including instructions for at least a portion of the operation of CND108 and / or related circuits). In certain embodiments, primary policy value 7204 and / or secondary policy value 7206 can be easily updated in real time, for example, stored as a data file (e.g., provided according to certain naming designations at a selected memory location, a logical location of a selected OS, and / or stored with selected header information, metadata, etc. that identifies each policy value as primary policy value 7204 or secondary policy value 7206), and includes policy values stored as part of a calibration set, trim set, etc.

[0190] The exemplary primary policy 7204 is a tool supplied policy such as a manufacturer tool, an OEM tool, a service tool, etc. In certain embodiments, the secondary policy value 7206 is a downloaded policy value, e.g., a policy value received from an external device through an external communication portal, and a policy value from a web-based tool, a cloud application, etc. The listed examples are non-limiting, and any of the policy values can be received from any external communication portal. The exemplary implementation is provided at the installation of CND108 or a related control component (e.g., the first image file applied to a controller including executable parts such as CND108, the policy management circuit 7106, etc.), and generally is not updated except as part of the overall instruction setting date (e.g., updating the executable instructions provided for CND108 and / or a part thereof), including the default polic...

Claims

1. A vehicle having at least one network zone, a local domain name server (DNS) data structure including local address values for each of a plurality of endpoints of the at least one network zone, an authorization description, an external data service description including a quality of service (QoS) value, and a firewall configuration description, a policy management circuit structured to interpret a policy including the above; a configuration circuit structured to configure a gatekeeper interface circuit in response to the policy; a gatekeeper interface circuit inserted between the at least one network zone and an external communication portal selectively connectable to an external device and further structured to regulate communication between the plurality of endpoints and the external communication portal; A system comprising the above.

2. The system according to claim 1, wherein the local DNS data structure further includes non-local address values for each of the plurality of endpoints of the at least one network zone.

3. The system according to claim 2, wherein the policy further includes an external data volume description.

4. The system according to claim 3, wherein the authorization description further includes an external data access description.

5. The system according to claim 4, wherein the external data access description further includes an external communication permission value for each of the plurality of endpoints of the at least one network zone.

6. The system according to claim 5, wherein the authorization description further includes a policy change authorization description.

7. The system according to claim 1, wherein the firewall configuration description includes at least one of a default behavior description, a data access description, or a data blocking description.

8. The external data volume description is the amount of communication data corresponding to a selected period, the amount of communication data corresponding to selected vehicle operating conditions, the amount of communication data corresponding to a data provider associated with an application, the bandwidth allocation of the external communication portal, the bandwidth volume of the external communication portal, the bandwidth allocation of a channel of the external communication portal, or the bandwidth volume of a channel of the external communication portal, including at least one data restriction selected from the restrictions composed of the above, The system according to claim 3.

9. The system according to claim 1, wherein the QoS value includes a priority value.

10. The system according to claim 1, wherein the QoS value includes a packet delay value.

11. The system according to claim 10, wherein the packet delay value is for the maximum delay.

12. The system according to claim 10, wherein the packet delay value is for the average delay.

13. The QoS value is the maximum dropout time value, the data buffering priority value, or the data life cycle description, and the system according to claim 1 includes at least one of them.

Images