System, method and apparatus for extra-vehicle communications control

Abstract

To provide a system, method and apparatus for extra-vehicle communications control.SOLUTION: An example system includes a vehicle having at least one network zone, and a policy manager circuit that interprets a policy including a local DNS, an authorization description, and a firewall configuration description. The system includes a configuration circuit that configures a gatekeeper interface circuit in response to the policy, where the gatekeeper interface circuit is interposed between one of the network zones and an external communication portal, and regulates communications between end points of the network zone and the external communication portal.SELECTED DRAWING: Figure 73

Description

[Technical Field]

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

[0002] Each of the above-referenced applications is incorporated herein by reference in its entirety. [Background technology]

[0003] Vehicle communication networks are utilized to connect sensors, actuators, controllers, and communication devices throughout a vehicle. Recent trends of more connected devices, more data passed between devices, lower latency requirements to meet vehicle performance, safety, and emission requirements, and added vehicle features are increasing the strain on these vehicle communication networks. In addition, consumers expect ever-increasing connectivity and functionality, which increases the strain on vehicle communication networks. These trends are expected to continue and accelerate for the foreseeable future.

[0004] Conventional vehicle communication networks (e.g., CAN, LIN, FlexRay, MOST, LVDS, etc.) have several drawbacks and challenges. These vehicle communication networks were developed to meet the specific challenges of the vehicle environment and, therefore, were developed separately from other networks such as computer local area networks, wide area networks, large-scale interconnection networks (e.g., the Internet), and wireless networks. Most vehicle networks utilize robust and specialized equipment such as a controller area network (CAN) bus, which consists of a data link layer and an application layer and has dedicated or shared wiring between devices using specific data protocols (e.g., J1939, OBD, etc.). Modern vehicles may have multiple network buses, each with specific command and communication capabilities and limited customization and data speeds. For example, a CAN bus typically operates at up to about 1 Mbps, while advanced CAN buses operate at up to about 10 Mbps. In addition, a CAN bus experiences latency greater than 25 ms, typically from about 60 ms to 500 ms, depending on the configuration, traffic on the CAN, and the priority of specific messages.

[0005] As the number of devices and data rate demands from the devices increase, traditional vehicle communication networks require higher performance bus implementations. Because the automotive industry is a high-volume industry with very low tolerance for component failure, vehicle manufacturers utilize the same components over long periods of time and across a wide range of vehicles, including sharing of components between manufacturers. In addition, changing to components of nominally higher functionality may introduce risk, integration costs, recertification burdens for a given application, or have other undesirable consequences to the system. Therefore, even as vehicle communication networks migrate to higher functionality network configurations, it is desirable to keep network types separated within the system and maintain a large number of legacy devices (e.g., CAN-enabled ones) within the system over the long term.

[0006] Data collection from vehicles involves several additional challenges. For example, data collection operations are subject to regulatory and liability risks, particularly 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 proprietary rights to sensitive data, are at risk while in possession of the data, for example, in the event of inadvertent or malicious access to the data. With respect to vehicle data being collected, large amounts of data may be collected and there may be multiple purposes for collecting the data, increasing risk compared to other common data storage applications. Therefore, it may be desirable to control data collection, storage, and access to reduce risk, and may further be desirable to include data access verification and partitioning or other elimination of data when it is not being used.

[0007] Vehicle-related data collection is further complicated by the volume and type of data that must be communicated between the vehicle and external devices, with the vehicle's networked systems being limited by the constraints of mobile applications, costs, and / or bandwidth limitations imposed by high data rates and / or large data transfers. Nevertheless, customer demands, market expectations, increasing requirements for the efficiency of vehicle operation, and increasing functional capabilities of data-related applications continue to rapidly increase the total amount of data that must be transferred, the number of off-vehicle applications that utilize the transferred data, the number of purposes for which the data can be utilized, and the number of users or entities with legitimate needs for each portion of the transferred data. Additionally, the applications that utilize the data continue to grow in sophistication and capability, increasing data demands on limited available transfer resources and increasing the cost and complexity of logistical control and storage of the transferred data. For example, more sophisticated routing or operational algorithms associated with vehicles, increasing automation of vehicle functions, increasing demands for predictive decisions and / or maintenance support, and increasing media streams (both the number of media streams and the quality of those media streams) are all driving increasing demands on data rates, the amount of stored data, and the number of entities or applications accessing the stored data. Summary of the Invention

[0008] The description herein refers to vehicle applications as a non-limiting example and for clarity of the description. However, embodiments herein are applicable to other applications having similar challenges and / or implementations. Without being limited to any other applications, embodiments herein are applicable to any application that has multiple end points, including multiple data sources, controllers, sensors, and / or actuators, and may further include end points that reside in distinctly different and / or distributed network environments, and / or to applications that have historical or legacy network-connected or communication systems (within a given system, as a division of a system, and / or as an industry) that may be transitioning to newer and / or more capable network-connected or communication systems. Exemplary, non-limiting embodiments include one or more of industrial equipment, robotic 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. It will be understood that certain features, aspects, and / or advantages of the present disclosure may be applicable to any one or more of these applications and not to others of these applications, and that the applicability of certain features, aspects, and / or advantages of the present disclosure may vary depending on the operating conditions, constraints, and cost parameters of a particular application (e.g., operational costs, integration costs, operation costs, data communication and / or storage costs, service costs, and / or downtime costs, etc.). Accordingly, it will be understood by one of ordinary skill in the art having the benefit of the present disclosure that whenever the present disclosure makes reference to vehicles, vehicle systems, mobile applications, industrial equipment, robotic systems, and / or manufacturing systems, each of these is also contemplated herein and may be applicable in certain embodiments or inapplicable in certain other embodiments.

[0009] The disclosure herein, as reflected in the described embodiments, recognizes that the above-listed complexities and other challenges have a synergistic effect that makes the complexity of the vehicle data environment greater than the sum of the individual contributions from each challenge.

[0010] As one example, increasing the number of entities or applications accessing data increases the likelihood that individual data requests will be repetitive, for example, when multiple entities request the same or similar data. Furthermore, increasing the number of entities or applications accessing data increases the likelihood that members of a group of entities or applications will share similar authorization levels, such that data access for individual members of these access groups will benefit from data management.

[0011] In another example, regulations regarding sensitive data are increasing, which not only generally increases the data management requirements of systems, but also increases the likelihood that data management will be subject to multiple constraints at a given time and / or constraints that change over time as regulations change and / or constraints that change based on the applicable jurisdiction, which may change as the location of the vehicle changes.

[0012] In yet another example, the complex environment of currently known and evolving vehicle network architectures, e.g., vehicles with mixed network types and / or split networks, increases the complexity of data access for individual entities, which, without certain aspects of the present disclosure, may otherwise require determining request parameter specifications for particular 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. Additionally, the trajectory of additional entities requesting data access is moving towards entities located further away from the core vehicle functionality in the technical knowledge space, and thus the complexity and specificity of vehicle applications and / or vehicle applications, including on-vehicle network configurations, specific data descriptions, data request and communication protocols, and industry norms or practices for providing information, etc., are becoming increasingly unfamiliar to each new entity, further increasing the cost-volume function (e.g., the cost over time for a given entity, which may be an automobile manufacturer and / or vehicle market, a geographic market, and / or an industry, such as the automotive industry, passenger car industry, etc., to reach the desired data collection deliverable). For example, COST = Number of entities * Basic learning costs * Transitional adaptation cost trajectories * Data Trajectory Cost * Regulatory compliance costs * Data access / storage liability costs Consider a nominal cost-volume function such as

[0013] The described COST functions are non-limiting, nominal examples intended to illustrate how various challenges and drawbacks associated with currently known systems interact to create synergies that increase the cost of reaching future data collection capabilities for vehicle applications. The described cost parameters are not intended to encompass all costs associated with the automotive data collection industry or challenges that exist with currently known systems. The parameters can be averages or other complex functions, and the values ​​of specific parameters generally will not be known by specificity. Additionally, the units of COST can be expressed as a monetary value for resources (e.g., man-hours, computing time, etc.) to reach a data collection target over time, or as another non-monetary unit such as carbon dioxide equivalents, customer satisfaction, risk incurred, or public perception loss or gain. The entity count parameter generally reflects the number of entities accessing vehicle data over time; basic learning cost reflects the cost for a new entity to learn the data collection requirements and protocol details for a particular vehicle, vehicle type, market, etc.; transition adaptation cost trajectory reflects the cost of adapting to changing vehicle network configurations, including network types and organizations, and interactions with endpoints or devices on these networks; data trajectory cost reflects increasing demands on data collection from corresponding vehicles over time, including data communication, storage, and ramifications such as an inability to support desired applications or costs to improve data communication infrastructure; regulatory adaptation cost reflects the costs associated with an increasing number of regulations, an increasing number of regulatory frames, and / or an increasing number of regulatory authorities; and data access / storage liability cost reflects the costs incurred regarding data compliance and security, and / or losses incurred due to data breaches, unauthorized use, and premature expiration of data, etc.

[0014] Without being limited to any other aspects of the present disclosure, aspects of the disclosure herein reduce and / or eliminate any one or more of the following: the cost per entity added to a data collection system; the basic learning cost for a new entity to implement an application that utilizes collected data; the cost of adapting to a changing vehicle network configuration; the cost incurred to meet increasing demands for data collection; the cost of adapting to a changing regulatory environment; and / or the cost of protecting data and / or losses incurred due to infringement or unauthorized use. Certain embodiments and / or aspects of the disclosure herein may satisfy one or more of the described cost parameters. Certain embodiments and / or aspects of the disclosure herein may increase one or more given cost parameters but still be beneficial by reducing the overall cost function for a target vehicle, vehicle type, entity, industry, etc. Certain embodiments and / or aspects of the disclosure herein may increase one or more given cost parameters but provide other benefits, such as improved functionality. In certain embodiments, the improved functionality may be achieved at a higher cost but at a lower cost than previously known systems configured to achieve similar improved functionality.

[0015] Without being limited to any other aspect of the present disclosure, embodiments herein provide for the configuration of inter-network, intra-network, and off-vehicle communication control utilizing off-vehicle devices such as cloud applications, web-based tools or applications, manufacturing tools, OEM tools, or service tools. Embodiments herein provide for the execution of active diagnostics, active testing, vehicle control operations, and / or active assistance operations, including operations involving flows, applications, services, and / or vehicle functions, including both on-vehicle and off-vehicle aspects and / or participating devices. Embodiments herein provide for convenient monitoring, diagnosis, and configuration of inter-network, intra-network, and off-vehicle communications, including communications traveling between endpoints, between networks, and / or to external devices, and further including communications involving associated endpoints associated according to associated flows, vehicle functions, applications, services, source and / or destination addresses, and / or source and / or destination ports. Embodiments herein provide for the aggregation (physical and / or logical) of off-vehicle communication control, coordination, data management, security enforcement, authorization enforcement, permission enforcement, service enforcement, and / or subscription enforcement. Embodiments herein provide for policy scheduling, including updating policies, adjusting policies, and / or checking authorization for changes to policies. Embodiments herein provide for communication service level scheduling and / or QoS enforcement, including for communications associated with endpoints, flows, applications, vehicle functions, vehicle controllers, service groups, and / or external communication portals. Embodiments herein provide for data usage scheduling, including utilization of specific external communication portals, APNs, and / or data service providers. Embodiments herein provide for adjustment of external communication portals with respect to off-vehicle communications to reduce costs, improve service levels, and / or limit and / or reduce data usage of specific external communication portals, improve the overall functionality of off-vehicle communications to support the vehicle mission, and / or make such adjustments transparent to communication devices (e.g., local communication devices and / or external devices, applications, and / or tools).

[0016] For the purposes of facilitating an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the drawings and described in the following specification. It will be understood that no limitation on the scope of the present disclosure is intended by this reference. It will be further understood that the present disclosure includes all variations and modifications to the illustrated embodiments and further applications of the principles disclosed herein which would normally occur to one skilled in the relevant art. [Brief explanation of the drawings]

[0017] [Figure 1] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 2] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 3] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 4] 1 is a schematic diagram of a centralized network device (CND). [Figure 5] 1 is a schematic diagram of a centralized network device (CND). [Figure 6] 1 is a schematic diagram of a centralized network device (CND). [Figure 7] 1 is a schematic diagram of a centralized network device (CND). [Figure 8] 1 is a schematic diagram of a centralized network device (CND). [Figure 9] 1 is a schematic diagram of a centralized network device (CND). [Figure 10] FIG. 1 is a schematic diagram of a configurable Ethernet switch. [Figure 11] FIG. 1 is a schematic diagram of a configurable edge gateway. [Figure 12]FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 13] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 14] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 15] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 16] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 17] FIG. 1 is a schematic diagram of a CND. [Figure 18] FIG. 1 is a schematic diagram of an end point of a network responsive to actuator command values. [Figure 19] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 20] 1 is a schematic diagram of a system for providing visualization data of a network of vehicles. [Figure 21] FIG. 2 is a schematic illustrative embodiment of a local DNS table. [Figure 22] FIG. 2 is a diagram of a schematic illustrative example of vehicle communication data. [Figure 23] FIG. 1 is a diagram of a schematic illustrative example of visualization data. [Figure 24] FIG. 1 is a diagram of a schematic illustrative example of visualization data. [Figure 25] FIG. 1 is a diagram of a schematic illustrative example of visualization data. [Figure 26] FIG. 1 is a diagram of a schematic illustrative example of visualization data. [Figure 27] FIG. 1 is a diagram of a schematic illustrative example of visualization data. [Figure 28] 1 is a schematic diagram of a system for coordinating an on-vehicle network according to certain embodiments of the present disclosure. [Figure 29]FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 30] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 31] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 32] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 33] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 34] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 35] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 36] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 37] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 38] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 39] FIG. 2 is a schematic illustrative embodiment of a local DNS table. [Figure 40] FIG. 2 is a schematic illustrative embodiment of a local DNS table. [Figure 41] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 42] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 43] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 44] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 45] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 46]1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 47] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 48] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 49] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 50] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 51] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 52] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 53] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 54] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 55] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 56] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 57] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 58] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 59] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 60] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 61] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 62] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 63] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 64] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 65] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 66] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 67] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 68] FIG. 10 depicts an exemplary operation for processing a message. [Figure 69] FIG. 10 depicts an example operation for downsampling a message. [Figure 70] FIG. 10 depicts an example operation for upsampling a message. [Figure 71] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 72] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 73] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 74] FIG. 1 is a diagram of a schematic illustrative embodiment of a policy. [Figure 75] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 76] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 77] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 78] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 79] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 80] 1 is a schematic flow diagram illustrating an exemplary procedure for coordinating vehicle communications. [Figure 81] 1 is a schematic diagram of a system for coordinating off-vehicle communications in accordance with certain embodiments of the present disclosure. [Figure 82] FIG. 2 is a schematic diagram of a visualization management controller. [Figure 83] 1 is a schematic flow diagram of a procedure for providing visualization data. [Figure 84] 1 is a schematic flow diagram of a procedure for updating a policy. DETAILED DESCRIPTION OF THE INVENTION

[0018] Referring to Figure 1, an exemplary system generally illustrates aspects of an embodiment of the present disclosure. The exemplary system includes an application 102 (e.g., a vehicle) having a first network 104 and a second network 106. As used herein, a network should be understood broadly and can 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, stranding arrangement, coaxial arrangement, etc.), implementation of any layers (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 distinctly different manner), and / or can be all or partially wired or wireless. Without being limited to any aspect of the present disclosure, exemplary, non-limiting networks include a Controller Area Network (CAN), a Media Oriented Systems Transport (MOST) network, a Local Interconnect Network (LIN), a FlexRay network, a Time Triggered Protocol (TTP) network, a Low Voltage Differential Signaling (LVDS) network, and / or an Ethernet implementation network. In certain embodiments, one or more networks can be an electrical signal zone (e.g., a device that provides data and / or receives commands as electrical signals such as voltage values, frequency values, and indicated resistance values) such as a sensor or actuator electrically coupled to an interpreting device, which has the capability to receive information from and / or pass 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 should be understood broadly and include networks having different protocols, at least one layer that is distinctly different from each other (e.g., having a distinct application layer, presentation layer, etc.), two networks that are not operationally compatible (e.g., a device coupled to one of the networks will not function on the second network without modifications to connections, communications, or other aspects), and / or two networks that are not message compatible (e.g., a message designed for the first of the networks cannot be directly carried 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 implementation network and a second network 106 that is 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 interposed between the first network 104 and the second network 106 and structured to facilitate communication between the first network 104 and the second network 106. The CND 108 interposed between the networks 104, 106 passes communications between the networks 104, 106, including embodiments that receive communications from the first network 104 and transform the communications destined for the second network 106 (e.g., encapsulating all or a portion of the communications into a message for the second network 106, and / or transforming aspects of the communications such as device addresses, bit depth for the data, and / or unit values ​​for the data, and / or adding or removing aspects of the communications such as priority information, message delivery requests or requirements, industry standard information such as message identifiers, etc.). In certain embodiments, the CND 108 may not physically pass communications or may pass only portions of communications, but may otherwise control other devices (e.g., switches, routers, gateways, or repeaters) that regulate, manage, grant permissions, throttle messages, or otherwise perform operations to pass communications between networks. Thus, a CND 108 inserted between networks 104, 106 may, in certain embodiments, be physically located between networks 104, 106, and communications to and from networks 104, 106 may be physically received by components of the CND 108. In certain embodiments, a CND 108 inserted between networks 104, 106 may have visibility into communications on networks 104, 106 and a control device to regulate message passing between these networks. In certain embodiments, a CND 108 inserted between networks 104, 106 may have visibility of endpoints on networks 104, 106 and a control device for coordinating the passing of messages between the endpoints of each network 104, 106.

[0021] One skilled in the art, having the benefit of the present disclosure and the information normally available when considering a particular system, can readily configure CND108 according to one of the above intervention schemes and / or a combination of more than one of these intervention schemes.Certain considerations when designing an intervention scheme for CND 108 for a given system include the number and type of networks on the vehicle, the capabilities of each network (e.g., throughput, bandwidth, address availability, broadcast / unicast / multicast availability and desirability of each network and / or endpoint on the network, acknowledgment 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 networks implementing multiple controllers (e.g., presence and ownership of switching devices, access to instructions such as firmware or buffers for available devices, and / or connectivity of available devices to one or more networks, e.g., desired messages to and from networks, desired redundancy, and / or desired failure mode response), the capabilities of networks implementing multiple controllers (e.g., buffer sizing, These aspects may include, but are not limited to, hardware cost considerations for adding CND-specific components to the system, hardware cost considerations for providing functionality for CND operation within other components of the system, integration cost considerations and system functionality for implementing additional CND-specific components and / or adding functionality for CND operation within other components of the system, the number, type, and / or message throughput of endpoints utilizing inter-network communications, expected changes in any one or more of these aspects over the life of the vehicle (e.g., due to service events, upgrades, and / or campaign events such as product recall events for the vehicle), and / or expected changes in any one or more of these aspects over the life cycle of the associated vehicle fleet (e.g., associated vehicle fleet, vehicle model year, and / or model year group associated with the system, e.g., multiple vehicles expected to have similar network infrastructure but with changes in device distribution, modifications to the network, etc.).

[0022] 1 , the first external device 110 is shown as communicatively coupled to the application 102. The first external device 110 is directly coupled to the application 102, and this coupling may include a directional wired connection (e.g., to a service port, an OBD port, or other available connection) and / or a wireless connection (e.g., a WiFi connection such as an IEEE 801.11 compliant connection and / or a Bluetooth connection). The first external device 110 may be connected to a particular network (the first network 104 or the second network 106) and / or may be connected to another device that directly manages communications with the external device 110 (e.g., the CND 108 and / or devices coordinated thereby). Regardless of whether the external device 110 is coupled to a network 104, 106 or another device such as the CND 108, in certain embodiments, the CND 108 has the capability to manage communications so that the external device 110 receives only authorized communications, and further manage communications so that the external device 110 can request communications from endpoints on either network 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 shop tool, and / or an application (e.g., an application that communicates through a computing device such as a laptop, desktop, mobile device, and / or mobile phone, e.g., an application operated by an owner, service technician, fleet manager, or the like).

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

[0024] As used herein, endpoint should be understood broadly. An endpoint is an organizational concept for accessing a vehicle's network 104, 106 and can include a particular device (e.g., engine controller, transmission controller, door controller, infotainment system, etc.), a group of devices with single network access (e.g., multiple devices communicate with each other through a single network access point, in which case the network 104, 106 and / or CND 108 may have visibility to the individual devices or may only have visibility to communications from the endpoint as a group). For example, a door controller (not shown) may be an endpoint for one of the networks 104, 106, with communications for underlying devices (e.g., door position sensor, door lock actuator and position sensor, window actuator and position sensor, etc.) traveling through the door controller endpoint to the network 104, 106, in which case the CND 108 may have visibility to the underlying devices (e.g., a door position message including an identifier that the door position sensor is about to send a message) or may have visibility only to the door controller endpoint (e.g., it is known that a door position message is provided by the door controller, but the CND 108 does not know which underlying device may have sent the message). One skilled in the art, having the benefit of this disclosure and with information typically available for the system under consideration, can readily determine which devices in the system are endpoints for each network 104, 106.Certain considerations for determining endpoint placement include, but are not limited to, the availability of hardware ports on the network, the distribution of vehicle controllers, the messages passed between vehicle controllers, the tuning options set forth in this disclosure and made available for a given endpoint (e.g., message rate, priority, data collection, message configuration, component ID information, addressing management between networks and with external devices, etc.), the desired granularity of data control (e.g., permission for particular devices to provide or request information, permission for applications either within 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 redundancy options made available for a given system (e.g., redundancy of network communication functions, redundancy of control operations and related devices, and / or redundancy of CND operations if CND components are distributed in more than one location on the vehicle).

[0025] As used herein, the term "application" should be understood broadly. Exemplary applications include a group of related vehicle functions or operations, such as speed control (e.g., of a vehicle or subcomponents thereof, e.g., engine or driveline), anti-lock braking system (ABS) operation, advanced driver assistance systems (ADAS), performance control (e.g., providing torque, speed, or other performance requests from the driver), or other vehicle functions. Exemplary applications include a group of non-vehicle related functions, such as applications for supporting positioning and / or navigation, requesting and / or processing service information related to the vehicle, and / or third-party applications that interact with the driver (e.g., to find the nearest hotel, selected events, etc.). Applications may be implemented by the vehicle manufacturer, supplier, contract manufacturer, body manufacturer, third party, driver, service technician, or similar. As used herein, an application provides an organizing concept that can be utilized to associate certain data, certain destinations, and / or related functions of the vehicle. In certain embodiments, CND 108 can identify data sources, data destinations, permissions available to an application, or priority information about an application, etc., and utilize the application to perform certain data regulating operations described herein.

[0026] As used herein, the term "flow" should be understood broadly. Exemplary flows include related data (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related functions (e.g., additional functions within vehicle functions, such as service operations and / or data collection, aggregation among related vehicles, and / or combinations thereof for a particular system), related devices (e.g., door actuators), and / or related applications. As used herein, a flow provides an organizational concept that can be used to associate certain data, certain endpoints, certain applications, and / or related functions, whether vehicle or otherwise. In certain embodiments, the CND 108 can utilize flows to identify data sources, data destinations, permissions available for a flow, or priority information related to a flow, and perform certain data coordination operations described herein. In certain embodiments, the utilization of flows allows the CND 108 to perform separate operations that may involve the same endpoint to support desired network management. For example, a vehicle speed management application may have a high priority, and a speedometer endpoint may be associated with the vehicle speed management application. In this example, if the vehicle speed is communicated to support a vehicle speed management application, the CND 108 gives a higher priority to the vehicle speed message. However, if the vehicle speed is communicated to support a journey planning flow (e.g., if a journey planning flow is present but does not have a high priority), the CND 108 can give a lower priority to the vehicle speed message. In yet another example, a failure of a vehicle controller, portion of the network, or other off-nominal condition may result in the vehicle speed management application migrating to another controller in the system, whereby the vehicle speed message is communicated to support the vehicle speed management application (e.g., if a backup controller is on a different network), and the CND 108 can give a higher priority to the vehicle speed message.The use of flows and applications to organize the components of the system allows the CND 108 to coordinate the same or similar information in a differential manner to support various functions, providing improved performance and security of network coordination operations (e.g., reducing unnecessary inter-network traffic, providing only necessary information, and / or coordinating communications with external devices), and supporting additional functionality such as redundancy support, distributed control, and fine-grained inter-network messaging compared to previously known systems.

[0027] As used herein, the term "services" should be understood broadly. Exemplary services include related applications for a vehicle. The related applications (e.g., one or more vehicle systems, functions, or other applications of the vehicle) may be located entirely on the vehicle and / or on external devices (e.g., supporting processing, data collection or storage, service use of external source data, etc.), and may include aspects that may be web applications, web tools, cloud applications, service applications, etc. In certain embodiments, any local communication devices may be logically associated as services. The use of services to organize system components and / or applications allows the CND 108 to differentially coordinate the same or similar information to support various functions, providing improved performance and security of network coordination operations (e.g., reducing unnecessary inter-network traffic, providing only necessary information, and / or coordinating communications with external devices), and supporting additional functionality such as redundancy support, distributed control, and fine-grained inter-network messaging compared to previously known systems.

[0028] As used herein, and not limited to any other aspect of the present disclosure, a coordinated component includes any system component that is coordinated with respect to communications, including data collection, subscription, data request, access to external devices and / or addresses, access to network zones, access to endpoints, utilization of communications resources (e.g., network zone bandwidth, external communications portals, total data limits or amounts, etc.) A coordinated component includes, but is not limited to, one or more of an endpoint, a flow, an application, a controller, a set of services, an interface circuit, a network zone, an external communications portal, an external device, a source address, a destination address, a vehicle function, an entity associated with any of these, a user associated with any of these, and / or a user role associated with any of these.

[0029] Exemplary operations for coordinating communications between endpoints in a network zone and / or coordinating communications with external communication portals and / or external devices include, but are not limited to, operations described below. Coordinating operations can be performed on an endpoint, on associated endpoints, and / or on a network zone. Associated endpoints can be associated according to a flow, an application, a set of services, a controller, a vehicle function, a source address for the communication, and / or a destination address for the communication. In certain embodiments, applications, services, and / or flows can be provided with identifiers as an implementation for associating associated components such as endpoints. Coordinating operations can be performed by, but are not limited to, a CND, a network gateway, a network interface circuit, and / or a gateway interface circuit. Although coordination operations are described throughout this disclosure in the context of certain exemplary coordinating devices, embodiments can be configured with other devices that perform the coordination. Exemplary communication and / or coordination operations include: Providing communication (bidirectional) between a first endpoint and a second endpoint, including configuring the communication (e.g., protocol, message information, metadata, parameter units, etc.) to a receiving network zone and / or 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 associated flow) on one of the network zones has permission to request communication from a device on another of the network zones, and providing the communication in response to the permission determination; adjusting at least one of the data rate, the required resolution, and / or the required response time of communications between devices of these network zones based on the authorization decision for the requesting device, the communication capabilities of the requesting device and / or the provider device, and / or the network performance parameters of one or both network zones (e.g., current available bandwidth, absolute or current network capabilities, network utilization, etc.), and / or a priority value for communications associated with the requesting device (and / or the associated flow); performing upsampling and / or downsampling operations on the data communicated between the network zones, mirroring communications from a first endpoint to a port in a second network zone, including encapsulating, structuring, processing, and / or upsampling or downsampling the mirrored communications; providing the communication from the first endpoint to 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, and / or providing the communication includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communication, and / or the provided communication may be unicast, multicast, and / or provided as a subscription service; providing the communication from the second end 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 providing the communication may include encapsulating, structuring, processing, and / or upsampling or downsampling the provided communication, and / or may unicast, multicast, and / or provide the provided communication as a subscription service; providing communications from devices coupled to the second network zone 1904, e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices, to the first endpoint, and / or providing the communications may include encapsulating, structuring, processing, and / or upsampling or downsampling the provided communications, and / or may unicast, multicast, and / or provide the provided communications as a subscription service; For example, further providing a communication as a command value that causes the first endpoint to perform an operation related to the mission of the mobile application in response to the command value (e.g., setting a setpoint, target value, or threshold in response to the command value); providing communications from devices coupled to the second network zone, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices, to the first endpoint, and / or providing the communications includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communications, and / or the provided communications may be unicast, multicast, and / or provided as a subscription service; For example, the first endpoint may further provide a communication as a test execution value, which executes an operation related to an active text execution operation of the mobile application in response to the command value (e.g., performing a certain operation for a service test or an active diagnostic operation, etc.); providing communications from the first endpoint to a number of second endpoint devices, the provided communications being configured to satisfy a superset of the requirements (e.g., data rate, resolution, units, etc.) of the second endpoint devices, and the provided communications may be unicast, multicast, and / or provided as a subscription service; parsing communication values ​​from a first device (e.g., a first endpoint, a second endpoint, and / or a device coupled to the network zone, e.g., 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 responsive to the communication value) responsive to the parsed communication value; and configuring the communication of the target communication destination and / or communication provider responsive to the parsed communication value; e.g., the communication value may include generic and / or standard component identifiers (e.g., turbine temperature, front passenger door actuator, etc.), and the CND may determine respective endpoints corresponding to the component identifiers according to a current configuration of the mobile application, and further determine routing, encapsulation, and processing of the communication to translate between the first device and the target device, etc. For example, such operations may enable devices, service personnel, or other requestors to change the configuration and placement of devices on the network zone without needing to track the specific configuration and placement of the devices; Additionally or alternatively, such operations may include the CND storing configuration information responsive to configuration changes (e.g., replacement or movement of a device from one network zone to another, changes to communication parameters or communication capabilities of the device, etc.) and / or performing runtime decisions to establish device location, identity, configuration, communication parameters, and / or communication capabilities that can be utilized during runtime operations, stored for later use, and / or stored as a default configuration subject to further updates; performing any one or more of the operations described above with respect to a group or subgroup of devices, for example, where multiple devices are aggregated with respect to a single endpoint, but other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) communicating with the network zone can be treated as separate devices, e.g., where a first configuration has two (or more) devices using separate endpoints and a second configuration has two (or more) devices (and / or two devices aggregated into a single device) utilizing a single endpoint; an exemplary and non-limiting embodiment may perform any one or more of the operations described above with respect to a group or subgroup of devices, for example, where multiple devices are aggregated with respect to a single endpoint, but other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) communicating with the network zone can be treated as separate devices, e.g., where a first configuration has two (or more) devices using separate endpoints and a second configuration has two (or more) devices (and / or two devices aggregated into a single device) utilizing a single endpoint; including aggregating sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) and / or exchanging interfaces of multiple components behind a single network interface (e.g., a single communication device such as an edge gateway or configurable edge gateway that interfaces to a single network zone as a single endpoint and manages communications for associated devices); in yet another example, such operation enables devices to communicate across multiple network zones despite configuration changes, supports upgrades and updates regarding device associations with endpoints, supports backward compatibility (e.g., later configurations and later inter-device control distribution when an earlier system with a distinctly different configuration is enabled to support the latest configuration and / or inter-device control distribution, etc.); Additionally or alternatively, such operations may include the CND storing configuration information responsive to configuration changes (e.g., involvement of a single endpoint between more than one device and a network zone, aggregation of devices, etc.) and / or performing runtime decisions to establish device locations, identities, configurations, communication parameters and / or communication capabilities and / or aggregation status of devices that can be utilized during runtime operations, stored for later use, and / or stored as a default configuration subject to further updates; performing any one or more of the operations described above with respect to a group or subgroup of devices, for example, where the devices are distributed among more than one endpoint, but other endpoints or devices in communication with the network zone (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) are able to treat the devices as a single device; e.g., where a first configuration includes devices using a single endpoint and a second configuration has devices (or a portion thereof) utilizing more than one endpoint (and / or devices that were previously aggregated to form two or more separate devices in the second configuration), such operations may include multiple configurations, updates to a mobile application, , and / or upgrades, and exemplary and non-limiting embodiments include separating a group of sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) that communicate to a network zone through a single endpoint into one or more sensors (and / or subgroups of multiple sensors each with a separate endpoint), and in yet another example, such operation enables devices to communicate across multiple network zones despite configuration changes, supports upgrades and updates regarding device associations with endpoints, supports backward compatibility (e.g., later configurations and inter-device control distribution where operation of the CND enables an earlier system with a distinctly different configuration to support a later configuration, etc.); Additionally or alternatively, such operation may involve the CND storing configuration information responsive to configuration changes (e.g., splitting multiple devices behind a single endpoint on a single network zone into more than one endpoint and / or splitting across more than one network zone), and / or performing runtime decisions to establish device locations, identities, configurations, communication parameters and / or communication capabilities, and / or aggregation status of devices, which may be utilized during runtime operation, stored for later use, and / or stored as a default configuration subject to further updates; Implementing a service specification architecture in which the CND determines available services (e.g., data parameters available for communication, command values ​​available for execution, and / or configurations thereof, e.g., rate information, units, resolution, precision, accuracy, availability descriptions, dependent data, and / or operating conditions), publishes available services, and / or determines subscribed clients (e.g., devices, flows, and / or endpoints) for available services; Additionally or alternatively, such operation may include the CND determining permission and / or authorization to publish the available services, to view the available services (and / or portions of the available services) and / or to subscribe to the available services, Additionally or alternatively, such operation may include the CND determining the subscribed entity as an endpoint, device, flow, and / or external device, e.g., a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device; Additionally or alternatively, such operation may include the CND determining a priority of service-specific communications, which may depend on the publishing device, endpoint, or associated flow, and / or on the subscribing device, endpoint, or associated flow, Additionally or alternatively, such operation includes the CND adjusting service specification architecture operation in response to operating conditions (e.g., mobile application operating conditions, network status of one or more affected network zones, communication status of one or more external devices, etc.); Additionally or alternatively, such operation includes the CND accessing stored information indicating available services, public parameters (permissions, priorities, associated operating conditions, etc.), and / or subscription entity information; Additionally or alternatively, such operations include the CND updating the stored information in response to one or more of: received updates such as policy descriptions, service configuration descriptions, runtime updates from endpoints, devices, and / or flows, for example but not limited to, performed during operations such as starting or stopping a mobile application; Additionally or alternatively, such operations include the CND implementing a service specification architecture based on run-time operations with or without storing information and / or updating stored information; and / or Additionally or alternatively, enabling updates to stored information, run-time updates to stored information, and / or run-time operations implementing a service specification architecture in response to priorities and / or permissions for devices, endpoints, and / or flows requesting the updates and / or run-time implementation; Additionally or alternatively, operation of the exemplary CND may include adjusting any one or more of the above-described operations in response to operating conditions of the mobile application (e.g., adjusting communication operations during certain operations such as high power operation, high transient operation, stop operation, start operation, selective operating modes, e.g., vocational operation, power take-off (PTO) operation, charging operation, cruise control operation, autonomous vehicle operation), where the adjustment to communication may be qualitative (e.g., allowing or disallowing certain communication types, certain communication priority thresholds, etc. during certain operating conditions, and / or during certain operating conditions as data capture events). the communication control may be quantitative (e.g., capturing a certain data value), quantitative (e.g., controlling communication speed, network zone utilization, external device communication speed, etc.), or a combination thereof (e.g., controlling communication speed for certain communication types, etc.), and may include steps to increase or decrease communication capabilities according to operating conditions and / or communication types (e.g., allowing a device to reduce communication capabilities during shutdown operation, but increasing communication capabilities of an external device during the shutdown operation, increasing a device's communication capabilities for certain devices or flows, but reducing the device's communication capabilities for other devices or flows during startup operation); Additionally or alternatively, exemplary CND operations may include performing any one or more of the operations described above in response to degradation of a network zone (e.g., loss of yield, loss of communication with one or more endpoints in the network zone, injection of noise onto or presence of noise on the network zone, physical failure of at least a portion of the network zone, etc.), a fault condition of one or more devices (e.g., the CND adjusts a data source for the failed device, adjusts a data rate for the failed device, implements a backup data source for the failed device, reroutes data to a backup data destination for data provided to the failed device, etc.), and / or adjusting in response to abnormal operating conditions related to the mobile application, including conditions such as: (e.g., implementing an event-driven data collection scheme where a device failure is an event); loss of control function of the vehicle controller (e.g., when the loss of control function indicates that the vehicle controller lacks a data value to perform its mission, when the loss of control function indicates that the vehicle controller has lost communication with the connected network zone, 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 is unable to perform its mission or a portion thereof); and further example operations of the CND include one or more of the following in response to the abnormal condition: providing data values ​​to the vehicle controller from an alternative source (e.g., the data values ​​are from a different endpoint, network zone, etc., and this providing may include encapsulating, structuring, processing, and / or upsampling or downsampling the communications of the alternative source, thereby resulting in a communication equivalent to the original data value that was lost, or a replacement communication that may suffice as a back-up data value for the vehicle controller); providing data values ​​to the second vehicle controller together with alternative source communications (e.g., having a distinctly different data rate, resolution, units, precision, etc.) or other data values ​​(e.g., where the second vehicle controller utilizes a distinctly different data set to perform full-featured or alternative operations) to replace all or part of the vehicle controller's lost control functions, for example, where the second vehicle controller is configured to act as a backup to the vehicle controller and may be fully capable of performing the lost control functions and / or may be capable of performing alternative operations (e.g., with more limited functionality) in place of the lost control functions, and the data values ​​provided to the second vehicle controller may be the same as the data values ​​provided to the vehicle controller; additionally or alternatively, the CND provides data from any network zone to the vehicle controller and / or second vehicle controller that may be on any network zone; suppressing communication of one or more data values ​​in response to an abnormal condition, for example, where a fault condition or loss of a device or endpoint indicates that one or more data values ​​are unavailable, where one or more data values ​​are of low priority as determined from the abnormal condition, and / or where one or more data values ​​are indicated as invalid as determined from the abnormal condition (e.g., sensor values ​​from a sensor have a fault condition or failure state); shifting communications from a first network zone (e.g., a degraded network zone) to a second network zone when the endpoints and / or devices are reachable through more than one network zone (e.g., when more than one physical path is available between corresponding endpoints when these zones are logically separated but physically coupled (see FIG. 15 ) and / or when a second vehicle controller and / or a second endpoint coupled to the second network zone has the capability to perform the operations (or a portion thereof and / or an alternative operation thereof) of a first vehicle controller and / or a first endpoint coupled to the first network zone); repeating the communication from the first network zone (e.g., the degraded network zone) on the second network zone; shifting an endpoint from a first network zone (e.g., a degraded network zone) to a second network zone, for example, when the endpoint is physically coupled or coupleable to both a first network zone and a second network zone (e.g., when the separation between these network zones is logical, and / or when the endpoint is reachable through more than one network zone, as shown in Figure 15), and the operations of the CND include adjusting addressing operations, protocol operations, encapsulation operations, and / or any other operations that cause the shift of the endpoint, said shifting further including updating the location of the shifted endpoint to other devices / endpoints in the system or diverting communications with other devices / endpoints in the system without notification of the shift; combinations of these steps, such as shifting the endpoint from a first network zone to a second network zone, shifting the associated communication to the second network zone, and / or repeating the associated communication on the second network zone; Coordinating communications between endpoints in the first network zone (and / or one or more additional network zones) and external devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, network monitor devices, driver devices, cloud computing devices, and / or third party applications), where coordinating communications between endpoints in the first network zone and external devices may include any one or more of the operations described above and / or restricting communications according to an abnormal condition of a component of the system (e.g., endpoint, device, flow, network zone, etc.), restricting communications according to an operation condition of a mobile application, endpoint, associated flow, and / or external device. restricting communications according to device permissions and / or priorities, according to aggregated data values ​​(e.g., corresponding to the data service providers involved in the communication, endpoints, associated flows, and / or entities related to any one or more of these), which may be aggregated according to time (e.g., daily, weekly, monthly, etc.), operating conditions (e.g., trips, events, etc.), and / or where the data values ​​include one or more of total data transmission / reception values, data rate values, and / or combinations thereof; and / or according to external data access type (e.g., cellular, WiFi, Bluetooth, hardware / port connection, etc.); and / or Any one or a combination of two or more 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 interposed between the networks 104, 106. This exemplary system depicts the vehicle 202 communicatively coupled to the external device 110 and / or communicatively coupled to a second external device 114, similar to that shown in FIG. 1 . The example depicted in FIG. 2 depicts another external device 204 communicatively coupled to the vehicle 202, in this example through a cloud connection 112. The third external device 204 is shown as a laptop operated by, for example, a fleet service manager, an owner, and / or a vehicle agent (e.g., a secure manager). The example depicted in FIG. 2 is an exemplary depiction showing additional context options and specific uses for the vehicle, but is otherwise similar to the system depicted in FIG. 1 .

[0031] Referring to FIG. 3 , an exemplary embodiment is shown including a vehicle 202 illustrating certain further details that may be present 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 depicted 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 depicted in FIG. 3 , a third network 318 is shown having a fuel tank sensor 306 coupled to the CND 108. In this example, the third network 318 may be the same type as one of the other networks, separated from the other networks to improve installation costs, risk management, or other considerations, and / or may be a different type to support devices, e.g., sensors operating on a LIN network. The third network 318 may communicate with the CEG 314 of the CND 108, the Ethernet switch 312, or another device (not shown).

[0032] The example depicted in FIG. 3 includes a first device 314 (e.g., a controller for a prime mover in the example depicted in FIG. 3) on a first network 104 and several devices (e.g., an interactive dashboard 302, a fuel tank sensor 306, and a door actuator 310 in the example depicted in FIG. 3) on a second network. The system includes one of the devices 302, 310, 320 on the second network that communicates with the first device 314 through the CND 108. For example, the door actuator 310 can lock the doors when the vehicle 202 is moving and can pull and receive vehicle movement information from the first device 314 (e.g., engine speed, gear position, vehicle speed, and / or status parameters such as a Boolean value or bit mask of "vehicle moving").

[0033] 3 is a non-limiting example. Additionally or alternatively, a given device (e.g., prime mover 308) may appear as a single endpoint or multiple endpoints, for example, a controller for prime mover 308 may provide multiple parameters (e.g., engine temperature from an engine temperature sensor) to first network 104, each of which may be given an identifier and each of which may operate as a separate endpoint, and / or may include parameters so provided by the controller for prime mover 308 (e.g., engine temperature from an engine controller).

[0034] To illustrate the example depicted in FIG. 3 , the first network 104 may be a CAN bus network, where the desired data (e.g., vehicle movement indicator) is provided as a CAN message in accordance with CAN network considerations. The door actuator 310 is provided on a second network, e.g., an Ethernet network, where the door actuator 310 is on a port of the second network. The port for the door actuator 310 may be a physical port (e.g., an Ethernet switch 312 dedicated to the door actuator 310) or a virtual port (e.g., an address location for the second network that may reside on a physical port shared with one or more other devices). In the example depicted in FIG. 3 , the door actuator 310 is unable to receive a CAN message indicating vehicle movement, and the CND 108 interprets the request for the vehicle movement indicator from the door actuator 310 and transmits the message over the second network to the door actuator 310, removing the message from the first network 104.

[0035] The operations performed to send the message may vary depending on the application. For example, the CND 108 may publish to devices on the second network that certain parameters are available from the first network 104 (and / or the third network 318) and either provide select parameters directly to the device (e.g., provide a vehicle movement indicator to a requesting device) or publish data values ​​representing these parameters as available to devices that subscribe to the parameters (e.g., utilize a broker, not shown, to make the subscribed parameters available). In certain embodiments, the CND 108 may restrict the publication of available parameters to devices, endpoints, applications, and / or flows authorized to view these available parameters. In other words, various devices on the second network may see different available parameter lists depending on the authorization of these devices and / or applications or flows associated with these devices. In certain embodiments, the CND 108 may restrict the provision of these parameters to devices, endpoints, applications, and / or flows authorized to receive the parameters, for example, by rejecting subscribed requests for the parameters and / or by suppressing transmission of the parameters to unauthorized devices despite subscribed reception. Thus, in certain embodiments, a device may be able to see that a parameter is available (e.g., in a public list of available parameters) but may not be able to receive the parameter's data value. In certain embodiments, a device may be restricted to seeing only the available parameters that it is authorized to receive.

[0036] In certain embodiments, a device may have only limited availability to receive parameters, for example, CND108 may limit the rate of data values ​​to support network utilization reduction, data security considerations (e.g., limiting the accuracy, resolution, and / or data rate of sensitive parameters such as vehicle position), and / or proprietary considerations (e.g., limiting the accuracy, resolution, and / or data rate of parameters that may be related to proprietary control operations, for example, to limit the ability of an application to reverse engineer or otherwise determine how a control operation functions).

[0037] In certain embodiments, the CND 108 determines which parameters to expose and provide, and the conditions for providing them, based on stored data that defines the permissions and / or capabilities of devices, endpoints, applications, flows, etc. In certain embodiments, the CND 108 also accesses stored data that defines processing or conditioning 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, the CND 108 determines authorization for applications and / or flows that are on-vehicle, off-vehicle (e.g., operating on external devices such as 110, 114, 204), or a combination of on-vehicle and off-vehicle. In certain embodiments, the CND 108 can support prioritization of data flows, including the rate at which devices provide or receive information, based on the prioritization or other parameters of the associated devices, endpoints, applications, flows. In certain embodiments, the CND 108 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, a third priority scheme when the vehicle is moving, etc. In certain embodiments, the CND 108 can respond to any defined vehicle condition, such as charging operations, regeneration operations, aftertreatment operations, control strategies (e.g., cruise vs. driver control), emergency events, fault conditions, or service conditions, etc.

[0038] The example CND 108 depicted in FIG. 3 includes a first device 314 that communicates with the first network 104. The example first device 314 includes a configurable edge gateway (CEG) that reads communications from the first network 104 and provides them to the second network 106. In certain embodiments, the first device 314 translates the communications toward the second network, e.g., encapsulating the communications, portions of the communication frames, and / or the payload of the communications into messages for the second network. In certain embodiments, the first device 314 has the capability to request communications from devices on the first network 104, e.g., requesting parameters that are available but not currently communicated over the first network 104. In certain embodiments, the first device 314 is not part of the CND 108, but is controlled by the CND 108, e.g., in response to commands from the CND 108, by accessing stored data written in whole or in part by the CND 108, or by other operations provided throughout this disclosure.

[0039] The exemplary CND 18 depicted in FIG. 3 includes a second device 312 that communicates with the second network. The exemplary second device 312 includes an Ethernet switch that can be configurable and that reads communications from the second network. In certain embodiments, the second device 312 receives messages from the first network 104 through the first device 314, e.g., receives messages in a format that can be communicated on the second network. The exemplary first device 314 includes a CEG that communicates through a port on the Ethernet switch that is provided for messages from the first device 314. Thus, FIG. 3 provides an embodiment of a second device 312 on the second network that communicates with the first device 314 via the CND 108.

[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 a transceiver 304 and / or by direct access to the vehicle 202's network (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, for example, modifying stored data that defines the available data to be exposed, associated permissions, defined applications, defined flows, defined endpoints, and defined devices. In certain embodiments, the external devices have associated permission values, and the CND 108 provides changes according to the associated permission values, and prevents adjustments to, for example, changes related to certain networks, devices, endpoints, applications, or flows.

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

[0042] 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 depicted in FIG. 4, the first network gateway device 404 is a CEG that has access to one or more endpoints 408, e.g., one or more CAN-based networks 406, each having devices coupled to the CAN network 406 to provide and / or receive communications from the respective CAN network 406. The example depicted in FIG. 4 depicts two CAN networks 406 that can be arranged for integration purposes (e.g., to divide vehicle components by function, by location within the vehicle, and / or by any other arrangement, such as groups of related components communicating over a common CAN network 406). In this example, first network gateway device 404 communicates with both CAN networks 406, although CND 108 may include and / or be configured to coordinate more than one CEG, e.g., one CEG accessing each CAN network 406 and / or each CEG accessing a subset of CAN networks 406 on the vehicle. While the example depicted in FIG. 4 shows bus network 406 and describes network 406 as a CAN network for illustrative purposes, network 406 may be any type described throughout this disclosure. Endpoint 408 may be any type of endpoint capable of communicating with network 406, such as a controller, smart sensor, or smart actuator, or other device capable of providing and / or receiving communications to and from network 406.

[0043] Although the example depicted in FIG. 4 depicts CND 108 as including network gateway devices 402, 404, CND 108 may be separate from one or both of network gateway devices 402, 404 and may configure the operation of network gateway devices 402, 404, such as by adjusting data stored therein, adjusting stored data accessible to devices 402, 404, providing instructions to these devices, and / or performing any other operations enumerated throughout this disclosure.

[0044] In the example depicted in FIG. 4 , the second network gateway device 402 is an Ethernet switch that accesses an Ethernet-based network 410, shown as several endpoints 412 that communicate with several ports 414 of the Ethernet switch. The ports 414 are depicted schematically and may be logical ports, hardware ports, or a combination thereof. The physical topology of the Ethernet network 410 may be a bus, hub, star, or any other type of network topology and may differ from the logical topology of the Ethernet network 410. The second network gateway device 402 is depicted as having a network interface 416, which may include physical port connections. In certain embodiments, the second network gateway device 402 is a configurable Ethernet switch that may include a processor, computer-readable storage (e.g., for storing instructions, configuration information, buffering data for communication and / or collection operations, and the like). While these aspects are not shown for purposes of depiction and clarity of this description, these aspects may be present on the second network gateway device 402, present in the same housing as the second network gateway device 402, present on a board separate from the network interface 416 located on another device in the system and in communication with the second network gateway device 402 and / or separate from the rest of the second network gateway device 402 (e.g., mounted on a separate printed circuit board) (e.g., on the first network gateway device 404, on the vehicle controller, and / or on another controller in the system), and / or distributed across a combination of these locations.

[0045] 4 , first network gateway device 404 includes one or more network interfaces 418 (and / or network interface circuitry) that communicatively couple it to networks 406, and conversion circuitry 420 that includes messages from Ethernet network 410 for communication to network 406 and / or includes messages from network 406 for communication to Ethernet network 410. Additionally or alternatively, conversion circuitry 420 includes messages for passing from one of networks 406 to another of networks 406, for example, if these networks 406 are of different types, utilize different protocols, or are otherwise deemed to have conflicting source or destination information, and / or have otherwise distinctly different characteristics that are managed by first network gateway device 404 to ensure message compatibility, successful vehicle mission operation, and / or to implement any other configuration operations set forth in this disclosure. Although the conversion circuit 420 is shown as a single device, the conversion circuit 420 may be implemented as one or more devices, with several components of the conversion circuit 420 each implementing a certain type of configuration and interacting with a certain type of network 406, for example, to distribute its processing and / or memory operations, or for any other reason according to the particular system. In the example depicted in FIG. 4 , the first network gateway device 404 provides messages to an Ethernet switch in response to corresponding messages on the CAN-based network 406. In the example depicted in FIG. 4 , the first network gateway device 404 provides messages to port 414 of the Ethernet switch. In the example depicted in FIG. 4 , any messages provided from the network 406 appear on the Ethernet network 410 as messages on a port between the conversion circuit 420 and the network interface 416, and messages from the Ethernet network 410 are received through a port between the conversion circuit 420 and the network interface 416.The translation circuitry 420 provides the structuring operation between messages so that such endpoints on each network 406, 410 can communicate between each other as coordinated by the CND 108.

[0046] The example depicted in FIG. 4 further includes an on-board diagnostics (OBD) interface 422, which in this example communicates with a dedicated OBD port 424. The example depicted in FIG. 4 is illustrative and non-limiting; the OBD interface 422 can connect to either network or to more than one network (e.g., to support multiple OBD tools that can be connected to the vehicle). An exemplary embodiment includes the OBD interface 422 connected to the second network gateway device 402; for example, in this case, the OBD system is largely CAN-based, and many of the OBD parameters are specific to one or more of the CAN networks 406, allowing for less traffic between the conversion circuit 420 and the network interface 416. The OBD interface 422 can alternatively reside on the Ethernet network 410 or on more than one of the system's networks 406, 410. Regardless of the location of the OBD interface 422 and where on the networks 406, 410 the OBD-related data originates, OBD requests and information can be made available to the OBD port 424 (which can be a physical connection, a wireless connection, or another external connection including a mobile data connection) by operation of the CND 108, which authorizes and provides inter-network communications from either end of the networks 406, 410. Additionally, while the example depicted in Figure 4 utilizes the OBD interface 422 as a non-limiting example, any type of specialized, dedicated, and / or proprietary interface having interfaces and ports that can make available any data from either end on the networks 406, 410 and subject it to configurable conditioning by the CND 108 can be provided in a similar manner.

[0047] The exemplary system includes a CND 108 interposed between an electrical sensor and one of the networks 406, 410 and structured to provide a sensed value on the network responsive to the electrical response of the electrical sensor. 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 the electrical sensor, in which case a conversion circuit 420 converts the electrical signal from the sensor for communication for the respective 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-to-digital (A / D) processing, indication bit determination, indication value determination, signal debouncing, signal filtering, diagnostic bit detection (e.g., fault determination and conversion to a corresponding fault value 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 limiting (e.g., applying a rate-of-change limit to an indication value), etc. The electrical signal from the sensor, if present, may be a voltage value, a frequency value, an indicated resistance value, or any other type of sensor electrical value known in the art.

[0048] In another example, the system includes a CND 108 interposed between an electric actuator and one of the networks 406, 410 and configured to provide a command value 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 the electric actuator, in which case the conversion circuit 420 converts communications from the respective network (e.g., network 410 or another network 406) into an electrical signal for the actuator. In this example, the conversion circuit 420 can perform processing operations on the electrical signal, such as digital-to-analog processing, determining from an indication bit to a corresponding value, providing a diagnostic bit, saturation management, and slew limiting. The electrical signal to the actuator, if present, can be 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 electrical actuator may further have sensed values ​​(e.g., position feedback, acknowledgments, etc.) and / or other feedback values ​​(e.g., certain electrical values ​​indicating the actuator has a fault condition, is unresponsive, is stuck, is saturated, etc.) that may be provided on the same or distinctly different electrical connections and may be part of the logically same network 406 or distinctly different networks (e.g., actuation on one network 406 and feedback on a second network 406).

[0049] It can be seen that the embodiment described in FIG. 4 enables communication between endpoints on distinct networks without requiring knowledge of how the endpoints communicate to other endpoints or where the other endpoints are located. Without being limited to any other aspect of the present disclosure, the embodiment described in FIG. 4 provides functionality for operation of a vehicle network having distributed devices on multiple distinct networks, including networks of different types. Furthermore, the embodiment described in FIG. 4 provides for operation of a vehicle when devices are moved between networks without being limited by whether the devices have changed communication capabilities. For example, a first device on a CAN network that is moved to an Ethernet network can continue to function by, with appropriate configuration of CND 108, moving messages utilized by the device from the CAN network to the Ethernet network and making them available to the device in its new location. In certain embodiments, the migrated device can continue to utilize the previous algorithm (e.g., the same local control), with the CND 108 configured to encapsulate the entire original CAN message within an Ethernet message (e.g., in a frame, packet, and / or in a specified manner) so that the migrated device can receive the previous CAN message originally presented and utilized by this same local control with computer-readable instructions specifically configured to the specifications of the previous CAN message, including, for example, bit depth, resolution information, message rate, and floating-point / fixed-point data nature, etc. Thus, the embodiment described in and principles illustrated with respect to FIG. 4 enable changes in the mix of endpoint devices between networks, whether across several vehicles (e.g., changes occurring across a design review process, model year, or the like) or within the same vehicle range (e.g., service repair, upgrades or modifications to the endpoints, upgrades, upfits, recall replacements, etc.), with only a configuration update of the CND 108 to support these changes.In certain embodiments, the embodiments described in and principles illustrated with respect to Figure 4 enable changes to the mix of termination devices between networks without requiring a configuration update of the CND 108, for example, when a range of terminations are contemplated that are made available in more than one possible location and / or configuration of the network, and the CND 108 is configured to determine the termination placement present on the vehicle and utilize a selected configuration (e.g., from among two or more available configurations). Thus, the embodiments described in and principles illustrated with respect to Figure 4 further enable changes to the mix of termination devices between networks, at least over a predetermined range of termination devices and configurations, without any changes to the vehicle and with only intermittent or no communication with external devices for the configuration of the CND 108 to support vehicle operation.

[0050] Referring to FIG. 5 , an exemplary system includes a CND 108 that coordinates communications between multiple networks on a vehicle, which may be physically or logically separated (e.g., as virtual local area networks (VLANs) or other logical separation schemes) and / or one or more of different types. The embodiment described in FIG. 5 is generally consistent with the embodiment described in FIG. 4 , with some differences noted to highlight certain aspects of the present disclosure. The example described in FIG. 5 includes additional interfaces 504, 506, which may be separate networks or network zones with respect to network 406. The example described in FIG. 5 depicts a vehicle control device interface (VCDI) 508, which may 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.), including a controller that provides communications to endpoint 504, and / or an electrical interface to a sensor, actuator, or combination of sensors and actuators, etc. The example depicted in Figure 5 depicts an additional interface 506 to the endpoint 502, which may be any type of communications device understood in the art or described herein. In the embodiment depicted in Figure 5, network interface circuits 418, 416 are shown between the endpoints 408, 502 and the conversion circuit 420 to allow the conversion circuit 420 to interface with many network types that may be present on the vehicle. The interface circuits 418, 416 may be co-located with the conversion circuit 420 or located elsewhere and communicatively coupled to the associated network and conversion circuit 420. The example depicted in Figure 5 further depicts networks 512, 514 communicatively coupled to the first network gateway device 404 through the endpoint 412 on the same network as the network interface 416.In certain embodiments, the CND 108 does not have or need specific knowledge about the networks 512, 514 or the associated endpoints 516, 518, because communications to the networks 512, 514 are provided through the endpoint 412. However, the CND 108 is structured to provide communications from networks in communication with the second network gateway device 402, such as the network 406 and / or the networks interfaced at the endpoints 504, 506. Communications from the second network gateway device 402 may provide requested information (e.g., ambient temperature, door position, vehicle speed), for example, as an encapsulated payload providing this information or as a proprietary message (e.g., a CAN message indicating ambient temperature, door position, vehicle speed, and / or a LIN message with relevant sensor information). Thus, the endpoints 516, 518 can send and receive tunneled messages to and from the network 406 (or other networks) in a shared format, or receive information from any network on the vehicle and coordinated by the CND 108.

[0051] Referring to Figure 6, an exemplary system includes a CND 108 located on a vehicle that coordinates communications between multiple networks, which may be physically and logically separated (e.g., as virtual local area networks (VLANs) or other logical separation schemes) and / or one or more of different types. The embodiment depicted in Figure 6 is generally consistent with the embodiment depicted in Figure 4, with some differences noted to highlight certain aspects of the present disclosure. Without being limited to any flexibility of the arrangement depicted in Figure 4, the example depicted in Figure 6 depicts a conversion circuit 420 located in a first network gateway device 404.

[0052] Without being limited to any other aspect of the present disclosure, the collocation shown in FIG. 6, as used herein, may refer to physical collocation (e.g., the conversion circuitry 420 is located in a shared housing with the first network gateway device 404 and / or on the same substrate as the first network gateway device 404) and / or logical collocation (e.g., the grouping of operational responsibilities of the execution hardware, such as connections, connectivity, operating instructions, stored data, data storage, and / or processing resources). The decision on a colocation scheme depends on the purpose of the colocation (e.g., sharing hardware resources, reducing the number of external interfaces, simplifying and / or diversifying the risk profile of the colocated components and / or other components in the system associated with these components), the nature of the colocated components (e.g., hardware implementation, processing resources, and / or memory resources associated with the colocated components), the division of ownership of the colocated components (e.g., manufacturer, supplier, servicer, vehicle owner, vehicle operator), the operational burden of the components and / or vehicles (e.g., reliably, operational liabilities, service, insurance, operational liabilities, etc.), and / or the integration burden of the components (e.g., meeting installation, design, footprint requirements, compromises between components, and / or the ability to influence the same).Thus, in certain embodiments, colocating components can include one or more of placing components in a housing or housings, placing components in a selected geometric vicinity, placing components in a selected logical placement (e.g., associating within the same flow or flow groups, associating within the same application or application groups, imposing operational constraints such as parameter naming, memory allocation, or execution order, etc.), placing components in a selected risk profile placement (e.g., placing in the same impact zone subject to the same failure mode (e.g., electrical impact, logical impact, failure impact, physical impact, and / or dependency on physical components such as pumps, cooling systems, etc.), the same temperature environment, the same NVH environment, the same EMI environment), placing on the same board, and / or on shared memory locations (e.g., computer-readable instructions are placed in shared memory locations and / or executed by the same processor resources). In this example, NVH is the "noise, vibration, and harshness" environment and EMI is the "electromagnetic interference" environment. Those skilled in the art, having the benefit of this disclosure and the information typically available when considering a particular system, can readily determine the implementation of collocated components as shown in this disclosure. It will be appreciated that components arranged in one or more of the described collocation schemes may be collocated in certain embodiments and not collocated in other embodiments, and / or may be collocated for certain operating conditions but not for other operating conditions.Certain considerations for determining whether components are collocated, and the collocation scheme selected for those components, include (but are not limited to), the objectives of the collocation, the operational costs of the resources (e.g., communications, processing resources, operational constraints on the vehicle's mission, operational impact on the vehicle's mission, e.g., cooling requirements, and power consumption, etc.), the capital costs of the resources (e.g., computing power, network infrastructure, memory resources, quality or functional requirements of individual components, shielding requirements, data throughput whether on-vehicle or off-vehicle, etc.), the integration costs associated with the components (e.g., footprint availability and cost, interface management, design flexibility and lockdown trajectory, and / or the ability to compromise and / or optimize other aspects of the system), and / or the ability to spread costs to other stakeholders in the system (e.g., these stakeholders may be suppliers, manufacturers, customers, and / or service providers, which may include the ability to spread high costs associated with high functionality and / or to transfer costs between stakeholders).

[0053] In the example depicted in FIG. 6, the translation circuitry 420 may provide communication by, but not limited to, putting data into and / or reading data from memory shared with the network interface 416 and / or by communicating with the port 414 (not shown).

[0054] Referring to Figure 7, an exemplary system includes a CND 108 on a vehicle that coordinates communications between multiple networks, which may be physically and logically separated (e.g., as virtual local area networks (VLANs) or other logical separation schemes) and / or one or more of different types. The embodiment described in Figure 7 is generally consistent with the embodiment described in Figure 4, with some differences noted to highlight certain aspects of the present disclosure. Without being limited to any flexibility of the arrangement shown in Figure 4, the example described in Figure 7 depicts a conversion circuit 420 having a first portion 702 co-located with a second network gateway device 402 and a second portion 704 co-located with a first network gateway device 404. Each portion 702, 704 of the conversion circuitry 420 may be separated for any reason, including at least separating the conversion operations by network (e.g., which network 406 is being served), by predetermined endpoint, by flow, by conversion operation (processing of frame information, processing of payload information, managing functionality differences by downsampling, upsampling, buffering, providing communication instructions, encapsulating messages in different message formats, etc.), and / or by direction of communication (e.g., between selected networks, between gateway devices, between endpoints, between flows, or a combination of these directions).

[0055] Referring to FIG. 8 , an exemplary system includes a CND 108 that is on a vehicle and coordinates communications between multiple networks, which may be physically or logically separated (e.g., as virtual local area networks (VLANs) or other logical separation schemes) and / or one or more of different types. The embodiment described in FIG. 8 is generally consistent with the embodiment described in FIG. 4 , with some differences noted to highlight certain aspects of the present disclosure. In the example described in FIG. 8 , the first network gateway device and the second network gateway device are omitted as they are co-located and shown as part of the CND 108. In certain embodiments, the CND 108 described in FIG. 8 may instead be a combined gateway device coordinated by the CND 108 rather than forming a part thereof. In certain embodiments, one or more portions of the combined gateway device may form part of the CND 108, with other portions of the combined gateway device being coordinated by the CND 108.

[0056] A policy, as used herein and not limited to any other aspect of the present disclosure, includes a description of data to be collected, such as data parameters, collection rates, resolution information, and priority values ​​(e.g., ordering data collection values ​​for selection in response to abnormal conditions where not all data collection parameters may provide information). In certain embodiments, a policy further includes event information, which may be defined as a parameter or a quantitative-based event (e.g., a given data value being greater than a threshold), and / or a categorical event (e.g., a particular fault code, operating condition or state, or vehicle location / jurisdiction occurs). In certain embodiments, a policy further includes an event response, such as a data value to be captured in response to the occurrence of the event, and / or other changes to the data collection scheme, such as increasing or decreasing the data collection rate or changing the collection resolution. In certain embodiments, the event response further includes a time frame relative to the event occurrence, e.g., a period for utilizing an adjusted data collection scheme after the event occurs, and / or a period preceding the event occurrence (e.g., utilizing a rolling buffer or other data collection operation, providing temporal information that can be captured if the event occurs later). In certain embodiments, the change in the data collection scheme for an event can include multiple changes, such as changes over a period of time, further changes based on the progression of the event (e.g., if the event severity worsens), and / or further changes based on criteria for determining that the event is resolved. In certain embodiments, the change in the data collection scheme can be implemented based on an event-related resolution of the same or another event, such as implementing the data collection change until the next vehicle stop event, until a service technician resolves the event, for a selected number of stop events, or a similar period of time. Additionally or alternatively, the policy can include parameters for implementing any adjustment action for any adjusted component listed throughout this disclosure.

[0057] A policy in use herein may refer to a secondary policy, e.g., an implicit policy to be implemented in response to a single data collection scheme from a single user, and a complete policy that is prepared, verified, and communicated to a vehicle after one or more secondary policies have been collected. A policy in use herein may refer to an unverified policy, e.g., a policy after policies in response to several users have been collected but before policy verification operations have been completed (e.g., before it has been determined whether data collection suggested by the policy can be implemented). A policy in use herein may refer to a previously applied policy (e.g., a policy that existed before an updated version of a policy was communicated to and / or implemented on a vehicle). A policy in use herein may refer to an updated policy, e.g., a verified policy (e.g., from CND 108) awaiting communication to and / or confirmation by the vehicle.

[0058] Referring to Figure 9, an exemplary system includes a CND 108 on a vehicle that coordinates communications between multiple networks, which may be physically or logically separated (e.g., as virtual local area networks (VLANs) or other logical separation schemes) and / or one or more of which may be of different types. The embodiment described in Figure 9 is generally consistent with the embodiment described in Figure 4, with some differences noted to highlight certain aspects of the present disclosure. In the example described in Figure 9, the first network gateway device 404 and the second network gateway device 402 are not co-located, and the CND 108 is shown in communication with the first network gateway device 404. The CND 108 may be in communication with any one or more of the network gateway devices and / or may be at least partially located on one or more of the network gateway devices. Additionally or alternatively, CND 108 may coordinate communications between networks by accessing and / or adjusting memory locations (e.g., policies, configuration instructions, or configuration tables) available to one or more of the network gateway devices, where CND 108 may pass relevant portions of instructions (if any) to other network gateway devices if CND 108 does not communicate directly with those devices. In certain embodiments (not shown), CND 108 may communicate with one or more of the network gateway devices using one or more of the networks, for example, at port 414 of first network gateway device 404. In certain embodiments, CND 108 may be at least partially located on one or more of the network gateway devices, co-located with one or more of the network gateway devices, and / or included (at least partially) within one or more components (e.g., translation circuitry and / or network interface circuitry) of the network gateway devices.

[0059] 10, there is shown an exemplary first network gateway device 404. In the example depicted 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 circuitry) having several ports 414 for communication with an Ethernet network. The ports 414 may be physical ports, logical ports, or a combination thereof.

[0060] 11 , an exemplary second network gateway device 402 is shown. In the example depicted in FIG. 11 , the second network gateway device 402 is a configurable edge gateway (CEG) that provides translation between a secondary network 406 and a primary network interface (e.g., an Ethernet network such as network 410). The use of secondary and primary to refer to networks merely indicates the logical arrangement of the network, in which case interfaces to other networks other than the primary are referred to as edge interfaces (e.g., interfaced to an edge gateway). In certain embodiments, a primary network may have higher capabilities (e.g., bandwidth, throughput, and / or resource dedication), more devices or endpoints on the network, migration target networks for endpoints over time (over the life of a vehicle, fleet of vehicles, model year duration, etc.), and / or a primary entry network for external communications (e.g., over-the-air updates, configuration updates, data collection, etc.), although particular embodiments may have some, all, or none of these considerations present for a network that is considered a primary network. The example set forth in FIG. 11 depicts an optional OBD interface 422 that may be present elsewhere in the system or may not be present in the system.

[0061] Referring to Figure 12, a vehicle is shown having several networks therein, with communications between these networks coordinated by a CND 108. The arrangement depicted in Figure 12 is provided to illustrate certain aspects of the present disclosure and is not intended to be limiting. The example depicted in Figure 12 includes an endpoint 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 co-located switch with the CND 108 and / or at least partially separate from the CND 108). In the example depicted in Figure 12, the controllers 1202, 1204, 1206, 1208, 1210, 1212 can pass communications coordinated by the CND 108 between the vehicle's heterogeneous networks. In certain embodiments, a given controller can be switched between networks and maintain communication with other controllers within the vehicle and / or communications external to the vehicle, regardless of whether the associated controller (or external controller, application, or device) has knowledge of the switch.

[0062] Referring to FIG. 13, a vehicle is shown having several networks therein, with communication between these networks coordinated by CND 108. For illustrative purposes, the example depicted in FIG. 13 includes the same set of networks and controllers as the example depicted in FIG. 12. In the example depicted in FIG. 13, controllers 1204, 1208, 1210, and 1212 are co-located 1302, and further, controller 1204 has been moved from first network 406 to a second network. The co-location 1302 of controllers 1204, 1208, 1210, and 1212 can be any implementation including consolidating the controllers into fewer housings (1-3 total housings instead of 4), fewer boards (1-3 total boards instead of 4), and / or utilizing at least partially shared computer resources (e.g., shared processing, shared memory, shared cache, and / or combinations thereof). 13, which includes vehicle controller aggregation, by allowing communication coordination and connectivity to be maintained solely through configuration updates to the CND 108 and / or through vehicle controller aggregation changes that fall within the available pre-defined configuration of the CND 108 (which can be performed without updates to the CND 108). Additionally, controller aggregation can provide several benefits, such as reduced network costs, reduced network traffic, and selective risk distribution (e.g., placement of controller locations and / or network routing in locations of lower risk or distributed risk, and / or reduced risk to other system components by leveraging footprint gains and / or cost savings from controller aggregation).In certain embodiments, controller aggregation can enable deeper information sharing between controllers (e.g., due to greater available network capacity, avoidance of network limitations with shared controllers, and / or utilization of shared memory resources), thereby providing higher-capability controller operation and / or operation that was previously unavailable because the shared information between controllers was not readily available. In certain embodiments, CND 108 further enables controller aggregation by decoupling controller locations from end-point locations (not shown) that require distribution (e.g., sensors and actuators that must be located at a certain location to perform their function no longer need to be located near each controller due to operation of CND 108 and / or CEG 402). In certain embodiments, controller aggregation can, for example, reduce hardware costs for shared computer resources, enable higher-capability computer resources (e.g., processing power and / or memory), or a combination thereof, enabling lower cost and / or higher functionality. Thus, operation of CND 108 provides aggregated operation of vehicle controllers that was previously unavailable. In certain embodiments, the example set forth in FIG. 13 may be illustrative of an aggregated and / or unrelated embodiment of the controllers with respect to FIG.

[0063] Referring to FIG. 14 , a vehicle is shown having several networks thereon, with communication between these networks coordinated by a CND 108. For illustrative purposes, the example set forth in FIG. 14 includes the same networks and a similar set of controllers as the example set forth in FIG. 12 . In the example set forth in FIG. 14 , the co-location 1302 controller includes a set of controllers 1402, 1404, 1406 and the CND 108, shown as a controller on the co-location 1302 controller. The CND 108 may be at least partially located on one or more of the co-location controllers 1402, 1404, 1406 and / or may be separate as illustrated. In certain embodiments, the example set forth in FIG. 14 may be yet another aggregation of controllers with respect to FIG. 13 and / or an illustration of the co-location 1302 controller unrelated to the examples set forth in FIGS. 12 and 13 .

[0064] Referring to Figure 15, a vehicle is shown having several networks thereon, with communication between these networks coordinated by a CND 1502, 1504. For illustrative purposes, the example set forth in Figure 15 utilizes two aggregation controllers 1302, 1506, each containing a set of co-located vehicle controllers as enumerated throughout this disclosure. The example set forth in Figure 15 includes a first CND 1502 (or CND portion) inserted between a first network 406 and a second network (with a termination 412 directly coupled to the CND 1502 and the aggregation controller 1506 directly coupled to the CND 1502) and a second CND 1502 (or CND portion) inserted between the first network 406 and the second network (with a termination 412 directly coupled to the CND 1504 and the aggregation controller 1302 directly coupled to the 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 the same or electrically coupled hardware. While the example set forth in FIG. 15 shows the CND 1504 having primary network coordination for the first network 406, coordination of the first network 406 can be coordinated according to distribution, sharing, endpoints, or applications and / or flows, etc. In certain embodiments, coordination of the second network can be performed by only one of the CNDs 1502, 1504 and / or coordinated according to distribution, sharing, endpoints, applications, and / or flows.

[0065] Several representative aspects described in Figure 15 are described below, any one or more of which may be present in certain embodiments. The exemplary aspects described in Figure 15 include network coordination shared by CNDs 1502, 1504, where either CND 1502, 1504 has the capability to fully or partially support coordination of the entire network, for example, in the event that an end point, network, other (or partial) CND, and / or controller experiences a malfunction, failure, or degraded operational capability. The exemplary aspects described in Figure 15 include primary coordination of the network by one CND 1502, 1504, where the other CND has the capability to fully or partially support coordination of the entire network, for example, in the event that an end point, network, primary CND, and / or controller experiences a malfunction, failure, or degraded operational capability. 15 includes one or both of the aggregation controllers 1302, 1506 having the capability to at least partially assume control operations for the other of the aggregation controllers 1302, 1506 if the other loses functionality, connectivity with endpoints, etc. In certain embodiments, the CNDs 1502, 1504 have the capability to respond to and pass on parameters previously available only to the original controllers 1302, 1506 in assuming control operations by the replacement controllers 1302, 1506. In certain embodiments, the availability of redundant network routing can be used by the CNDs 1502, 1504 to provide at least partial connectivity between endpoints that lose connection when a portion of the network fails.The CNDs 1502, 1504 may provide equivalent parameters (e.g., another termination point capable of providing equivalent data), alternative parameters (e.g., another termination point capable of providing alternative or backup parameters that can be used at least in part as a substitute for a lost parameter), the same parameters (e.g., where data from the original termination point or the same data value from another termination point can be routed through the remaining network infrastructure), and / or may provide management parameters such as controller handoff communications, heartbeat communications, or status communications. In certain embodiments, one or both of the CNDs 1502, 1504, or portions of the CND, may be co-located with another system component, such as one of the aggregation controllers 1302, 1506. In certain embodiments, network routing is provided for multiple networks on the vehicle that poses distinctly different risk profiles and reduces the risk of a single failure rendering the vehicle inoperable for such missions and / or at least for limp-home operations, controlled shutdowns, data capture, etc. In certain embodiments, the locations of the controller, CND, and / or aggregation controller may be selected to provide distinctly different risk profiles for multiple associated devices, reducing the risk of a single failure rendering the vehicle inoperable for such missions and / or at least for limp home operations, controlled shutdowns, data capture, etc. In certain embodiments, network routing is provided for these networks on the vehicle to result in lower operational costs, installation costs, integration costs, overall risk profile, or distribution of component weight and / or footprint on the vehicle, etc.

[0066] Resolution of conflicting priority rights can be accomplished using any of a number of techniques, such as always giving priority to the highest priority requester, providing a weighted response based on priority (e.g., providing information more often to higher priority requests than lower priority requests), and / or utilizing a credit-based scheme that allows lower priority requests to be provided with information after a certain period and / or number of requests while prioritizing higher priority requests. Resolution of conflicting priority rights can include satisfying service performance requirements (e.g., QoS values) for the higher priority requests and providing information to the lower priority requests to the extent possible while still satisfying the performance requirements for the higher priority requests.

[0067] As used herein, the mission of a device (e.g., controller, endpoint, vehicle, mobile application, etc.) should be understood broadly and includes, at a minimum, the associated functions, structure, capabilities, and operation of the device that support the operation of a mobile application to perform the intended or primary function of the mobile application. Without being limited to any other aspect of this disclosure, the intended or primary function of a mobile application includes one or both of the mobile application's propulsive operation (e.g., having a specified torque, speed, responsiveness, etc.) according to the design of the propulsion function and / or the mobile application's non-propulsive operation according to the designed non-propulsion function (e.g., industrial operation, professional operation, pumping operation, providing shaft power, range of motion, and control thereof). In certain embodiments, the intended or primary function of a mobile application includes abnormal operation responses, such as operating in a limp-home mode, communicating a fault condition or a fault condition, and / or preventing further degradation of the vehicle and / or mobile application, which may have only a lower function than the designed propulsion or non-propulsion function. In certain embodiments, the intended functionality or primary function of a mobile application includes sending and / or receiving external data, performing update operations, facilitating service operations, facilitating update and / or upgrade operations, etc. Accordingly, device roles may vary between 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 its components, devices, and / or their controllers. Those skilled in the art, having the benefit of this disclosure and the information typically available when considering a particular mobile application, will readily understand the mobile application's roles, the device roles for the mobile application, and the availability of these devices across the operating and status conditions of the mobile application.

[0068] Referring to FIG. 16 , an example system 1600 for providing off-vehicle communication control consistent with embodiments of the present disclosure is shown. The systems described throughout this disclosure may be provided on a mobile application, such as in a vehicle, or as described throughout this disclosure. The example systems herein recite specific arrangements of, for example, 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 may be distributed, combined, split, and / or have relationships distinct from those depicted to form the systems and implement the methods described herein.

[0069] A circuit, controller, processor, or other device shown herein may be configured to functionally perform the operations described herein and may include computer components such as a processor, memory, and / or communication components. Additionally or alternatively, such a device may include logic circuitry, hardware configured to perform one or more functions of the device, sensors, actuators, and / or displays of any type. A given circuit, controller, processor, or other such device may be distributed and / or grouped in whole or in part with other such devices.

[0070] Certain operations herein are described as interpreting or receiving a parameter or obtaining a parameter value, using other similar language depending on the context. Any such operations include receiving a parameter value as a 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 the interpreting or receiving device, receiving a parameter value as a command, receiving a parameter value in response to a request from a receiving or interpreting device, and / or receiving a precursor value from which the parameter is at least partially determined (e.g., using other information to operate a virtual sensor to determine the parameter value to interpret or receive, determining a situation value based on the received information if a situation value is received or interpreted for purposes of this description, and / or using the received information to infer an interpreted value). Additionally, any such operation may include more steps than these (e.g., interpreting parameter values ​​at different times, operating conditions, during abnormal conditions, in distinctly different schemes depending on the source of the parameter values ​​and / or depending on the use or purpose of the interpreted parameter values ​​at a given time or during certain operating conditions), and / or combinations of these steps (e.g., operating virtual sensors on received information to determine precursor values ​​and determining interpreted parameter values ​​in response to the precursor values).

[0071] The example system 1600 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 different types of networks. Without being limited to any other aspect of the present disclosure, the various types of networks described herein contemplate any differences in networks such as differences in network capabilities (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, acknowledgment type, requirements, or capabilities, cast availability, e.g., unicast, multicast, and / or broadcast), network standard type (e.g., Controller Area Network (CAN), Media Oriented Systems 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, customized versions of any one or more of these, and / or proprietary versions of any one or more of these). Exemplary network zones include electrical signal zones (e.g., networks where a corresponding network interface circuit interprets electrical signal values ​​as communications and / or provides electrical signal values ​​as communications to an endpoint of the electrical signal zone, e.g., a sensor providing an electrical value indicative of a sensed parameter value, a diagnostic value, etc., and / or an actuator that moves to a selected position and / or applies a selected force in response to the electrical value, and / or where the actuator can additionally or alternatively provide feedback and / or diagnostic information on the electrical signal zone). 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., a duty cycle, an amplitude, a selective period, etc.

[0072] The example 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 that includes 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 pre-stored (e.g., at the time of manufacture, assembly, and / or during a previous update from the external device 1618), where the policy 1606 includes a network regulation description having an indication of devices on the vehicle 102 that are selected for functionality to utilize the network zones 1612, 1614, to communicate between the zones, and / or to communicate with the external device 1618.

[0073] The example system 1600 includes a first network interface circuit 1608 provided as part of a CEG when a first network zone 1612 is a CAN bus network, and a second network interface circuit 1610 provided as part of a CES when a second network zone 1614 is provided as an Ethernet network. In this example, the first network interface circuit 1608 provides selected communications from the first network zone 1612 to the second network interface circuit 1610 at selected ports of the Ethernet network and / or receives selected communications from the second network zone 1614 at selected ports of the Ethernet network, thereby enabling inter-network communications 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 may 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 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 a first network zone 1612 as a virtual local area network (VLAN) that is logically separate from, but located on hardware that is at least partially shared with, the second network zone 1614. In this example, the first network interface circuitry 1608 and the second network interface circuitry 1610 may operate as elements of a network switch or router and control communications between endpoints in the first network zone 1612 and the second network zone 1614 in response to policy 1606.

[0075] The devices on the vehicle 102 that are regulated by the policy include, but are not limited to, one or more of: an endpoint of a network zone, a flow associated with a communication device (e.g., an endpoint or application), and an application associated with a communication device (e.g., an endpoint). For example, an endpoint in a first network zone 1612 (e.g., a backup camera on the vehicle 102) may require or perform communication over the vehicle's network, but may be associated with more than one application or flow (e.g., associated with a first flow associated with reversing the vehicle in a first operating condition, and associated with a second flow associated with security operation of the vehicle in a second operating condition), and thus, the communications of the backup camera on the vehicle 102 may have different regulation parameters depending on the flow associated with the operation while moving. In certain embodiments, an endpoint is associated with more than one application or flow and is regulated according to the highest priority of the associated application or flow (e.g., to reduce communication requirements, such as determining which applications or flows require immediate communication to be regulated, and / or to reduce processing time for determining which applications or flows require immediate communication). In certain embodiments, an endpoint is associated with more than one application or flow and is adjusted according to the priority of the application or flow requiring immediate communication.

[0076] Devices may be referred to herein as local communication devices on the vehicle 102 and coordinated by policies. Local communication devices include, but are not limited to, network zone endpoints, applications, flows, sensor devices, service groups, vehicle functions (e.g., power management, cabin comfort, traction control, etc.), and / or vehicle controllers (e.g., engine controller, transmission controller, anti-lock braking system (ABS) controller, advanced driver assistance system (ADAS) controller, etc.). It can be seen that a given component, such as a network zone endpoint, can be a first local communication device during one operating condition and a second local communication device during another operating condition, depending on, for example, the vehicle operating condition (e.g., stopping, propelling operation, parking operation, etc.), and / or can be a first local communication device for a first purpose (e.g., a brake controller performing active traction control operation) and a second local communication device for a second purpose (e.g., a brake controller providing data to be stored for diagnostic operation). It can further be seen that the distribution of communication devices among applications, flows, controllers, vehicle functions, etc., can depend on the organization scheme of a particular system, design choices made by the manufacturer or other entity having design and / or configuration control of the system, etc. For example, traction control can be provided by an integrated vehicle controller for a given system (e.g., which can treat traction control as a vehicle controller for network coordination purposes), by a distributed controller for another system (e.g., which can treat traction control as a vehicle function for network coordination purposes), and / or can be treated as a logically grouped operating set for another system (e.g., which can have any hardware organization including the above-mentioned organizations and can treat traction control as an application or flow for network coordination purposes). One skilled in the art, having the benefit of this disclosure and the information typically available when considering a particular system, can readily determine the organization scheme and network coordination for the local communication devices of the system.The organizational scheme for local communication devices includes inclusion and / or association of endpoints in a network zone and / or communication with one or more of specific endpoints, vehicle controllers, vehicle functions, applications, and / or flows in the system (including source or destination communication to the endpoints).

[0077] Certain considerations in determining the organization scheme include the number, type, function, and interconnection bandwidth of the system's network zones, the available size and / or granularity for the system's policies, the processing power available for enforcing the system's policies, the number and distribution of vehicle controllers and other controllers throughout the system, the expected aging of the system (e.g., the availability to reconfigure, remanufacture, and / or re-specify vehicles, expected changes in upcoming model years for vehicles, and / or the available or expected level of consumer and / or third-party vehicle customization), the number and distribution of sensors and / or actuators throughout the system, and the connectivity of sensors and / or actuators to the network zones (e.g., aggregation to a controller and / or the ability of sensors and / or actuators to interface directly with the network zones). the presence, number, and distribution of multi-purpose communication elements (e.g., sensors, actuators, controllers, and / or data values ​​that provide information to multiple vehicle functions, flows, and / or applications) on the system; the presence, number, and distribution of multi-purpose data elements (e.g., sensors, actuators, controllers, and / or data values ​​that provide redundant performance to support a given vehicle function, flow, and / or application) on the system; and / or the expected utilization of network aspects (e.g., communications on a network zone, data rates and / or aggregations of communicated data for external communications, inter-network communications, etc.) with respect to associated capacity (e.g., bandwidth of a network zone, bandwidth for external communications, data limits for external communications, inter-network communications, etc.).

[0078] The example policy management circuit 1602 receives policy communications 1616 from external devices 1618 and interprets the policies 1606 by performing operations such as storing the policies 1606 (e.g., in a memory location accessible to the policy management circuit 1602 and / or distributing them across several memory locations) and / or updating the stored policies 1606. In certain embodiments, the policy management circuit 1602 configures the policy 1606 for use by the network adjustment aspects of the system 1600 by, for example, updating the number of configuration files used by the interface circuits 1608, 1610, adjusting the high-level description of the policy communication 1616 into instructions executable by the network adjustment aspects of the system 1600 (e.g., limiting external communication data to 32 GB per month), adjusting criteria values ​​of the policy communication 1616 (e.g., associating local address values ​​of the endpoint described in the policy communication 1616 when the endpoint is moved without notification to the external device 1618 and / or when local device specific addressing information is abstracted from the external device 1618), associating system-specific designations (e.g., names or IDs of local parameter values, names or IDs of flows, names or IDs of applications, etc.) with elements of the policy description 1620, etc.

[0079] The example 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 coupling to a network zone. The example 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 example system 1600 includes a policy management circuit 1602 that validates the policy 1606 communicated by the policy communication 1616 before storing and / or updating it. For example, the policy management circuit 1602 may require authentication of the external device 1618 and / or a determination of permissions associated with the external device 1618 before implementing changes to the policy 1606. In certain embodiments, the policy management circuit 1602 may determine the permissions associated with the external device 1618, the entity utilizing the external device 1618, the application or flow utilizing the external device 1618, etc. before implementing changes to the policy 1606. In certain embodiments, the policy management circuit 1602 may reject the policy communication 1616 if the policy 1606 contained in the policy communication 1616 is greater than the permissions associated with the external device 1618 and / or if the policy 1606 cannot be enforced (e.g., executing the policy 1606 is deemed greater than the capabilities of the system 1600, such as network zone bandwidth, external communication limits, memory storage limits, etc.). In certain embodiments, the policy management circuit 1602 may partially enforce the policy communication 1616 if the policy 1606 contained in the policy communication exceeds the permissions associated with the external device 1618 and / or if the policy 1606 cannot be fully enforced. For example, the policy management circuit 1602 may implement authorized portions of the policy communication 1616 and / or portions of the policy communication 1616 that the system 1600 has the capability to enforce.In certain embodiments, the policy management circuit 1602 implements portions of the policy communication 1616 according to priority, such as the associated endpoint, flow, application, or vehicle function of the policy communication 1616, for example, when full implementation is greater than the system's capabilities (e.g., implementing higher priority aspects until a limit is reached), and / or maximizes the implementation value of the policy communication 1616 (e.g., associating a value with each aspect according to the given aspect's associated priority, importance, or benefit description, e.g., when satisfying a group of several policy aspects of slightly lower priority is considered to be greater than the value of satisfying only a single higher priority policy aspect).

[0081] The example policy management circuit 1602 provides a policy notification 1620 to the external device 1618 in response to verifying the policy 1606. The example policy notification 1620 includes a confirmation that the policy 1606 was updated and / or stored in accordance with the policy communication 1616. The example policy notification 1620 includes a notification that the policy 1606 was not enforced (e.g., if the external device 1618 does not have authorization to enforce the policy communication 1616). The example policy notification 1620 includes a reason for the denial of the policy communication 1616 (e.g., lack of authorization, lack of functionality, etc.). The example policy notification 1620 includes a description of one or more aspects of partial enforcement of the policy communication 1616, e.g., which aspects of the policy communication 1616 were enforced, denied, and / or the reason for the partial enforcement. In certain embodiments, the policy management circuit 1602 can provide a policy notification 1620 to a separate external device (not shown) either instead of and / or in addition to the policy notification 1620 to the first external device 1618. In certain embodiments, the policy notifications 1620 to the separate external devices can have the same information or separate information. For example, the policy management circuit 1602 can provide a simple policy notification 1620 (e.g., denial of the policy communication 1616) to the requesting external device 1618 and provide a more detailed policy notification 1620 (e.g., details regarding the authorization that prevented enforcement of the policy communication 1616, the capacity that prevented enforcement of the policy communication 1616, and / or partial enforcement of the policy communication 1616) to the separate external device. In certain embodiments, the policy management circuit 1602 can provide the more detailed policy communication 1616 to the requesting external device 1618 and provide a simpler policy communication 1616 to the separate external device.

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

[0083] Without being limited to any other aspects of the present disclosure, exemplary aspects of policy 1606 include data collection parameters (e.g., data available to at least one network zone of the vehicle, e.g., data from any sensors, actuators, controllers, and / or endpoints at least selectively coupleable to the network zone and / or in communication with an endpoint of the network zone), data collection permission values ​​(e.g., sampling or communication rates, permission to provide data values ​​to the network zone, permission to request data values ​​from the network zone, resolution values ​​for the data, delay permission for the data, storage permission for the data, e.g., authorized data storage amount, data expiration criteria, and stale data handling parameters, e.g., compression and / or summarization operations performed on stale data and / or when allowed storage becomes limited due to lack of ability to communicate stored data externally or when competing storage priorities interfere with available storage planning), service subscription permission values ​​(e.g., service subscription permission values), and service subscription permission values. policy 1606 may include any one or more of the above with respect to local communication devices (e.g., endpoints, controllers, vehicle functions, flows, applications, etc.), external devices (e.g., specific devices or device categories, entities, and / or applications), service subscription permission values ​​(e.g., published services visible to associated local communication devices, details of services available to associated local communication devices, and / or permission to subscribe to services for associated local communication devices), and / or external communication permission values ​​(e.g., data rates, associated parameters, possible external addresses, possible APNs, aggregate data communication permissions, etc.). The policy 1606 may include any one or more of the above with respect to local communication devices (e.g., endpoints, controllers, vehicle functions, flows, applications, etc.), external devices (e.g., specific devices or device categories, entities, and / or applications).In certain embodiments, a given flow, application, or vehicle function may include aspects related to the 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] 17, an example system 1700 for providing off-vehicle communication control consistent with embodiments of the present disclosure is shown. The example 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 example system 1700 includes a CND 108 interposed between the first network zone 1612 and the second network zone 1614. A CND 108 inserted between network zones 1612, 1614 includes physical intermediation (e.g., communication between network zones 1612, 1614 passes through devices such as the CND 108 and / or a CEG, CES, or other network interface circuit controlled by it), and / or logical intermediation (e.g., when communication between network zones 1612, 1614 passes through devices controlled by the CND 108, and / or when the CND 108 adjusts communication between network zones 1612, 1614, e.g., passing data values, configuration of data values, data rate, data upsampling and / or downsampling, encapsulation operations, frame inclusion, and / or processing of passing communications, etc.).

[0085] The example system 1700 further includes a policy management circuit 1602 that interprets a policy 1606 that includes an active diagnostic description 1705, and a diagnostic execution circuit 1702 that provides a diagnostic command value 1712 to endpoints in the network zones 1612, 1614 in response to the active diagnostic description 1705. The example system 1700 includes an endpoint (endpoint 1708) in the first network zone 1612 and an endpoint (endpoint 1710) in the second network zone 1614. In the example system 1700, the endpoints 1708, 1710 include devices that are 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 operate actuators, and / or commands to operate a vehicle function (e.g., engine speed, power level, or to perform a higher level function, e.g., regeneration mode, scheduled test operation, etc.). The exemplary system 1700 enables successful execution of active diagnostic tests requested by an external device despite distribution of endpoints 1708, 1710 across multiple networks of vehicles, including when endpoints are moved between networks and / or when a given diagnostic command value 1712 is utilized to perform active diagnostic tests across different vehicles having different network configurations and different distributions of endpoints 1708, 1710.

[0086] 18 , an example endpoint 1708 includes a device control circuit 1802 that interprets a diagnostic command value 1712 and provides an actuator command value 1804 responsive to the diagnostic command value 1712. The example 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 may include commands such as “lock driver door,” “close exhaust gas recirculation valve,” or “increase motor temperature to 80° C.”, allowing abstraction between the diagnostic command value 1712 and the response of the actuator 1806 to obtain the diagnostic command value 1712. Additionally or alternatively, the diagnostic command value 1712 may be associated with a complex or sequential operation, such as an entire test sequence, and thus may be associated with many endpoints 1708, 1710, and / or multiple actuators 1806 across the system 1700 may be involved by a single diagnostic command value 1712.

[0087] The example system 1700 further includes a diagnostic execution circuit 1702 that determines whether vehicle operating conditions 1720 are consistent with diagnostic command values ​​1712 before providing the diagnostic command values ​​1712 to the endpoints 1708, 1710. For example, the diagnostic command values ​​1712 may include a diagnostic test that adjusts torque delivery of a vehicle prime mover, and the associated vehicle operating conditions 1720 may include parameters such as ensuring the vehicle is in neutral gear, ensuring the vehicle is not in prime mover mode, and / or ensuring the vehicle is in a selected test mode. In certain embodiments, vehicle operating conditions 1720 for a given diagnostic command value 1712 can be indicated in the active diagnostic description 1705, allowing active control of the vehicle operating conditions 1720 for the execution of the test (e.g., target temperature, specific state to be diagnosed, e.g., vehicle launch, high altitude operation, etc.) and / or considerations outside of the test (e.g., operator or service technician safety, fuel economy or emissions, impact on network communication speed, processing demands, and / or memory storage amount, etc.). In certain embodiments, the vehicle operating conditions 1720 for a given diagnostic command value 1712 can be forced by another flow, application, vehicle function, etc. with respect to the vehicle (e.g., a torque command cannot be adjusted separately from a driver command unless a specified vehicle state 1720 is present, etc.). The example system 1700 includes a policy 1606 that includes a diagnostic execution condition 1706 , and the diagnostic execution circuitry 1702 further determines whether the vehicle operating conditions 1720 match the diagnostic command values ​​1712 in response to the diagnostic execution condition 1706 .

[0088] The example system 1700 further includes a diagnostic execution circuit 1702 that performs diagnostic data collection operations responsive to the active diagnostic description 1705 and stores a diagnostic data set 1714 responsive to the diagnostic data collection operations. For example, the active diagnostic description 1705 may include certain data parameters to be collected, vehicle situational conditions to be monitored, and / or parameter thresholds to be determined (e.g., a temperature greater than a threshold). The stored diagnostic data set 1714 may include the collected data, the vehicle situational conditions determined therefrom, or a combination thereof. The collected data may be from endpoints 1708, 1710 responsive to the diagnostic command value 1712 (e.g., confirmation that an actuator has responded to the command, diagnostic data or fault codes related to the responsive actuator, etc.) or from endpoints 1708, 1710 other than those responsive to the command (e.g., observation of a temperature, pressure, speed value, situational confirmation, etc. not directly related to the operation endpoint 1708, 1710).

[0089] The example diagnostic execution circuit 1702 performs processing operations on the collected data during diagnostic data collection operations and stores a diagnostic data set 1714 responsive to the processing operations. For example, the stored diagnostic data set 1714 may include status information, virtual sensor information, negative information (e.g., storing only data related to operation when a threshold is not met), upsampled and / or downsampled values ​​for the collected data, and / or any other processing operations described throughout this disclosure. Exemplary, non-limiting processing operations on the collected data or portions thereof include compressing the collected data, summarizing the collected data, operating a virtual sensor using the collected data, determining vehicle operating conditions responsive to the collected data, determining a diagnostic data set responsive 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 example diagnostic execution circuit 1702 further communicates a diagnostic data set 1714 responsive to the diagnostic data collection operation to an external device (e.g., 1618). The external device receiving the diagnostic data set 1714 can be the same or a different external device as the external device providing the active diagnostic description 1705. The example diagnostic execution circuit 1702 further processes the collected data before communicating it to the external device, which processing can include initial processing to determine the diagnostic data set 1714 to be stored and / or further processing operations 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. The example diagnostic execution circuit 1702 then performs selected operations, such as further processing the diagnostic dataset 1714 before communicating it to the external device (e.g., to reduce external data communication in response to data selected for transmission by the external device), and / or communicating the diagnostic dataset 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 needed from the external device for all of the diagnostic dataset 1714), and / or communicating additional selected portions of the diagnostic dataset 1714 (e.g., data requested by the external device), and / or retaining the diagnostic dataset 1714 and / or a further processed form of the diagnostic dataset 1714 stored for a selected period of time, and / or deleting the diagnostic dataset 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).Operation of system 1700 can be seen to enable active diagnostic operations to be performed by external devices (e.g., service tools, service applications, cloud-based applications, fleet service computing devices, and / or third-party applications) involved with endpoints on vehicles over a mixed network, enable diagnostic operations that can support multiple configurations of vehicles without requiring knowledge of the location and / or makeup of endpoints on the vehicles, and / or can support configuration changes of the vehicles. Additionally or alternatively, operation of system 1700 can enable planned data transmission, including reduced transmitted data, while achieving powerful active diagnostic capabilities, and further enable planned consumption of on-vehicle processing, memory, and inter-network communication resources while achieving this powerful active diagnostic capabilities.

[0091] The example system 1700 includes a diagnostic validation circuit 1704 that determines a diagnostic confirmation value 1716 based on the actuator responses to the diagnostic command value 1712 (e.g., confirms whether the actuators performed the commanded function and / or whether the vehicle, across the actuators, performed an active diagnosis in accordance with the active diagnostic description 1705). The example diagnostic validation 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, the diagnostic validation circuit 1704 adjusts the storage and / or communication of the 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 performing an active diagnosis. In certain embodiments, the diagnostic execution circuit 1702 may store all or a portion of the diagnostic data set 1714 as a rolling buffer of data and save selected portions of the diagnostic data set 1714 in response to the diagnostic validation circuit 1704 providing a diagnostic confirmation value 1716 (e.g., if the diagnosis has a time value or actuator position as part of the diagnostic execution, allowing the diagnosis to be fully determined when a timer or other accumulation state completes).

[0092] The example active diagnostic description 1705 includes a target device description 1718 (e.g., fuel actuator, engine controller, door actuator, mirror position adjustment actuator, etc.), which does not identify on which network zone 1612, 1614 its corresponding endpoint is located. The example 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 responsive to the target device description 1718, and the diagnostic execution circuit 1702 further provides a diagnostic command value 1712 to the endpoint responsive to the network address value 1722. For example, the target device description 1718 can include a standardized description for the endpoint (e.g., engine speed, ambient temperature, passenger seat occupancy sensor, etc.), and the configuration circuit 1604 has access to a configuration table that associates the standardized description with a local network address for the intended component. Additionally or alternatively, target device description 1718 may have a description matching a baseline product (e.g., the 2020LX version of a given vehicle), a description matching an original version of the vehicle (e.g., when the vehicle was configured after manufacture), and / or a description matching an earlier version of the vehicle (e.g., when the vehicle included a point in time of a certain date). In certain embodiments, the configuration table or other information utilized by configuration circuit 1604 to determine network address value 1722 may 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 policy 1606.

[0093] The example active diagnostic description 1705 includes a target device description 1718 (e.g., a fuel actuator, an engine controller, a door actuator, a mirror position adjustment actuator, etc.) that identifies an endpoint on one network zone (e.g., a first network zone 1612), and the configuration circuit 1604 determines that the endpoint is on another network zone (e.g., a second network zone 1614) in response to the target device description 1718. For example, the configuration circuit 1604 may determine that the target device description 1718 indicates an incorrect or absent device and / or further determine that an external device is utilizing a previous, different, and / or standardized configuration file to provide the target device description 1718, and the configuration circuit 1604 utilizes a 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 determines the proper network address value and / or network zone for this endpoint using other information from the target device description 1718, such as parameter names, intended function, etc. Similarly, the configuration circuit 1604 can correct the target device description 1718 that indicates an incorrect address, such as an incorrect network zone, or another address on the first network zone when the correct address is an address on the first network zone.

[0094] Operation of the configuration circuit 1604 may enable simplification of active diagnostic descriptions (e.g., external devices do not need system-specific information related to endpoint location and network distribution), adaptation of diagnostic execution as vehicle endpoints and / or local communication devices are moved and / or upgraded, and / or an abstraction layer between external devices and the vehicle's configuration. Simplification and / or abstraction of active diagnostic definitions from vehicle network configuration may enable lower costs of active diagnostic development and launch, and an expanded user base seeking active diagnostic development (e.g., with increased protection of vehicle configuration information and / or sensitive information such as data compartmentalization), thereby improving overall diagnostic capabilities, improving the vehicle operator experience, and increasing competition and implicit competition in the development and implementation of active diagnostics.

[0095] 19 , an exemplary system 1900 includes a vehicle 102 having a first legacy network zone 1902 and a second advanced 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 advanced network zone 1904 can be a second network type, such as an Ethernet network. In certain embodiments, the second advanced network zone 1904 can be the same type as the first legacy network zone 1902, but a more highly capable version, such as a high-speed CAN bus, a faster Ethernet network, etc. In certain embodiments, a system 1900 such as that shown in FIG. 19 can exist when a vehicle transitions to an upgraded network type, for example, during a transition over several vehicle model years, when new components utilizing a more highly capable network are added to the vehicle, and similar times.

[0096] The exemplary system 1900 includes a CND 108 interposed between a first conventional network zone 1902 and a second intelligent network zone 1904, the CND 108 including a policy management circuit 1602 that interprets a policy 1606 including an external communication value 1906, and an external communication control circuit 1908 that coordinates communications between an external device 1618 and an endpoint of the first conventional network zone 1902 and / or an endpoint of the second intelligent network zone 1904 in response to the external communication value 1906. For example, external communications between endpoints in the first conventional network zone 1902 may be restricted to reduce traffic generated by communications to and from external devices 1618 on the first conventional network zone 1902 and / or due to the need to protect endpoints on the first conventional network zone 1902 (e.g., if vehicle control and / or proprietary information is maintained on the first conventional network zone 1902 and / or if security protocols associated with the first conventional network zone 1902 are more restrictive than those available in the second advanced network zone 1904). In another example, external communications between endpoints of the second advanced network zone 1904 can be limited to reduce external transmissions from the vehicle (e.g., utilizing a specific data provider for those routed through the vehicle's transceiver) due to the potentially large number of devices on the second advanced network zone 1904, including devices that may have been recently added to the vehicle (and therefore do not have a long known usage history, security pre-screening, and / or vehicle operation impact data) and / or devices that may have been added by an entity and are not as closely controlled as the provider of the devices on the first conventional network zone 1902 (e.g., devices such as entertainment providers that may be provided by third parties and that are involved in recently developed vehicle functions and / or not core vehicle functions) (e.g., where the higher capability devices on the second advanced network zone 1904 may have the ability to generate high data rates).The reasons presented for restricting external traffic between endpoints and external devices on various networks are non-limiting and are presented for illustrative purposes, but the external communications control circuitry 1908 may regulate communications between endpoints in any network zone and any external device for any reason.

[0097] The example system 1900 includes external communication values ​​1906 that may include active diagnostic descriptions, e.g., diagnostic operations and / or data collection performed as diagnostic operations, and may include commands to, data collected from, and / or communications with any endpoints on any network zone of the vehicle. The example system 1900 includes external communication values ​​1906 that may include active test descriptions, e.g., test operations (e.g., testing any endpoints, actuators, sensors, flows, applications, vehicle functions, and / or vehicle controllers on the vehicle), and may include commands to, data collected from, and / or communications with any endpoints on any network zone of the vehicle. The example system 1900 includes external communication values ​​1906 that may include data request values ​​(e.g., data parameter collection from any endpoint and / or processing of data parameters) and / or vehicle command values ​​(e.g., commands to any actuators, displays, controllers, etc. associated with any endpoint). Exemplary, non-limiting external devices 1618 include service tools, manufacturer tools, seller tools, and / or cloud-based tools.

[0098] The example external communication value 1906 includes a target device description that includes identification information for the target endpoint (e.g., network zone, local address, sensor name, actuator name, data parameter name, etc.), and the external communication control circuitry 1908 determines that the endpoint has a different configuration (e.g., different network zone, local address, sensor name, actuator name, data parameter name, etc.) than the identification information indicated in the target device description. In certain embodiments, the external communication control circuitry 1908 can include or utilize the configuration circuitry 1604 (see, e.g., FIGS. 16, 17 and related discussion) to determine the proper identification information for the target endpoint. The example external communication value 1906 does not include identification information for the target endpoint, and the external communication control circuitry 1908 provides the proper identification information for the target endpoint based on the external communication value 1906 (again see, e.g., FIGS. 16, 17 and related discussion including the operation of the configuration circuitry 1604). It can be seen that operation of the system 1900 enables the external device 1618 to operate across several vehicle configurations to perform active diagnostics, testing, and data collection without specific knowledge of endpoint locations, parameter names, local addresses, etc. The vehicle configurations can represent changes in the vehicle after service repairs, replacement of components (e.g., endpoints), upgrades of components and / or executable instructions stored on a computer-readable medium, changes across multiple model years, and / or changes in the vehicle due to campaigns, upgrades, and / or remanufacturing.

[0099] 20, an example apparatus 2000 for providing a network overview for one or more networks of a vehicle having a mixed network is shown. The example apparatus 2000 can be used with any of the vehicles described throughout this disclosure, and aspects of the apparatus 2000 can be located on the vehicle, on an external device in at least selective communication with the vehicle, on a cloud server, and / or on a web application.

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

[0101] The example device 2000 further includes a display interface circuit 2006 that transmits visualization data 2018, provides stored visualization data 2022 to the electronic display 2012, and / or provides visualization data 2018. Transmitting the visualization data 2018 may include any one or more operations selected from the following: transmitting the visualization data 2018 from the vehicle to a tool; transmitting the visualization data 2018 from the vehicle to a cloud server; transmitting the visualization data 2018 from the vehicle to a display device (e.g., electronic display 2012, e.g., a vehicle display, a service tool, an external computing device, e.g., a driver device, a service device, a manufacturer device, a fleet owner device or service device, a vehicle communications administrator device, and / or a third party device, etc.); transmitting the visualization data 2018 from the cloud server to a tool; transmitting the visualization data 2018 from the cloud server to a display device; and / or transmitting the visualization data 2018 from a first cloud server to a second cloud server (e.g., enabling distributed storage standards among the cloud servers for the stored visualization data 2022, including data anonymization, data aggregation, and partitioning aspects of the data). In certain embodiments, transmitting the visualization data 2018 may include transmitting the visualization data 2018 to on-vehicle storage (e.g., dedicated memory space available for visualization data 2022 to be stored for later access, access request, and / or later transmission to a location outside the vehicle), and / or to storage coupled nearby (e.g., a USB device coupled to the vehicle, a mobile device such as the driver's mobile phone, and / or a computing device over short-range wireless communication such as a WiFi or Bluetooth connection).Additionally or alternatively, transmitting the visualization data 2018 may include any one or more operations selected from the following: 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 secure cloud storage; and / or transmitting the visualization data 2018 to 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 example device 2000 includes an electronic display 2012 that interprets and displays visualization data 2018. The example electronic display 2012 accesses stored visualization data 2022 and displays at least a portion thereof and / or the visualization data 2018 and / or processed visualization elements determined from the stored visualization data 2022. The example visualization data 2018 includes topology data corresponding to the network topology of the first network and / or the second network (e.g., depicting the networks and / or selected endpoints connected to each thereof). The topology data may include a visual representation, tabular listing, or other visualization thereof.

[0103] The example visualization circuit 2004 is further structured to include a portion of the metadata of the vehicle communication data 2016 within the visualization data 2018. Example, non-limiting metadata of the vehicle communication data 2016 includes data such as source addresses, destination addresses, timestamps, vehicle operating or state conditions, fault code information, status parameters related to destinations, flows, applications, and / or vehicle functions, etc. In certain further embodiments, the metadata of the vehicle communication data 2016 includes information about the trajectory of the vehicle communication data 2016 through the vehicle network, such as frame data related to the original communication (e.g., frame data from a 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 frames of the vehicle communication data 2016 (e.g., a description of processing operations performed on the payload and / or frames of the communication, e.g., to enable reverse computation of the processing, upsampling and / or downsampling, etc.). In certain embodiments, the metadata may have predetermined values, such as a first data value for a first processing operation (e.g., filtering, changing resolution, etc.), and a second data value for a second processing operation, thereby communicating the processing operation (or other operation) according to the value (e.g., designated bit) of a selected portion of the vehicle communication data 2016.

[0104] The example apparatus 2000 includes an input monitor circuit 2014 that interprets data filtering values ​​2020 (e.g., selection of certain endpoints and / or local communication devices, selection of certain network zones, communications meeting specified criteria, downsampled descriptions for selected communications, communications relating to abnormal conditions such as endpoints, flows, vehicle functions, and / or applications with associated fault values, and / or communications relating to endpoints with packet loss, high or low communication rate expectations). Example, non-limiting data filtering values ​​2020 include network address associations, vehicle control device associations, vehicle system associations, network protocol types, endpoint identifiers, data types, application associations, and / or flow associations. Example, non-limiting data filtering values ​​2020 include references to systems such as an engine system, a steering system, a braking system, a fuel system, a prime mover system, an anti-lock braking system, a traction control system, and / or a drivetrain control system. Further exemplary and non-limiting data filtering values ​​2020 include references to systems such as security systems, lighting systems, safety systems, climate control systems, ADAS, and / or infotainment systems.

[0105] The example apparatus 2000 includes a visualization circuit 2004 that filters the vehicle communication data 2016 based at least in part on the data filtering values ​​2020 to generate visualization data 2018. In certain embodiments, the data filtering values ​​2020 can be provided within a policy 1606 that is communicated from an external device 1618 and / or received (e.g., by the display interface circuit 2006) through a user interface and / or through interaction with a cloud- or web-based application running on the electronic display 2012, the external tool 2014, and / or a user device, e.g., a device of a vehicle owner or operator, service technician, manufacturer, fleet owner, fleet service technician, vehicle communications manager.

[0106] Referring to FIG. 22 , an exemplary user interface for retrieving 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 depicted in FIG. 22 , “Switch 0” corresponds to a first network zone, “Switch 1” corresponds to a second network zone, and allows a user to select monitored endpoints from each network zone. In this example, filter choices allow narrowing down the monitored endpoints (e.g., left-side choices) according to filtering criteria, e.g., to include only selected endpoints, flows, applications, etc. (right-side choices). In the example depicted in FIG. 22 , monitored parameters can be further downsampled (bottom choices). In the example depicted in FIG. 22 , a selected mirroring timeout can be configured (e.g., if monitoring is implemented using port mirroring). The exemplary user interface depicted in FIG. 22 illustrates certain aspects of the network monitoring and filtering operations described herein and is not limited to the present disclosure.

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

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

[0109] The example device 2000 includes visualization data including network activity profiles provided for one or more of an endpoint, 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 on one of the first network or the second network.

[0110] Referring to FIG. 24 , exemplary visualization data 2018 including a network activity profile is shown. The example depicted in FIG. 24 depicts network bandwidth utilization for a selected network zone using several utilization plots 2402, 2404, 2406, and 2408, each relating to an endpoint of the selected network zone. Referring to FIG. 25 , exemplary visualization data 2018 including a network activity profile for a selected network zone is shown. The example depicted in FIG. 24 depicts overall activity for the network zone in the top row, network bandwidth utilization for specific devices (e.g., ISL0, ISL1) in the middle row, and network bandwidth utilization for a vehicle controller (e.g., a head-up display and head unit) in the bottom row, which further depicts utilization for several specific devices (e.g., various cameras in this example) broken out. The examples depicted 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 further grouped and / or sub-grouped in any manner by endpoint, flow, application, vehicle function, vehicle controller, etc.

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

[0112] In certain embodiments, retrieving vehicle communication data 2016 including traffic monitor, network activity, and / or messages corresponding to an endpoint of a network zone and / or a port of a network zone includes mirroring traffic from a first port of the 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 may correspond to the monitored endpoint, in which case retrieving vehicle communication data 2016 includes mirroring the first port of the second network zone 2010 to a second port of the second network zone 2010 (e.g., if a monitoring tool such as vehicle communication circuitry 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 , an example visualization 2018 is shown that includes data flows between selected network participants (e.g., endpoints, flows, applications, vehicle controllers, etc.). The example depicted in FIG. 26 depicts data flows between selected endpoints, in this example depicting data flows associated with “EP1” (e.g., an endpoint such as a head unit) and other endpoints (e.g., EP3, EP5, and EP10, in this example, ADAS-related components, such as a parking controller). The example depicted in FIG. 26 allows for monitoring of the network to determine whether expected data flows are occurring, whether anomalous data flows are occurring, etc. Referring to FIG. 27 , an example visualization 2018 is shown that shows overall network activity for a selected network zone (top row) and data path tracing from a selected endpoint to other endpoints in the system (data paths in the bottom row). In this example, user interface elements can be provided that, for example, provide selection of the time (top row) utilized for the data path tracing in the bottom row, allow selection of a target endpoint (e.g., EP1 on the left), and / or allow selection of whether to depict transmission, reception, or both. In certain embodiments, visualization data 2018 may be provided as a user interface, for example, that allows a user to select a component and has the associated data flow shown. It can be seen that visualizations such as those shown in Figures 26 and 27 can be used to confirm expected operation and diagnose problems (e.g., degradation in component operation, diagnosing network problems, and / or detecting abnormal operating conditions, such as those shown in communications between components that communicate more during certain abnormal operating conditions). Additionally or alternatively, visualizations such as those shown in Figure 26 can be used to aggregate applications, flows, vehicle functions, etc. on vehicle controllers (e.g., to reduce network traffic requirements) and / or identify potential redundant or unnecessary network communications to improve network topology design, hardware selection, and / or protocol selection.

[0114] Referring to FIG. 21 , an exemplary local address table 2100 is shown, generally illustrating configuration information consistent with various embodiments of the present disclosure. The exemplary local address table 2100 may be part of policy 1606 and / or a configuration file (e.g., accessible in whole or in part by the interface circuitry and / or configuration circuitry). The local address table 2100 may be provided as a data structure in memory locations accessible to the interface circuitry, configuration circuitry, and / or other implementing components described throughout this disclosure. The local address table 2100 may be provided as a distributed data structure, portions of which are provided as data structures in memory locations accessible to the implementing components. While the exemplary local address table 2100 is shown to provide an example of the type of local address information that can be utilized to implement aspects of the present disclosure, the details of the stored information and the organization of the data structure implementing the local address table 2100 may be configured according to an implementing embodiment. The exemplary local address table 2100 includes an endpoint identifier 2102, which may be a local identifier of an endpoint present in the system. In yet another example, a non-local endpoint identifier (not shown) may be included that, for example, allows an external device to refer to the endpoint using industry-standard terminology or other selected terminology. The exemplary local address table 2100 includes, for example, a network zone identifier 2104 that indicates which network zone the endpoint is considered to be part of. Additionally, the exemplary local address table 2100 includes, for example, local address values ​​2106 that indicate how each endpoint is addressed on the appropriate network zone. In certain embodiments, the exemplary local address values ​​2106 may be a TCP / IP address, port number, or other identifier. In certain embodiments, the local address values ​​2106 may include, for example, a message identifier, such as a value that is included in a message to indicate the intended destination (or source) of the message to or from the endpoint on a logical bus architecture such as a CAN bus.The example local address table 2100 includes external address values ​​2108, which may include, for example, addresses utilized by external devices to identify endpoints.

[0115] Use of the external address value 2108 allows an external device to extract knowledge of the endpoint, including local addressing and / or associated network zone, from operations that utilize and / or collect data from the associated endpoint. It can be seen that it is possible to include further information within the local address table 2100, such as additional external address values ​​(e.g., allowing multiple external addresses to be associated with a given endpoint in the system), and / or the inclusion of one or more additional non-local endpoint identifiers (e.g., allowing multiple industry standards, proprietary designations, informal designations, etc. to be successfully associated with a given endpoint in the system). In certain embodiments, one or more of the external addresses 2108 and / or non-local endpoint identifiers may further be associated with a version (e.g., interface version, vehicle model description, etc.) to enable implementation components using the local address table 2100 to interpret data commands and / or requests from external applications, algorithms, etc. and properly associate desired endpoints with these data commands and / or requests when changes occur within the vehicle (e.g., an endpoint is moved between network zones and / or addresses) or outside the vehicle (e.g., an external application is updated that is no longer applicable to a particular vehicle in the system for an updated vehicle configuration).

[0116] It can further be seen that utilization of the local address table 2100 enables multiple addressing support for a vehicle's endpoints, e.g., providing both IPv4 and IPv6 addressing for a vehicle's endpoints. In certain embodiments, the local address table 2100 can be extended, or alternatively, separate data structures can be maintained, enabling association of endpoints with applications, flows, vehicle functions, vehicle controllers, APNs, external data routing paths, or network zone trajectories, etc. Thus, a given application, such as "route management," can be associated with specific endpoints for a vehicle, and these associations can persist throughout the endpoint's movement (e.g., from one network zone to another). Utilization of the local address table 2100 and / or extended or alternative data structures described herein provides for configuration of priority, admission, subscription management (both publishing and subscribing to services), and / or any other communication coordination activities described herein.

[0117] In certain embodiments, the local address table 2100 can be extended, or alternatively, separate data structures can be maintained, allowing addresses of external devices to be configured according to endpoint, application, flow, vehicle function, and / or vehicle controller. For example, a given vehicle function can be allowed access to a given external resource (e.g., a routing function that accesses the external resource and has maps, traffic reports, etc.), and the associated external address that provides access to the external resource is associated with the vehicle function. In this example, other vehicle functions can be denied access to this given external resource; instead, the associated external address is associated with the vehicle function (and / or lost association with these other vehicle functions, depending on the implementation) so that a default address, protection space, null communication, or other selected behavior is implemented when these other vehicle functions request access to this external resource. Thus, a first application in the vehicle requesting access to an external resource, such as https: / / www.google.com, may receive the expected generic access to an external IP address corresponding to the Google website, whereas a second application in the vehicle requesting access to the same external resource may receive an access denied indication, a default external resource indication (e.g., indicating that the requested resource is a cloud-based resource within the protected space and is not permitted), or some other selected response from the system. Thus, the local address table 2100 and / or its extended or alternate versions may be utilized as a local DNS and / or an external DNS. In certain embodiments, for example, if 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, an external DNS (e.g., on a cloud server or from an Internet provider) that is outside the vehicle and provides an external address may be accessible.In certain embodiments, an external DNS on the vehicle may be updated based on addresses retrieved from an external DNS outside the vehicle.

[0118] 28, an example 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 depicted in FIG. 28 includes a CND 108 interposed between the network zones 1612, 1614. The example CND 108 includes a policy management circuit 1602 that interprets a policy 1606 that includes a network adjustment description, and a configuration circuit 1604 that includes a first network interface circuit 1608 that is responsive to the network adjustment description, where the first network interface circuit 1608 adjusts communications between an end point in the first network zone 1612 and an end point in the second network zone 1614. Additionally or alternatively, the configuration circuit 1604 configures, in response to the network coordination description, a gatekeeper interface circuit 2802 that coordinates communications between an endpoint of at least one of the network zones 1612, 1614 and an external communication portal and / or external device 1618. An exemplary first network interface circuit 1608 includes a CEG, the first network zone 1612 is not a primary 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 send and receive communications passed between the network zones 1612, 1614.

[0119] 29 , the exemplary network adjustment description 2904 includes a data request permission description 2906 that includes data values ​​2910 for data requestors 2908 (e.g., each an endpoint on one of the network zones 1612, 1614). The exemplary first network interface circuit 1608 adjusts communications between an endpoint on the first network zone 1612 and an endpoint on the second network zone 1614 in response to the data request permission description 2906, e.g., restricting the associated data requestor 2908 to authorized data values ​​2910 and / or preventing the associated data requestor 2908 from accessing unauthorized data values ​​2910. In certain embodiments, the first network interface circuit 1608 also adjusts communications between endpoints on 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 example system 2800 further includes a configuration circuit 1604 that includes a second network interface circuit 1610 responsive to the network adjustment description, where the second network interface circuit 1610 adjusts communications between endpoints in the second network zone 1614. Referring again to FIG. 29 , the example second network interface circuit 1610 adjusts communications between endpoints in the second network zone 1614 and endpoints in the first network zone 1612 responsive to the data request permission description 2906, e.g., to restrict an associated data requester 2908 to authorized data values ​​2910 and / or prevent an associated data requester 2908 from accessing unauthorized data values ​​2910. In certain embodiments, the second network interface circuit 1610 further coordinates 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 example system 2800 further includes a configuration circuit 1604 that includes a gatekeeper interface circuit 2802 responsive to the network coordination description 2904, where the gatekeeper interface circuit 2802 coordinates communications between endpoints in both the first network zone 1612 and the second network zone 1614 and the external device 1618. The example external device 1618 may be coupled to the first network zone 1612, the second network zone 1614, or both. Additionally or alternatively, the external device 1618 may be coupled to a transceiver (not shown) in the vehicle 102, which may be a cellular, WiFi, and / or Bluetooth transceiver. In certain embodiments, the transceiver may be communicatively coupled to a network zone, e.g., a port on 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 a CES that includes the second network interface circuit 1610.

[0122] 29 , the exemplary data request permission description 2906 includes data access permissions 2914 associated with each of several external communicators 2912. The external communicators 2912 include identified external devices 1618, external applications, external flows, external entities (e.g., service technicians, manufacturers, owners, drivers, etc.), external addresses, etc. The exemplary data access permissions 2914 include permissions to communicate with specific endpoints, flows, applications, vehicle functions, network zones, vehicle controllers, etc. In certain embodiments, the data access permissions 2914 may be distinct for outgoing and incoming communications; 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 the given external communicator 2912. The example data request permission statement 2906 includes data access permissions associated with one or more of an external device, an external communicator, an endpoint, a flow related to the external device, and / or an external communicator, a vehicle function related to the endpoint, the external device, and / or an external communicator, and / or an application related to the endpoint, the external device, and / or an external communicator. The example and non-limiting data access permissions 2914 include one or more of the ability to request, send, and / or publish data, the ability to request, send, and / or publish specific data values, and / or external communication bandwidth restrictions (e.g., data rate, aggregate data volume per unit time, and / or share of available bandwidth). The example system 2800 further includes a gatekeeper interface circuit 2802 that coordinates communications between endpoints in the network zones 1612, 1614 and the external device 1618 (and / or the external communicator 2912) in response to the data request permission statement 2906 and / or the data access permissions 2914.

[0123] The exemplary gatekeeper interface circuit 2802 further adjusts communications with the external device 1618 (and / or external message 2912) in response to a flow associated with the adjusted communication (e.g., adjusting permissions based on the priority of the associated flow, the role of the associated flow, and / or current operating conditions, etc.), adjusts in response to a data type associated with the adjusted communication (e.g., raising or lowering the priority of certain data types, restricting certain data types to certain communication conditions such as the availability of high-speed data communications, typing data according to criteria such as the age of the data, etc.), and so forth. adjusting permissions accordingly), adjusting in response to a data service provider regarding the adjusted communication (e.g., configuring data rates, bandwidth, and / or aggregate data values ​​in response to a data service provider regarding the data), adjusting in response to vehicle functions regarding the adjusted communication (e.g., prioritizing certain vehicle functions), and / or adjusting in response to a connection type of a communicative coupling with an external device 1618 (and / or external communicator 2912) (e.g., allowing for higher communication speeds when a higher speed and / or cheaper data connection is available).

[0124] The example system 2800 includes a configuration circuit 1604 that receives a policy update (e.g., from the policy management circuit 1602) that includes changes to the network adjustment description 2904 and 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 changes to the network adjustment description 2904. In yet another example, the policy management circuit 1602 interprets an authorization associated with the policy update based on, for example, the permission of the external device 1618 and / or the external communicator 2912 that provides the policy update. The example 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 communicator 2912) is not authorized to make the changes to the network adjustment description in the policy update. In certain embodiments, the policy management circuit 1602 may additionally or alternatively provide one or more policy notifications 1620 to the requesting unit and / or other external devices 1618 or external communicators 2912 in response to suppressing or partially suppressing the policy update (see, e.g., FIG. 16 and related discussion). Exemplary, non-limiting requesting units include one or more of an entity for the policy update, an application for the policy update, a flow for the policy update, a vehicle function for the policy update, an identifier of an external device communicating the policy update, and / or an identifier of an external communicator for the policy update.

[0125] 28 , the example policy management circuit 1602 interprets a policy 1606 that includes a network usage permission description 3004 (see FIG. 30 ). The example network usage permission description 3004 includes an external data access description 3006, where 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 coordinates communications with the external device 1618 in response to the external data access description 3006. The example external data access description 3006 includes an external access permission 3014 associated with an external communicator 3012, such as an identified external device 1618, an external application, an external flow, an external entity (e.g., service provider, manufacturer, owner, driver, etc.), or an external address. In certain embodiments, the external messager 3012 includes one or more local communication devices requesting external communication, e.g., a flow of a vehicle, an application, a network zone of a vehicle, an endpoint of a network zone, etc. For example, the example gatekeeper interface circuit 2802 regulates the external communication based on a flow association of the communicating ones of the first network zone and / or the endpoint of the second network zone (e.g., restricting the external communication to communications permitted in accordance with the external access permission 3014 and / or allowing external communication not excluded by the external access permission 3014). The example gatekeeper interface circuit 2802 regulates the external communication based on an application association of the communicating devices (e.g., the external device 1618 and / or the endpoint), e.g., restricting the external communication to communications permitted in accordance with the external access permission 3014 and / or allowing external communication not excluded by the external access permission 3014.The example gatekeeper interface circuit 2802 coordinates the external communication based on the network zone association of the communication device (e.g., the network zone or source zone associated with the endpoint requesting the external communication and / or the network zone or destination zone that is the target of the external communication), e.g., restricting the external communication to those allowed in accordance with the external access permission 3014 and / or allowing external communication that is not excluded by the external access permission 3014. In certain embodiments, the first network zone and the second network zone may be separate virtual local area networks of the vehicle and may have separate external access permission 3014.

[0126] The exemplary policy 1606 includes an external data quantity description (not shown), where the configuration circuit 1604 includes a gatekeeper interface circuit 2802 responsive to the external data quantity description. The exemplary external data quantity description includes a data limit for an application, where the gatekeeper interface circuit further regulates the external communication based on an association of the application with a communicating device. The application may be a vehicle operation-related application (e.g., an application running on the vehicle and / or an application running on an external device in an interactive situation that can communicate with the vehicle) or an application unrelated to vehicle operation (e.g., an infotainment application, a driver application, web browsing utilizing the vehicle's network zone, a third-party application communicating with the vehicle, etc.). The exemplary external data quantity description includes a data limit for an endpoint of one of the network zones, where the gatekeeper interface circuit regulates the communication based on the source or destination endpoint of the regulated communication. The exemplary external data quantity description includes a data limit for a flow, where the gatekeeper interface circuit regulates the external communication based on an association of the flow with a communicating device.

[0127] Exemplary, non-limiting data limits include one or more of: a communication data amount associated with a selected time period (e.g., MB per hour, GB per month, etc.); a communication data amount associated with a selected vehicle operating condition (e.g., MB per trip, data rate during idle operation, data rate at rated operation, data rate during sudden transient operation, etc.); a communication data amount corresponding to a data provider for an application, endpoint, and / or flow; a transceiver bandwidth allocation utilized for communication; a transceiver bandwidth volume utilized for communication; a transceiver channel bandwidth allocation (e.g., if the transceiver includes more than one channel and the bandwidth allocation is limited for channels providing external communications for the application, endpoint, and / or flow); and / or a transceiver channel bandwidth volume (e.g., if the transceiver includes more than one channel and the bandwidth volume is limited for channels providing external communications for the application, endpoint, and / or flow).

[0128] 31 , the example network usage permission description 3004 includes a network usage description 3102 corresponding to a network zone 3104 and a communication device description 3106 corresponding to a local communication device, such as an endpoint, a flow, a vehicle function, and / or an application. In this example, the gatekeeper interface circuit 2802 further coordinates the external communication based on the network usage description 3102 and the communication device (e.g., corresponding to the communication device description 3106) associated with the coordinated communication. The example network usage description 3102 includes determining a priority 3108 for the communication device to coordinate the external communication, an associated flow 3110, an associated vehicle function 3112, an associated application 3114, and / or an associated condition or event 3116 (e.g., a trigger event for implementing aspects of the policy 1606, a vehicle condition or other condition that exists to enable implementation of aspects of the policy 1606, and / or a vehicle condition or other condition that, if present, modulates or inhibits aspects of the policy 1606). The network usage description 3102 may include one or more of the bandwidth of the network zone 3104 available to use to support external communications, the data rate of the network zone 3104 available to use to support external communications, the bandwidth limit of the network zone 3104 (e.g., external communications may be throttled or reduced if they are deemed to cause general overages), and / or the data rate limit of the network zone 3104 (e.g., external communications may be throttled, reduced, or delayed if they are deemed to cause general overages). In certain embodiments, the priority 3108 or information regarding the external communications may be compared to the priority of on-vehicle communications using the network zone, and the external communications may be prioritized over the on-vehicle communications, and the on-vehicle communications may be throttled, reduced, or delayed until the external communications are provided.In certain embodiments, service requirements (e.g., QoS parameters) for endpoints, flows, applications, vehicle functions, etc. on the vehicle (e.g., local communication devices) can be considered in determining external communication allowance, and external communication can be allowed while the service requirements can be satisfied.

[0129] 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 interposed between the first network zone 3202 and an external device 3210 and between the second network zone 3204 and the external device 3210. The gatekeeper interface circuit 3206 may be physically interposed, for example, if communications between the zones 3202, 3204 and the external device 3210 pass through the gatekeeper interface circuit 3206, or may be logically interposed, for example, if communications between the zones 3202, 3204 and the external device 3210 are coordinated 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 interposed between the zones 3202, 3204 and the transceiver 3208. 32 is shown as a single device, a given vehicle may have several transceivers (not shown). The example gatekeeper interface circuit 3206 coordinates communications between a selected number of zones 3202, 3204 on the vehicle 102 and the selected transceiver 3208. For example, but not by way of limitation, operation of the gatekeeper interface circuit 3206 may restrict external communications with 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 vehicle's ability to perform selected missions (e.g., restricting foreign and / or malicious network traffic on the selected zones 3202, 3204). In another example, but not limited to, operation of the gatekeeper interface circuit 3206 can restrict utilization of the selected transceiver 3208 to conserve external communication bandwidth, limit the amount and / or rate of data passing through the transceiver 3208, and / or ensure that external data communications are attributed to the appropriate local communication device and / or data service provider.

[0130] 33, in certain embodiments of the present disclosure, an exemplary CND 108 consistent with the example described in FIG. 32 is shown. The exemplary CND 108 includes a gatekeeper interface circuit 3206 and further includes a policy management circuit 3302 that interprets a policy 1606 that includes a network adjustment description, and a configuration circuit 3304 that includes a first network interface circuit 3306 and / or a second network interface circuit 3308 in response to the policy 1606, where the network circuits 3306, 3308 adjust communications between endpoints in their respective network zones (intra-network communications) and / or across their respective network zones (inter-network communications). While the example described in FIG. 33 shows two network interface circuits 3306, 3308, operation of the gatekeeper interface circuit 3206 can be implemented with only one network interface circuit, a subset of the available network interface circuits, or all network interface circuits. 34, the example CND 108 includes a second network interface circuit 3308, and a gatekeeper interface circuit 3206 coordinates communications between a second network zone 3204 and an external device 3210. In the example depicted in FIG. 34, external communications from a first network zone 3202 are provided to the second network zone 3204 through the first network interface circuit 3306 and are thereby coordinated by the gatekeeper interface circuit 3206 as communications on the second network zone 3204. Additionally or alternatively, external communications from a network zone (such as the first network zone 3202) may not be coordinated 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] 35, the exemplary vehicle 102 includes a vehicle controller 3502, where the gatekeeper interface circuit 3206 is located on the vehicle controller 3502. The exemplary gatekeeper interface circuit 3206 coordinates external communications between a selected network zone 3204, 3202 and an external device 3210. The exemplary gatekeeper interface circuit 3206 and / or the vehicle controller 3502 may be an endpoint of a second network zone 3204. Referring to FIG. 36, the exemplary gatekeeper interface circuit 3206 is distributed between two vehicle controllers 3502, 3602, each of which is provided as an endpoint of the second network zone 3204. In certain embodiments (not shown), the vehicle controllers 3502, 3602 may be endpoints on separate network zones 3204. In examples where the gatekeeper interface circuits 3206 are distributed, each partial gatekeeper interface circuit 3206 may coordinate a portion of external communications, such as communications with a connected network zone, and / or may have the functionality to coordinate all external communications for a selected network zone, for example, to enable redundancy functionality in the event that communications with one of the partial gatekeeper interface circuits 3206 is lost or degraded. Referring to FIG. 37 , the example gatekeeper interface circuits 3206 are distributed between a first portion on the CND 108 and a second portion on the vehicle controller 3702. The example vehicle controller 3702 is an endpoint on the second network zone 3204. Similar to the example described in FIG. 36 , each partial gatekeeper interface circuit 3206 may coordinate a portion of external communications, such as communications with a connected network zone, and / or may have the functionality to coordinate all external communications for a selected network zone, for example, to enable redundancy functionality in the event that communications with one of the partial gatekeeper interface circuits 3206 is lost or degraded.

[0132] 38, the example policy 1606 includes an external data routing description 3802, where the configuration circuit 1604 configures the gatekeeper interface circuit in response to the external data routing description 3802. The example external data routing description 3802 includes one or more of a local DNS 3804, an external DNS 3806, and / or one or more external data routing paths 3808.

[0133] 39, exemplary local DNS 3804 includes several local address values ​​3904 for an endpoint 3902 in a network zone, each corresponding to at least one non-local address value 3906. The exemplary local DNS 3804 can be stored as a data structure as part of policy 1606 and can be included with local address table 2100 (see FIG. 21) or as a separate data structure. The exemplary local DNS 3804 can be utilized in network address translation (NAT) operations. The exemplary non-local address values ​​3906 include addresses utilized by external devices (e.g., IPv4 or IPv6 addresses directed toward the endpoint, where the IPv4 or IPv6 addresses may not match the local address values ​​3904 but may be values ​​from a previous configuration, values ​​typically used by an entity related to the external device, etc.). The exemplary non-local address values ​​3906 include standard values ​​for the endpoint (e.g., industry norms, convention values, values ​​utilized by a standards body such as SAE). Exemplary non-local address values ​​3906 include proprietary values ​​for the endpoint (e.g., values ​​typically used by a manufacturer, aftermarket entity, etc.). Exemplary non-local address values ​​3906 include previous local address values ​​for the endpoint (e.g., local address values ​​3904 used when the vehicle was manufactured, used for a previous configuration of the vehicle, used for a previous configuration of an associated vehicle such as a prior model year, etc.). Use of local DNS 3804 allows external devices to address a vehicle's endpoint 3902 using a distinct non-local address value 3906 without requiring knowledge of the network configuration, location, or other information regarding the vehicle's endpoint 3902. Furthermore, use of local DNS 3804 allows for changes to vehicle configuration, such as moving endpoints between network zones, aggregating endpoints, and / or any other changes to the vehicle's endpoints and / or the vehicle's network topology, while allowing external devices, applications, etc. to function properly unchanged.The use of a local DNS 3804 further enables the separation of vehicle knowledge from external applications, allowing more users to access vehicle information, decoupling external users from vehicle information and reducing development time and / or resource requirements for external applications. The use of a local DNS 3804 also provides amenability to gradual changes to the network topology of associated vehicles, such as the transition of an endpoint from a first network zone to a second network zone over several model years or other configuration iterations.

[0134] The example policy management circuit 1602 determines an address change for the endpoint 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 can detect movement of the endpoint between network zones (e.g., detect communication from the endpoint and / or receive an identifier from the endpoint at the new location and / or receive notification of a change from the endpoint, a service tool, etc.) and 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 a non-local address value 3906 for the endpoint and update the local DNS 3804 accordingly. For example, a change to policy 1606 from an external device may indicate that a change in non-local address value 3906 has occurred (e.g., “AmbTempSens” is now “Ambient Temperature Sensor”) and / or that a public list of non-local address values ​​3906 may be updated (e.g., a public list is a list provided on the memory of a cloud server, where policy management circuit 1602 may browse the list periodically and / or in response to an event for changes). The example policy management circuit 1602 determines authorization of external devices to allow changes to non-local address values ​​3906, e.g., allowing only authorized devices, entities, applications, etc. to adjust non-local address values ​​3906. Operation of policy management circuit 1602 to update non-local address values ​​3906 allows advantageous compliance with industry norms, manufacturer preferences, and / or systematic changes for several vehicles, without having to involve individual vehicles when changing proprietary or standard references to endpoints. It can be seen that the operation of updating non-local address values ​​3906 can improve memory utilization, as the size of the local DNS 3804 (and / or local address table 2100) can be reduced over time as related vehicle fleets synchronize on received address values, eliminating unnecessary association of non-local address values ​​3906 that are no longer in use.

[0135] 40 , an exemplary external data routing 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 locations for the local communication device 4002. In certain embodiments, the external DNS 3806 is operated to allow only authorized external access (e.g., if an external address value 4004 is provided). In certain embodiments, the external DNS 3806 is operated to prevent external access (e.g., if a listed external address 4004 cannot be accessed). In certain embodiments, both access permission and / or access type may be adjusted according to the local communication device 4002. For example, if an external address value 4004 is available, certain endpoints, flows, applications, vehicle functions, etc. may be limited to external access, while other endpoints, flows, applications, vehicle functions, etc. may be allowed external access unless the particular external address value 4004 is described in the list as preventing access. In certain embodiments, external DNS 3806 includes a non-local address value 3906, e.g., an IP address corresponding to external address value 4004, which can be a common name such as a website address listed in a description language. Utilizing non-local address value 3906 allows for fast external access without having to use an external DNS (e.g., from a cloud server and / or internet provider) and also allows for differential responses to local communication devices 4002 for a given external address value 4004 (e.g., allowing some local communication devices to access a given external web address and redirecting other local communication devices to a selected location). Illustrative and non-limiting example network access locations include one or more of internet access, a wide area network address, and / or an identifier for an external device and / or external application.

[0136] The exemplary external data routing path 3808 includes a network zone trajectory of a coordinated external communication corresponding to the local communication device. The exemplary network zone trajectory includes data configurations for the 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, the network zone trajectory enables the communication to be provided with a selected communication processing, including its payload and / or frame, and / or at a selected data rate. The selected data rate can be in accordance with a data rate request from the external device and / or in accordance with data rate restrictions for the external communication (e.g., to limit network utilization, transceiver utilization, data transmission for a data provider, etc.). The network zone trajectory can additionally or alternatively include, for example, a message passing through participating network zones before being transmitted outside the vehicle (e.g., a CAN message from a first network zone passing as an Ethernet message on a second network zone).

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

[0138] An example external data routing path includes the APN of the coordinated communication (e.g., specifying the data service provider for the communication). The example gatekeeper interface circuit 3206 adjusts the APN in response to vehicle, network zone, and / or transceiver operating conditions (e.g., if the communication supports operation of more than one application, vehicle function, and / or flow that adjusts the APN in response to vehicle operating conditions, allowing the coordinated communication to be attributed to a “primary consumer” of the communication). The example gatekeeper interface circuit 3206 aggregates coordinated communications from several local communication devices (e.g., if the communication supports more than one endpoint, application, vehicle function, and / or flow) and distributes the aggregated coordinated communications among more than one APN for the local communication devices (e.g., if the communication supports multiple consumers, the aggregate traffic can be distributed across multiple APNs, allowing a reduction in overall external communication by avoiding redundancy while still attributing all external communications). In certain embodiments, the operations of adjusting the APNs, aggregating the coordinated communications, and / or distributing the aggregated coordinated communications among the APNs are performed in response to an attribution statement in policy 1606.

[0139] The example policy management circuit 1602 determines changes to external data routing paths made by, for example, external devices 1618 and updates external data routing descriptions in response to the changes to the external data routing paths. The example policy management circuit 1602 determines the authorization of the external device to provide the changes to the external data routing paths and suppresses all or a portion of the changes to the external data routing paths in response to determining that the changes are unauthorized or not fully authorized. The example policy management circuit 1602 changes the external data routing paths in response to changes in local communication devices (e.g., changing the routing in response to an endpoint moving from one network zone to another). Exemplary, non-limiting changes to the local communication device include one or more of: moving an endpoint from one of the first network zone or the second network zone to the other of the first network zone or the second network zone; a flow change including a change in priority, subscription, or permission; an application change including a change in priority, subscription, or permission; and / or a change in the amount, configuration, or type of data communicated by the local communication device.

[0140] 41 , the example vehicle 102 includes a gatekeeper interface circuit 3206 that coordinates communications between a local communication device and an external device 1618. The example vehicle 102 includes a local communication device (transmit / receive local communication device 4104) targeted to transmit communications and / or receive communications from the external device 1618, and a gatekeeper interface circuit 3206 that provides a routed external communication 4108 in response to the transmitted or received communication and in response to a policy 1606 that further includes an external data routing path, permissions for the local communication device, and / or permissions for the external device 1618. In certain embodiments, the gatekeeper interface circuit 3206 selects an external communication portal 4102 for the routed external communication 4108, which selection includes selecting a device through which the routed external communication 4108 is to be communicated to the external device 1618. The example external communication portal 4102 includes one or more of a first transceiver 4110 and / or an APN selection 4122 therefor (e.g., allowing for selection of a data provider for communication 4108), a second transceiver 4112, an APN selection 4122, and / or a channel selection 4124 for the second transceiver 4112 (e.g., allowing for selection of a data provider and / or channel for the transceiver 4112), a second network zone connection 4114 (e.g., a port in an Ethernet network zone), a WiFi adapter 4116 (e.g., utilizing a WiFi connection when available), a Bluetooth adapter 4118 (e.g., utilizing a Bluetooth connection when available), and / or a first network zone connection 4120 (e.g., a port in a CAN network zone). The example shown in FIG. 41 shows a first transceiver 4110 and a second transceiver 4112 for ease of explanation to indicate whether the transceivers 4110, 4112 can have channels, but a given vehicle 102 can have any number of transceivers 4110, 4112, some of which can have through-channel operation, all of which can have through-channel operation, or none of which can have through-channel operation.41 shows a single connection to each network zone for purposes of illustration to show that any network zone may have a connection, however, a given network zone may have zero or more than one connection (such as an OBD port and a dedicated port). Without being limited to any other aspect of the present disclosure, the gatekeeper interface circuit 3206 may adjust routing operations based on available external communication portals 4102, vehicle operating conditions, network operating conditions, permissions of any entities in the communication chain, priority of any entities in the communication chain, service requirements of any entities associated with the vehicle, and / or data rate and / or data volume restrictions.

[0141] 42, the example policy 1606 includes an external data service description 4202, where the configuration circuit 1604 includes a gatekeeper interface circuit 3206 responsive to the external data service description 4202. The example 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 one or more of a priority value, a packet delay value (e.g., maximum, average, or other packet delay description), a packet loss rate value (e.g., maximum, average, longest gap time, or other packet loss description), a data rate value, a maximum dropout time value, an acknowledgement value (e.g., whether an acknowledgement for a communication corresponding to an associated local communication device is required, when available), a data buffering priority value (e.g., which may be utilized to determine a buffer size, buffer priority, and / or data expiration parameters for buffering target data), a data buffering size value (e.g., a data buffer size, buffering time, or other storage size related parameter), and / or a data life cycle description (e.g., a storage life, expiration time, and / or deletion priority for associated data). Without being limited to any other aspect of the present disclosure, the local communication device includes one or more of a network zone endpoint, an application, a flow, a vehicle function, and / or a vehicle controller. In certain embodiments, the gatekeeper interface circuit 3206 regulates the external communication using the QoS values ​​4206 corresponding to the local communication devices 4204 involved in the regulated communication. In certain embodiments, for example, when more than one local communication device 4204 is involved in the regulated communication (e.g., endpoints and flows), the gatekeeper interface circuit 3206 utilizes the QoS values ​​4206 associated with the highest priority of these local communication devices 4204 and / or applies a superset of applicable QoS values ​​4206 that satisfies the highest service value for all of the associated local communication devices 4204.

[0142] The example policy management circuit 1602 determines changes to the external data service description due to, for example, policy updates 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 example policy management circuit 1602 determines authorization of the external device to provide the changes to the external data service description, and suppresses all or a portion of the changes to the external data service description in response to determining that the changes are unauthorized or not fully authorized.

[0143] 40 , the example external data routing 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 in a network zone). The example gatekeeper interface circuit 3206 further accesses an off-vehicle external DNS (not shown) as needed by an endpoint communicating using the external address value, where the requested external address value is not found on the external DNS 3806. The example gatekeeper interface circuit 3206 further updates the external DNS 3806 in response to accessing the off-vehicle external DNS.

[0144] Referring again to FIG. 28 , the example vehicle 102 includes a first network zone 1612 and a second network zone 1614 of a different type. The example vehicle 102 includes a policy management circuit 1602 that interprets a policy 1606 that includes an external data routing description and an external data service description. The example vehicle 102 includes a configuration circuit 1604 that includes a gatekeeper interface circuit 2802 in response to the external data routing description and the external data service description. In this example, the gatekeeper interface circuit 2802 is interposed between the first network zone and at least one external communication portal 4102 (see, e.g., FIG. 41 ) that is selectively coupleable to an external device 1618, and is also interposed between the second network zone and the at least one external communication portal 4102. The gatekeeper interface circuit 2802 coordinates communications between endpoints of the network zones 1612, 1614 and the external communication portal 4102. An exemplary external data routing description includes several local communication devices, each corresponding to an external data routing path. The exemplary external data routing path includes a network zone trajectory of the coordinated communication. The exemplary network zone trajectory includes data constructs 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] An exemplary external data service description includes 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, where the gatekeeper interface circuit further distributes the coordinated communication between the first transceiver and the second transceiver in response to the external data service description. In another example, the external communication portal 4102 includes a first channel coupled to the transceiver and a second transceiver coupled to the transceiver, where the gatekeeper interface circuit distributes the coordinated communication between the first channel and the second channel in response to the external data service description.

[0146] Exemplary external communication portals 4102 include 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 diagnostics (OBD) port, a proprietary network port, an external network utilizing wireless communication with the vehicle (e.g., where communications with external devices are directed to and / or tunneled through the external network), an external network utilizing cellular communication with the vehicle, an Ethernet network utilizing Bluetooth communication with the vehicle (e.g., where communications with external devices are directed to 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] The exemplary gatekeeper interface circuit 2802 further distributes the coordinated communications among at least two external access points. In yet another example, the QoS values ​​include a priority value, a packet delay value, a packet loss rate value, a data rate value, a maximum dropout time value, an acknowledgement value, a data buffering priority value, a data buffering size value, and / or a service description such as a data life cycle description.

[0148] Certain aspects of the present disclosure are presented as steps for performing operations related to the present disclosure. Operations may be performed by, but are not limited to, any controller, circuit, device, component, sensor, actuator, logic circuit, or other aspect shown in the present disclosure. Steps are presented as embodiments, and operations may be omitted, combined, divided, and / or reordered in whole or in part. In certain embodiments, one or more operations of a first step may be combined with one or more operations of another step.

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

[0150] 44, an example procedure 4400 for coordinating communications between different types of networks on a vehicle is shown. The example procedure 4400 includes an operation 4402 for interpreting a policy including a network coordination description and an operation 4402 for receiving a policy communication from an external device. The procedure 4400 includes an operation 4404 for determining whether the policy is verified, e.g., whether the external device is authorized to update the policy, whether the system has the capability to enforce according to the policy, whether the policy violates any security standards, whether enforcement of the policy is deemed to be greater than data storage or communication limits, etc. In response to operation 4404 indicating "YES," the procedure 4400 includes an operation 4406 for storing and / or updating the policy and an operation 4404 for coordinating communications between a first network endpoint and a second network endpoint in response to the network coordination description. In response to operation 4404 indicating "NO," procedure 4400 optionally includes operation 4408 of providing a notification to the external device (and / or to other external devices) and operation 4304 of coordinating communications between the first network endpoint and the second network endpoint in response to the network coordination description (e.g., utilizing a previous policy, a default policy, etc.).

[0151] Referring to FIG. 45, an example procedure 4500 for coordinating communications between different types of networks on a vehicle is shown. The example procedure 4500 includes an operation 4302 for interpreting a policy including a network coordination description and an operation 4402 for receiving a policy communication from an external device. The procedure 4500 includes an operation 4404 for determining whether the policy is verified, e.g., whether the external device is authorized to update the policy, whether the system has the capability to enforce according to the policy, whether the policy violates any security standards, whether enforcement of the policy is deemed to be greater than data storage or communication limits, etc. In response to operation 4404 indicating YES, the procedure 4500 includes an operation 4502 for updating local configuration files of one or more of the network interface circuit, the CEG, the CES, and / or the 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 to other external devices). The procedure 4500 includes an operation 4504 of coordinating intra-network, inter-network, and / or external communications using the network interface circuitry, CEG, CES, and / or gateway interface circuitry (e.g., whether updated or not).

[0152] 46, an example procedure 4600 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 4600 includes an operation 4602 for interpreting a policy including an active diagnostic description, an operation 4604 for providing an endpoint with a diagnostic command value responsive to an active diagnostic condition, and an operation 4606 for commanding an actuator in response to the diagnostic command value.

[0153] 47, an example procedure 4700 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 4700 includes an operation 4702 for interpreting a policy including an active diagnostic description and a diagnostic execution condition, and an operation 4704 for determining whether the vehicle operating conditions are consistent with the diagnostic execution condition and / or the diagnostic command value (e.g., determined from the active diagnostic description). In response to operation 4704 determining YES, the procedure 4700 includes an operation 4604 for providing a diagnostic command value to an endpoint that is responsive to the active diagnostic condition, and an operation 4606 for commanding an actuator in response to the diagnostic command value.

[0154] 48, an example procedure 4800 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 4800 includes an operation 4602 for interpreting a policy including an active diagnostic description and an operation 4602 for performing diagnostic data collection operations responsive to the active diagnostic description. Additionally, the example procedure 4800 includes an operation 4604 for providing a diagnostic command value to an endpoint responsive to an active diagnostic condition, and an operation 4606 for commanding an actuator in response to the diagnostic command value.

[0155] 49, an example procedure 4802 for performing a diagnostic data collection operation is shown. The example procedure 4802 includes an operation 4902 for processing the collected data (e.g., processing payload and / or frame information of messages 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] 50, an example procedure 5000 for storing and / or communicating a diagnostic confirmation value is shown. The example procedure 5000 includes an operation 4602 for interpreting a policy including an active diagnostic description, an operation 4604 for providing a diagnostic command value to an endpoint responsive to an active diagnostic condition, and an operation 4606 for commanding an actuator responsive to the diagnostic command value. Further, the example procedure 5000 includes an operation 5002 for determining a diagnostic confirmation value and an operation 5004 for storing and / or communicating the diagnostic confirmation value to one or more external devices.

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

[0158] 52, an example procedure 5200 for coordinating communications between an external device and an endpoint of a network zone for a vehicle is shown. The example procedure 5200 includes an operation 5202 for interpreting a policy that includes an external communication value, and an operation 5204 for coordinating communications between the endpoint of the network zone and the external device in response to the external communication value.

[0159] 53, an example procedure 5204 for coordinating communications between an external device and an endpoint of a network zone for a vehicle is shown. The example procedure 5204 includes an operation 5302 for determining a type of external communication value. In response to operation 5302 determining the type as an active diagnostic description, procedure 5204 includes an operation 5304 for performing an active diagnostic operation. In response to operation 5302 determining the type as an active test description, procedure 5204 includes an operation 5306 for performing an active test operation. In response to operation 5302 determining the type as a vehicle control command, procedure 5204 includes an operation 5308 for performing a vehicle control operation. In response to operation 5302 determining the type as an active assistance operation, procedure 5204 includes an operation 5310 for performing an active assistance operation. Exemplary and non-limiting operations 5310 include one or more of a service technician contacting the vehicle operator, a service technician commanding a specified active diagnostic operation 5304, a service technician commanding a specified active test operation 5306, and / or a service technician commanding a specified vehicle control operation 5308. Exemplary procedure 5204 further includes an operation 5312 determining whether the external communication value indicates further operation, and returning to operation 5302 in response to operation 5312 indicating YES.

[0160] 54, an example procedure 5400 for coordinating communications between an external device for a vehicle and an endpoint in a network zone is shown. The example procedure 5400 includes an operation 5402 for interpreting a policy including an external communication value and a target device description. The example procedure 5400 further includes an operation 5404 for determining whether the target device description indicates a network address value for the target endpoint. In response to operation 5404 determining YES, the example procedure 5400 includes an operation 5408 for coordinating communications between the external device and the endpoint in the network zone in response to the external communication value. In response to operation 5404 determining NO, the example procedure 5400 includes an operation 5406 for providing or adjusting the network address value for the target endpoint and an operation 5408.

[0161] 55, an example procedure 5500 for transmitting visualization data is shown. The example 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] 56, an example procedure 5600 for transmitting visualization data is shown. The example procedure 5600 includes an operation 5502 for interpreting vehicle communication data, an operation 5602 for interpreting a data filtering value, and an operation 5604 for filtering at least a portion of the vehicle communication data based at least in part on the data filtering value. The example procedure 5600 further includes an operation 5504 for generating visualization data responsive to the vehicle communication data and an operation 5506 for transmitting the visualization data.

[0163] 57, an example methodology 5700 for coordinating inter-network, intra-network, and / or extra-vehicle communications is shown. The example methodology 5700 includes an operation 5702 of interpreting a policy including a network coordination description, an operation 5704 of configuring a network interface circuit in response to the network coordination description, and an operation 5706 of coordinating inter-network and / or intra-network communications using the configured network interface circuit. The example methodology 5700 further includes an operation 5708 of configuring a gatekeeper interface circuit in response to the network coordination description, and an operation 5710 of coordinating extra-vehicle communications using the configured gatekeeper interface circuit.

[0164] 58, an example procedure 5800 for coordinating inter-network, intra-network, and / or extra-vehicle communications is shown. In addition to the operations shown with respect to procedure 5700, example procedure 5800 includes operation 5802 of receiving a policy communication from an external device and operation 5804 of determining whether the policy is verified, e.g., whether the external device is authorized to update the policy, whether the system has the capability to enforce according to the policy, whether the policy violates any security standards, whether enforcement of the policy is deemed to be greater than data storage or communication limits, etc. In response to operation 5804 determining YES, the example procedure includes operation 5806 of storing and / or updating the policy, operation 5704 (which may further include configuring a gatekeeper interface circuit), and operation 5706 (and / or operation 5710). In response to operation 5804 determining NO, example procedure 5800 optionally includes operation 5807 of providing a notification to one or more external devices and proceeds to operation 5704.

[0165] 59, an example procedure 5900 for coordinating off-vehicle communications is shown. The example procedure 5900 includes an operation 5902 of interpreting a policy including a network usage authorization description and / or an external data access description, an operation 5904 of configuring a network interface circuit in response to the network usage authorization description, and an operation 5906 of coordinating communications within and / or between networks using the network interface circuit. The example 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 coordinating off-vehicle communications using the gatekeeper interface circuit.

[0166] 60, an example methodology 6000 for coordinating inter-network, intra-network, and / or extra-vehicle communications is shown. The example methodology 6000 includes an operation 6002 of determining authorization for the coordinated communications for a local communications 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 coordinating intra-network, inter-network, and / or extra-vehicle communications using the network interface circuit and / or the gatekeeper interface circuit.

[0167] 61, an example procedure 6100 for coordinating off-vehicle communications is shown. The example procedure 6100 includes an operation 6102 for interpreting a policy that includes an external data volume description, an operation 6104 for configuring a gatekeeper interface circuit in response to the external data volume description, and an operation 6106 for coordinating the off-vehicle communications using the gatekeeper interface circuit.

[0168] 62, an example procedure 6200 for coordinating off-vehicle communications is shown. The example procedure 6200 includes an operation 6202 of interpreting a policy that includes an external data routing description, an operation 6204 of configuring a gatekeeper interface circuit in response to the external data routing description, and an operation 6206 of coordinating the off-vehicle communications using the gatekeeper interface circuit.

[0169] 63, an example procedure 6300 for coordinating off-vehicle communications is shown. The example procedure 6300 includes an operation 6302 of interpreting a policy that includes external data routing paths corresponding to each of a number of local communication devices, an operation 6304 of configuring a gatekeeper interface circuit in response to the external data routing paths, and an operation 6306 of coordinating the off-vehicle communications using the gatekeeper interface circuit.

[0170] 64, an example procedure 6400 for coordinating off-vehicle communications is shown. The example procedure 6400 includes an operation 6402 of interpreting a policy that includes 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 coordinating the off-vehicle communications using the gatekeeper interface circuit.

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

[0172] 66, an example procedure 6600 for providing off-vehicle communications using a selected network zone trajectory is shown. The example procedure includes an operation 6602 for providing off-vehicle communications using a selected network zone trajectory and an operation 6604 for performing data configuration operations on the off-vehicle communications based on the network zone trajectory. The example 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] 67, an example procedure 6700 for providing out-of-vehicle communications using selected QoS values ​​is shown. The example procedure 6700 includes an operation 6702 for providing out-of-vehicle communications using selected QoS values ​​and an operation 6704 for distributing communications among external communication portals and / or APNs based on the QoS values.

[0174] Referring to FIG. 68, an embodiment of some embodiments of message transformation and / or message encapsulation is shown. The example set forth in FIG. 16 is illustrative and does not limit the present disclosure. In certain embodiments, the operations shown in FIG. 68 may be performed in whole or in part by a CEG, CES, transformation circuit, and / or CND, and in certain embodiments, may be coordinated by a CND. A first exemplary message transformation 6802 includes a message from a first network having a payload 6810 and other frame information 6808. The other frame information may include header, subsequent aspects, and / or termination bits, and may further be determined by the associated protocol, network type, source endpoint, destination endpoint, or other aspects known in the art. In certain embodiments, the payload 6810 may be message data, data values ​​represented by the message, or other information considered to be the content of a message. However, in certain embodiments, for certain operations, during certain operating conditions, and / or for certain endpoints, the payload 6810 may be any other aspect of the message. For example, network monitor operations can utilize timestamps, acknowledgment information, source and / or destination information, or other portions as the payload of a message. Exemplary message transformation 6802 includes separating the payload 6810 and packaging the payload into a new frame (or packet) 6812 within information configured for the target network. Additionally or alternatively, the new frame 6812 can include an adjustment identifier (e.g., source or destination), a timestamp, or other information that enables endpoints on heterogeneous networks to extract knowledge about each other. In certain embodiments, the payload 6810 can be processed to, for example, change the unit of use, change the bit depth (e.g., 2 bytes vs. 4 bytes), change the representation precision, or change the conversion, such as floating point or fixed point.

[0175] A second exemplary message transformation 6804 includes the original message 6808, 6810, fully encapsulated within a new frame 6812, e.g., to provide the original message provided by the original source to the target endpoint (e.g., allowing previously developed algorithms to operate as is without having to transform into a new message, enabling certain network monitoring operations that utilize the complete original message, and the like). In certain embodiments, either the original payload 6810 or the message frame 6808 can be processed, e.g., updating the source identifier, timestamp, etc., but providing otherwise equivalent or methodologically adjusted information in a new frame that is transformed to process the payloads as described above and extract the endpoints from each other.

[0176] The third example message transformation 6806 includes an original message 6808, 6810 with an adjusted payload 6814. The adjustment to the payload 6814 may include transforming the payload 6814 in any manner (e.g., value correction, virtually sensing or modeling values ​​based on the original payload 6810, upsampling or downsampling the payload 6810, etc.), and may additionally or alternatively include processing of the payload. While the third example message transformation 6806 illustrates an adjusted payload 6814, adjustments may additionally or alternatively be made to other portions of the message frame 6808. In the third example message, a new frame 6812 is applied for another communication.

[0177] Referring to FIG. 69, a schematic diagram of an operation for downsampling a message sequence 6902 is shown. In the example depicted in FIG. 69, the message sequence 6902 (e.g., a series of five communications in this example) is received, for example, at a network interface circuit of one of the network gateway devices. In the example depicted in FIG. 69, the downsampling operation is responsive to any downsampling operation described herein, for example, to match the data rate of a receiving endpoint, to provide data represented by the message 6902 at a planned rate, to manage bandwidth on the vehicle's network and / or for off-vehicle communications, to maintain buffer memory, or any other purpose involving any downsampling operation of the present disclosure. In the example depicted in FIG. 69, the downsampling device 6904, which may be a conversion circuit, a network interface circuit, a CND, a circuit connected to a CND, a circuit coordinated by a CND, etc., generates a converted message sequence 6908 (e.g., processed as shown in FIG. 16 and related disclosures and / or processed in accordance with any other message conversion and / or message processing operation described herein). The example set forth in FIG. 69 depicts a transformed message sequence 6908 for clarity of explanation. However, the transformed message sequence 6908 may not all exist at once; for example, messages may be removed from a cache, deleted, expired, etc., as they are transformed and transmitted. The message sequence 6908 is shown to illustrate aspects of the present disclosure. Additionally or alternatively, for example, to reduce utilization of processing resources, the transformation of the message 6908 may be performed after a downsampling operation is performed. For example, portions of the message may be eliminated as part of the downsampling before the transformation operation (e.g., partial frame or metadata exchange, encapsulation, payload and / or partial frame processing, etc.) is performed.69 , the downsampled message sequence 6906 may be provided and communicated to, for example, a different network gateway device, a different vehicle network that was the source of the first message sequence 6902, an external device (e.g., a service tool, a cloud server, the driver's mobile device, etc.), and / or stored on a memory storage device on the vehicle (e.g., as part of stored vehicle data for a later data collection operation, etc.). In this example, the five messages of the original sequence 6902 are downsampled to three messages of the downsampled sequence 6906. The downsampling operation may include transforming selected messages from the original sequence 6902, for example, modifying the original 10 ms data stream 6902 into a downsampled 20 ms data stream 6906 by utilizing every other data message. The downsampling operation may additionally or alternatively include interpolating data messages between the original values. For example, if the original data stream 6902 is a 40 ms data stream and the downsampled data stream 6906 is a 100 ms data stream, downsampling may involve either taking the message closest in time or performing an interpolation operation (e.g., applying a linear fit, spline fit, polynomial fit, or other interpolation operation to the interpolated data points) and using that as the downsampled message 6906.

[0178] As used herein, an interpolated data point or interpolated data value refers to a data value in a downsampled message 6906 that is not time-aligned with the corresponding original data message 6902. As used herein, a non-interpolated data point or non-interpolated data value refers to a data value in a downsampled message 6906 that is time-aligned or synchronized with the corresponding original data message 6902. It will be understood that the messages in the original data message 6902 and the messages in the downsampled message 6906 may additionally or alternatively have a phase difference, and thus, in certain embodiments, any or all of the original data messages 6902 may be non-interpolated messages. In certain embodiments, even if a phase difference exists between the original data message 6902 and the downsampled message 6906, certain of the original data messages 6902 can be treated as non-interpolated or synchronized data messages, for example, when any phase difference can be ignored for purposes of providing a baseline downsampled message 6906 that follows the trajectory characteristics (e.g., in the time domain) of the stream of original data messages 6902 and / or for purposes of a device or operation utilizing the downsampled message 6906 (e.g., when such device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference).

[0179] In yet another example, synchronized data values ​​(e.g., every fifth data value when going from 40 ms to 100 ms) can be used directly, or a fitting function can be used (e.g., to provide a smooth, filtered, or otherwise processed stream of data values). In certain embodiments, it may be desirable to use actual data values ​​provided from the first data stream 6902 as the downsampled data values ​​6906 when either minor transient behavior from various time steps is not relevant to how the downsampled data values ​​6906 are used, or when timestamp data is further communicated with the messages so that differential time steps between messages can be taken into account in processing that utilizes the downsampled data 6906. In certain embodiments, it may be desirable to use smoothed data values ​​that mimic the time response behavior of the underlying data, and these data values ​​can be controlled using interpolated data with respect to the interpolated data values ​​(e.g., processing that is responsive to the rate of change of the downsampled data 6906, e.g., threshold testing on the rate of change). In certain embodiments, for example, when downstream processing is particularly sensitive to time variations in the data message 6902 (e.g., the derivative portion of a PID controller), it may be desirable to ensure that all downsampled data messages 6906 are generated from the same processing, and that interpolation operations (or smoothing, filtering, or moving averages) can be performed to generate both interpolated and non-interpolated data values ​​6906. In certain embodiments, the downsampled data message 6906 may 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., to allow for more than one use of the downsampled data message 6906, diagnostic operations for the device providing the original data message 6902, and / or any other purpose).

[0180] It can be seen that the downsampling operations described in Figure 69 enable communication between devices and / or procedures having different data rate capabilities, expectations, and / or utilization of the downsampled data. Furthermore, the downsampling operations described in Figure 69 enable reduced network utilization while providing sufficient data to perform the intended function of the devices and / or procedures with an expected time-domain response (e.g., differential behavior, integral behavior, step-change response, etc.) for proper functioning of the devices and procedures, which may depend on the time dynamics of the communicated data values. It can be seen that the downsampling operations described in Figure 69 enable the gradual update of communication behaviors (e.g., components, devices, procedures, and / or operations that each communicatively interact with the network and / or other components, devices, procedures, and / or operations) with newer communication behaviors (e.g., higher data rate capabilities and / or data rate expectations, and / or distinctly different network protocols, characteristics, message types, etc.) of mobile applications having a combination of mixed network configurations and / or legacy communication behaviors (e.g., having lower data rate capabilities and / or data rate expectations, and / or distinctly different network protocols, characteristics, message types, etc.).

[0181] Referring to FIG. 70, a schematic diagram of an operation for upsampling a message sequence 7002 is shown. In the example depicted in FIG. 70, a message sequence 7006 (e.g., a series of three communications in this example) is received, for example, at a network interface circuit of one of the network gateway devices. In the example depicted in FIG. 70, the upsampling operation is responsive to any upsampling operation described herein, for example, to match the data rate of a receiving endpoint, to provide data represented by message 7006 at a planned rate, to manage bandwidth on the vehicle's network and / or for off-vehicle communications, to maintain buffer memory, or any other purpose involving any upsampling operation of the present disclosure. In the example depicted in FIG. 70, upsampling device 7004, which may be a conversion circuit, a network interface circuit, a CND, a circuit connected to a CND, a circuit coordinated by a CND, etc., generates a converted message sequence 7008 (e.g., processed as shown in FIG. 16 and related disclosures and / or processed according to any other message conversion and / or message processing operation described herein). 70 depicts a transformed message sequence 7008 for clarity of explanation. However, the transformed message sequence 7008 may not all exist at once; for example, messages may be removed from a cache, deleted, expired, etc., as they are transformed and transmitted. The message sequence 7008 is shown to illustrate aspects of the present disclosure. Additionally or alternatively, the transformation of the message 7008 may be performed after the upsampling operation is performed, for example, to reduce utilization of processing resources.

[0182] For example, some of the messages may be removed or adjusted as part of the upsampling before a transformation operation (e.g., partial frame or metadata exchange, encapsulation, payload and / or partial frame processing, etc.) is performed. In the example depicted in FIG. 70 , the upsampled message sequence 7002 may be provided and communicated to, for example, a different network gateway device, a different vehicle network that was the source of the first message sequence 7006, an external device (e.g., a service tool, a cloud server, the driver's mobile device, etc.), and / or stored on a memory storage device on the vehicle (e.g., as part of stored vehicle data for a later data collection operation, etc.). In this example, three messages in the original sequence 7006 are upsampled to five messages in the upsampled sequence 7002. The upsampling operation may include transforming selected messages from the original sequence 7006, e.g., modifying the original 50 ms data stream 7006 into an upsampled 20 ms data stream 7002 by inserting one or more generated messages 7010. The upsampling operation may additionally or alternatively include interpolation and / or extrapolation of data messages between original values. For example, if 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 may involve either taking the message closest in time or performing an interpolation and / or extrapolation operation (e.g., applying a linear fit, a spline fit, a polynomial fit, a moving average, and / or a low pass filter sequence between available data points and / or between an available data point and an expected next data point) and utilizing that as the upsampled message 7002.

[0183] As used herein, an interpolated data point or interpolated data value refers to a data value in upsampled message 7002 that is not time-aligned with the corresponding original data message 7006. As used herein, a non-interpolated data point or non-interpolated data value refers to a data value in upsampled message 7002 that is time-aligned or synchronized with the corresponding original data message 7006. It will be understood that the messages in original data message 7006 and upsampled message 7002 may additionally or alternatively have a phase difference, and thus, in certain embodiments, any or all of the original data messages 7006 may be non-interpolated messages. In certain embodiments, even if a phase difference exists between the original data message 7006 and the upsampled message 7002, certain messages of the original data message 7006 can be treated as non-interpolated or synchronized data messages, for example, when any phase difference can be ignored for purposes of providing a baseline upsampled message 7002 that follows the trajectory characteristics (e.g., in the time domain) of the stream of original data messages 7006 and / or for the purposes of a device or operation utilizing the upsampled message 7002 (e.g., when such device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference).

[0184] In yet another example, synchronized data values ​​(e.g., every other data value when going from 50 ms to 20 ms, e.g., a 0 ms phase value and a 100 ms phase value) can be used directly, or a fitting function can be used (e.g., to provide a smooth filtered or otherwise processed stream of data values). In certain embodiments, it may be desirable to use actual data values ​​provided from the first data stream 7006 as the upsampled data values ​​7002, for example, if minor transient behavior from various time steps is not relevant to how the upsampled data values ​​7002 are used, or if timestamp data is further communicated with the messages so that the processing utilizing the downsampled data 7002 can take into account differential time steps between messages. 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 one of the values ​​of the first data stream 7006 (e.g., holding the communicated value until the next value is available)).

[0185] In certain embodiments, it may be desirable to utilize smoothed data values ​​that mimic the time response behavior of the underlying data (e.g., original message 7006), and these data values ​​may be controlled using interpolated / extrapolated data with respect to interpolated data values ​​(e.g., processing responsive to the rate of change of the upsampled data 7002, e.g., threshold checks on the rate of change) and / or with respect to non-interpolated data values. In certain embodiments, for example, when downstream processing is particularly sensitive to time changes in the data message 7006 (e.g., the derivative portion of a PID controller), it may be desirable to ensure that all upsampled data messages 7002 are generated from the same processing, and that interpolation / extrapolation operations (and / or smoothing, filtering, and / or moving averages) can be performed to generate both interpolated and non-interpolated upsampled data values ​​7002. In certain embodiments, the non-interpolated upsampled data values ​​7002 are utilized directly (e.g., to provide a stream of upsampled data 7002 that has, as far as possible, the actual content of the data message 7006), and the interpolated upsampled data values ​​are processed as described herein. In certain embodiments, all of the original message 7006 is provided in the 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 still support the upsampling rate). In certain embodiments, the upsampled data message 7002 may further include metadata or other embedded information indicating whether it corresponds directly to the original data message 7006 or is a processed message (e.g., to allow for more than one use of the upsampled data message 7002, diagnostic operation for 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 a predicted value between non-interpolated data values, which can be performed based on a virtual sensor (e.g., a model of values ​​utilizing other information available in the system) and / or an extrapolation fitting operation. In certain embodiments, determining the interpolated upsampled data value 7002 additionally or alternatively includes providing a predicted value and / or an interpolated / extrapolated value that provides a representation of a rate of change for the upsampled data value 7002 determined according to the original data value 7006 and / or adjusted according to characteristics of a device, component, operation, and / or procedure utilizing the upsampled data value 7002. For example, the upsampling operation can include performing a prediction operation and / or interpolation / extrapolation to determine a rate of change for the value and providing a final interpolated upsampled data value 7002 that provides an expected rate of change for the upsampled data value 7002. In certain embodiments, the operations providing the upsampled data values ​​7002 include operations that determine a rate of change (or derivative) determination operation within the device that utilizes the upsampled data values ​​7002, and adjust the rate of change of the upsampled data values ​​7002 in response to the rate of change parameter determination within the device, for example, interpreting the data with respect to the time step utilized in the derivative operation (e.g., ΔT / 5 ms or 5 milliseconds per temperature change) and / or time constant (e.g., the time constant of a low pass filter, the time constant inherent in a moving average calculation, etc.), where the upsampled data values ​​7002 are adjusted to provide a desired response in the rate of change calculation to be performed thereon. For example, if the upsampling operation has a significant time step difference between the original data values ​​7006 and the upsampled data values ​​7002 (e.g., 50 ms vs. 5 ms), operations such as linear interpolation / extrapolation of data values ​​performed by a device that utilizes the upsampled data values ​​7002, which may be configured to process true 5 ms data, may provide significant distortion to the output of a low pass filter.Thus, in this example, the act of upsampling the original data values ​​7006 may include adjusting the original data values ​​7006 according to the expected response of a 5ms device determining the values, thereby providing a significant difference in the trajectory of the upsampled data values ​​7002 between non-interpolated data points compared to simple linear extrapolation, moving averages, etc. The act of adjusting the rate of change representation for the upsampled data 7002 and / or downsampled data 6906 may be performed or omitted.

[0187] In certain embodiments, configuration information regarding the upsampling and / or downsampling operations, such as whether non-interpolated original data values ​​6902, 7006 are used directly, metadata stored with the upsampled and / or downsampled data 7002, 6906, processing operations performed on interpolated and / or non-interpolated data values, whether all original data values ​​6902, 7006 are communicated, operations providing rate-of-change representations of the upsampled and / or downsampled data 7002, 6906, and / or rate-of-change determining parameters (e.g., filter constants, differentiation operations, etc.) within devices utilizing the upsampled and / or downsampled data 7002, 6906, can be provided in memory storage locations accessible to the controller and / or circuitry that performs the upsampling and / or downsampling operations. Any such configuration information can be provided in whole or in part at the time of design, for example, when including the mobile application and its devices in communication with 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 and / or downsampling operations may be provided as part of a policy, as configuration instructions, and / or as configuration tables that may be made accessible to CND 108, which coordinates communications between devices on separate networks of mobile applications. In certain embodiments, one or more aspects of the configuration information regarding the upsampling and / or downsampling operations that include configuration instructions and / or configuration tables as part of a policy may include default values ​​that may be adjusted and / or updated.

[0188] Referring to FIG. 71 , an exemplary system for controlling inter-network, intra-network, and / or external-vehicle communications utilizing a planned policy scheme is shown. The exemplary system includes a vehicle 102 having a policy management circuit 7106 that interprets a policy 7108 that includes at least one network (a first network zone 7102 and a second network zone 7104 in the example depicted in FIG. 71 ), external data communication parameters such as external data routing descriptions and / or external data service descriptions. The exemplary system includes a configuration circuit 7110 that includes a gatekeeper interface circuit 7120 responsive to the policy 7108 and coordinates communications between endpoints in 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 may include any one or more of the external communication portals 7116 depicted herein, including at least any one or more of the examples depicted with respect to FIG. 41 and related description. The example depicted in FIG. 71 shows a gatekeeper interface circuit 7120 coupled to an external communication portal 7116. However, the gatekeeper interface circuit 7120 can coordinate communications in any manner, such as by further configuring the network interface circuits 7112, 7114 to provide selected communications and / or enable communications having selected processing, encapsulation, data file formatting, communication protocols, authorization, and / or any other coordination description described throughout this disclosure. The example depicted in FIG. 71 shows the policy management circuit 7106, configuration circuit 7110, and network interface circuits 7112, 7114 located on the CND 108. As described elsewhere herein, the CND 108 can provide instructions to or coordinate other components, and the depicted components (and / or the CND 108) can be distributed elsewhere on the vehicle 102, in whole or in part, separate from the CND 108.

[0189] 72, the example policy 7108 includes one or more of a secondary policy value 7206, a primary policy value 7204, and / or a default policy value 7202. The example configuration circuit 7110 includes a gatekeeper interface circuit 7120 that is responsive to the default policy value 7202 if the primary policy value 7204 and / or the secondary policy value 7206 are not present (and / or are not valid), responsive to the primary policy value 7204 if the secondary policy value 7206 is not present (and / or is not valid), and uses the secondary policy value 7206 if it is present (and valid). The example configuration circuit 7110 applies policies, if present (and / or determined to be valid), in the order described (e.g., uses secondary policy value 7206, if present, and ignores any remaining policy values ​​7204, 7202). The example configuration circuit 7110 applies more than one policy value if there is a match and / or consistency between the policy values ​​(e.g., applies secondary policy value 7206 and also applies portions of primary policy value 7204 that do not conflict with secondary policy value 7206). In the example described in FIG. 72, default policy value 7202 may be a permanent storage policy (thus, for example, a policy stored with executable instructions stored on a computer-readable medium that includes instructions for at least a portion of the operation of CND 108 and / or associated circuitry). In certain embodiments, the primary policy values ​​7204 and / or secondary policy values ​​7206 are easily updated in real time and are stored, for example, as data files (e.g., provided according to a certain naming designation in a selected memory location, a selected OS logical location, and / or stored with selected header information, metadata, etc. that identifies each policy value as a primary policy value 7204 or a secondary policy value 7206), including policy values ​​stored as part of a calibration set, a trim set, etc.

[0190] Exemplary primary policies 7204 are tool-supplied policies, such as manufacturer tools, OEM tools, service tools, etc. In certain embodiments, secondary policy values ​​7206 are downloaded policy values, e.g., policy values ​​received from an external device through an external communication portal, and policy values ​​from a web-based tool, cloud application, etc. The listed examples are non-limiting, and any of the policy values ​​can be received from any external communication portal. Exemplary implementations include default policy values ​​7202 that are provided at the time of installation of the CND 108 or related control components (e.g., the initial image file applied to the controller, including executable portions of the CND 108, policy management circuit 7106, etc.) and are generally not updated, except as part of, for example, an overall instruction set date (e.g., updating executable instructions provided for the CND 108 and / or portions thereof). Exemplary implementations include primary policy values ​​7204 that are provided at the time of manufacture, assembly, or other initial pre-service servicing or assembly operations on the vehicle. An example implementation includes secondary policy values ​​7206 provided as downloaded operations and / or provided during service operations, trim operations, and / or application configuration operations (e.g., by an OEM, body manufacturer, or the like). The use of deliberate policy values ​​7202, 7204, 7206 provides a minimally functional (and / or lowest risk) policy implementation, giving the vehicle's devices sufficient functionality to communicate externally and download and / or act upon replacement policies, such as primary policy values ​​7204 and / or secondary policy values ​​7206.The use of programmatic policy values ​​provides various stakeholders in a manufacturing, remanufacturing, reconfiguration, service repair, sale or transfer, change of mission, or other vehicle-related operation with assurance that policy requirements (e.g., permission for local communication devices to communicate within and across a network, to store data, and / or to communicate with external devices) are satisfied, while also allowing for ease of policy update, enforcement, and interface for third parties, owner / operators, fleet owners, and the like, to adjust policy values ​​and resulting communication coordination operations. The use of programmatic policy values ​​7202, 7204, 7206 allows for ease of policy update, verification, and enforcement. Utilization of the programmed policy values ​​7202, 7204, 7206 allows for policy reconfiguration and / or communication adjustment responses to be adjusted in real time with only a small impact to the vehicle's mission (e.g., without a controller reset operation, adjustment of the main executable instruction file, etc.), e.g., adjusting policies in response to adjustment characteristics such as geography (e.g., vehicle location), jurisdiction (e.g., location within the vehicle's jurisdiction), and / or operation when direct control of the vehicle may be unavailable (e.g., after an accident, towing event, sale, or other transfer, etc.). In certain embodiments, the programmed policy values ​​7202, 7204, 7206 can be applied by one of several devices at different times, e.g., default policy values ​​7202 applied by a first device, primary policy values ​​7204 applied by a second device, and secondary policy values ​​7206 applied by a third device. In certain embodiments, a given external device may apply more than one of the scheduled policy values ​​7202, 7204, 7206 and / or apply a later version of one of the scheduled policy values ​​7202, 7204, 7206 at a later time compared to the application of an earlier version. In certain embodiments, more than one version of a given policy value (e.g., secondary policy value 7206) may exist, with a selection of these versions being utilized in response to operating conditions (e.g., vehicle operating conditions, geography, jurisdiction, abnormal conditions, and / or fault code conditions, etc.).In certain embodiments, a given policy value 7206 may include more than one version of a policy aspect, for example, to provide various data collection operations for a given local communication device, controller, flow, application, endpoint, etc., and a version of the policy aspect is selected in response to operating conditions.

[0191] 73, exemplary policy 7108 includes a local DNS 7302 (e.g., including local addresses to be utilized by endpoints on any network zone, and / or including non-local addresses to be utilized by external devices, applications, etc., and / or including external addresses to be utilized by endpoints on any network zone). Exemplary policy 7108 further includes an authorization description 7304, which may include any type of authorization mentioned throughout this disclosure, including network usage authorization, data access description, subscription authorization, external access authorization, policy change and / or update authorization, etc. The authorization description 7304 may describe a flow, a local communication device, an external device, an endpoint, a network zone, an application, a set of services, a vehicle controller, a source address, a destination address, any other coordinated component, and / or an entity, user, and / or user role associated with any of these. The example policy 7108 includes a firewall configuration description 7306, which may include, for example, a description utilized by a firewall-enforcing device (e.g., a gateway interface circuit, a CND, and / or an external communication portal) to determine how to perform firewall operations.In certain embodiments, the firewall configuration description 7306 includes a default behavior description (e.g., handling of unknown or unspecified communications, e.g., blocking communications from unknown external devices or addresses), a data access description (e.g., system components that have permission to contact certain addresses, certain communication types such as external devices responding to requests by components, and / or access planned according to permissions or authorizations according to components), and / or a data blocking description (e.g., system components that do not have permission to access external devices or addresses, selected external devices or addresses, external devices or addresses that are specifically blocked, and / or certain communication types that are specifically blocked, e.g., incoming communications requesting access to certain data types, flows, applications, vehicle functions, vehicle controllers, endpoints, etc.).

[0192] 74, exemplary policy 7108 includes local DNS 7302 and external data volume description 7402. External data volume description 7402 may include at least aspects of any of the external data volume descriptions referred to throughout this disclosure, including data caps, data limits (e.g., bandwidth, utilization, data volume per throttling event, e.g., per unit time, per trip, etc.) for the throttling component, data caps or data limits for APNs and / or data service providers for particular external communication portals, etc. Exemplary policy 7108 includes external data service description 7406, which may include aspects of any of the external data service descriptions referred to throughout this disclosure (e.g., see FIGS. 42, 64, and 67 and related discussions).

[0193] 75, an example procedure 7500 for coordinating external communications is shown. The example procedure 7500 includes an operation 7502 of utilizing a secondary policy value, if present, and a primary policy value, if present, and a default policy value (e.g., if neither the secondary policy value nor the primary policy value is present), in that order. The example procedure 7500 further includes an operation 7504 of interpreting a policy according to the usage policy values, which include an external data routing description and an external data service description. The example procedure includes an operation 7506 of configuring a gatekeeper interface circuit in response to the policy, and an operation 7508 of operating the gatekeeper interface circuit to coordinate communications between the vehicle's network and the vehicle's external communication portal, thereby coordinating communications between endpoints in the vehicle's network zone and external devices.

[0194] 76, an example procedure 7600 for coordinating external communications is shown. The example procedure 7600 includes an operation 7602 of interpreting a policy including an external data volume description and an operation 7604 of determining destination and / or source IP addresses (or other addresses), destination and / or source ports, and / or destination and / or source identifiers for the coordinated communication and / or according to the addresses, ports, and / or identifiers provided in the policy. The example procedure 7600 includes an operation 7606 of configuring a gatekeeper interface circuit in response to the policy and the determined addresses, ports, and / or identifiers. The example procedure 7600 includes an operation 7608 of operating the gatekeeper interface circuit to coordinate communications between the vehicle'...

Claims

1. a vehicle having at least one network zone; a local domain name server (DNS), a policy management circuit configured to interpret policies including authorization descriptions and firewall configuration descriptions; a configuration circuit configured to configure a gatekeeper interface circuit in response to said policy; a gatekeeper interface circuit interposed between the at least one network zone and an external communication portal selectively coupleable to an external device, the gatekeeper interface circuit further configured to coordinate communications between endpoints of the at least one network zone and the external communication portal; Including, the system.

2. The system of claim 1 , wherein the local DNS further comprises a local address value for each of the endpoints of the at least one network zone.

3. The system of claim 2 , wherein the local DNS further includes a non-local address value for each of the endpoints of the at least one network zone.

4. The system of claim 3 , wherein the policy further comprises an external data volume description.

5. The system of claim 4 , wherein the policy further comprises an external data service description.

6. The system of claim 5 , wherein the authorization statements further include an external data access statement.

7. The system of claim 6 , wherein the external data access description further includes an external communication permission value for each of the endpoints of the at least one network zone.

8. The system of claim 7 , wherein the authorization statements further include a policy change authorization statement.

9. The system of 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.

10. The external data quantity description is the amount of communication data corresponding to the selected period; an amount of communication data corresponding to a selected vehicle operating condition; the amount of communication data corresponding to the data providers associated with the application; bandwidth allocation for said external communication portal; the bandwidth volume of said external communication portal; the bandwidth allocation of the channels of said external communication portal; or the bandwidth volume of the channel of said external communication portal; and at least one data restriction selected from the restrictions consisting of: The system of claim 4.

11. a vehicle having at least one network zone; a local domain name server (DNS), a policy management circuit configured to interpret policies including an external data volume description and an external data service description; a configuration circuit configured to configure a gatekeeper interface circuit in response to said policy; a gatekeeper interface circuit interposed between the at least one network zone and an external communication portal selectively coupleable to an external device, the gatekeeper interface circuit further configured to coordinate communications between endpoints of the at least one network zone and the external communication portal; Including, the system.

12. The external data quantity description is the amount of communication data corresponding to the selected period; an amount of communication data corresponding to a selected vehicle operating condition; the amount of communication data corresponding to the data providers associated with the application; bandwidth allocation for said external communication portal; the bandwidth volume of said external communication portal; the bandwidth allocation of the channels of said external communication portal; or the bandwidth volume of the channel of said external communication portal; and at least one data restriction selected from the restrictions consisting of: The system of claim 11.

13. The external data service description an association between each of the endpoints of the at least one network zone and at least one of a plurality of local communication devices; and an association between each of the plurality of local communication devices and a corresponding Quality of Service (QoS) value; Including, The system of claim 12.

14. 14. The system of claim 13, wherein each QoS value comprises at least one service description selected from the service descriptions consisting of a priority value, a packet delay value, a packet loss rate value, a data rate value, a maximum dropout time value, an acknowledgement value, a data buffering priority value, a data buffering size value, or a data life cycle description.

15. The system of claim 14 , wherein the policy further comprises a firewall configuration description.

16. The system of claim 15 , wherein the firewall configuration description includes at least one of a default behavior description, a data access description, or a data blocking description.

17. The system of claim 15 , wherein the policy further comprises an authorization statement.

18. The system of claim 17 , wherein the authorization statement further comprises an external data access statement.

19. 20. The system of claim 18, wherein the external data access description further includes an external communication permission value for each of the endpoints of the at least one network zone.

20. The system of claim 17 , wherein the authorization statements further include a policy change authorization statement.

21. 20. The system of claim 17, wherein the local DNS further comprises a local address value for each of the endpoints of the at least one network zone.

22. 22. The system of claim 21, wherein the local DNS further includes a non-local address value for each of the endpoints of the at least one network zone.

23. the at least one network zone includes a first legacy network zone and a second advanced network zone; the policy further includes an external communication value; the gatekeeper interface circuitry is further configured to coordinate communications between the external device and an endpoint of at least one of the first legacy network zone or the second intelligent network zone in response to the external communications value. The system of claim 11 further comprising:

24. 1. A system comprising: a vehicle having a first network zone and a second network zone of a different type than the first network zone; a centralized network device (CND) interposed between the first network zone and the second network zone; Including, The CND is a policy management circuit configured to interpret a policy including a network adjustment description; a configuration circuit configured to configure a first network interface circuit in response to the network adjustment description, and to configure a gatekeeper interface circuit in response to the network adjustment description; Including, the first network interface circuit is structured to coordinate communications between an endpoint of the first network zone and an endpoint of the second network zone; the gatekeeper interface circuit is configured to coordinate communications between an endpoint in the first network zone and at least one of an external communications portal or an external device; system.

25. the network coordination description includes a data request permission description including a data value associated with a data requestor; at least a portion of the data requestors include an endpoint of at least one of the first network zone or the second network zone; the first network interface circuit is further configured to adjust communications in response to the data request permission description; 25. The system of claim 24.

26. the configuration circuitry is further configured to configure a second network interface circuit in response to the network adjustment description; the second network interface circuit is configured to coordinate communications of the endpoints of the second network zone; 26. The system of claim 25, further comprising:

27. 27. The system of claim 26, wherein the gatekeeper interface circuitry is further configured to coordinate communications between an endpoint in the second network zone and the at least one of the external communication portal or the external device.

28. 30. The system of claim 27, wherein at least one of the external communication portal or the external device is communicatively coupled to one of the first network zone or the second network zone.

29. the external communication portal includes a transceiver of the vehicle; the transceiver is communicatively coupled to the second network zone; 28. The system of claim 27.

30. 30. The system of claim 27, wherein the external device includes an application including at least one of a cloud server-based application, a web-based application, or a mobile device application.

31. the data request permission description further includes a data access permission associated with at least one of the external communication portal or the external device, a flow associated with one of the endpoints of the first network zone and / or the second network zone, a flow associated with the external device, a set of services associated with one of the endpoints of the first network zone and / or the second network zone, a set of services associated with the external device, a vehicle function associated with one of the endpoints of the first network zone and / or the second network zone, or a vehicle function associated with the external device; the gatekeeper interface circuitry is further configured to coordinate communications with the at least one of the external communication portal or the external device in response to the data access grant.

28. The system of claim 27, further comprising:

32. the data request permission description further includes an external communication bandwidth limit; the gatekeeper interface circuitry is further configured to regulate communications with the at least one of the external communication portal or the external device in response to the external communication bandwidth limitation.

28. The system of claim 27, further comprising:

33. The gatekeeper interface circuit comprises: a flow associated with one of the coordinated communications; a data type associated with one of the coordinated communications; a data service provider associated with one of the coordinated communications; a vehicle function associated with one of the coordinated communications; a set of services associated with one of the coordinated communications; or a connection type of said external communication portal; and further configured to coordinate communications with the at least one of the external communication portal or the external device in response to at least one of:

33. The system of claim 32.

34. interpreting a policy including a network usage authorization statement; configuring a gatekeeper interface circuit in response to said network authorization description; Using the gatekeeper interface circuit, an end point of at least one network zone for the vehicle; at least one of an external communication portal or an external device; coordinating communication between A method comprising:

35. The network usage permission description further includes an external data access description; The method is further configuring the gatekeeper interface circuit in response to the external data access description; using the gatekeeper interface circuit to coordinate communications with at least one of the external communication portal or the external device in response to the external data access description; Further comprising:

35. The method of claim 34.

36. 36. The method of claim 35, wherein the external data access description includes permissions associated with the external device.

37. the external data access description includes permissions associated with the vehicle's flow; and coordinating the communication includes coordinating the communication based on a flow association of a communicating one of the endpoints of the at least one network zone.

36. The method of claim 35.

38. the external data access description includes permissions associated with the application; coordinating the communication includes coordinating the communication based on an application association of a communication device including one of the external device or an endpoint of the at least one network zone.

36. The method of claim 35.

39. the external data access description includes permissions associated with a particular zone of the at least one network zone for the vehicle; The stage of coordinating communications is Source zones of coordinated communication, destination zones for coordinated communications; Authorization to utilize the external communication portal of the particular one of the at least one network zone; or authorization to communicate with the external device in the particular one of the at least one network zone; adjusting communications based on at least one of 36. The method of claim 35.

40. 1. A system comprising: a vehicle having a first network zone and a second network zone of a different type than the first network zone; a gatekeeper interface circuit interposed between the first network zone and a transceiver selectively coupleable to an external device, and further interposed between the second network zone and the transceiver; Including, the gatekeeper interface circuit is configured to coordinate communications between an endpoint in the first network zone and the transceiver, and to coordinate communications between an endpoint in the second network zone and the transceiver; system.

41. a policy management circuit structured to interpret a policy including an external data access description; a configuration circuit structured to configure the gatekeeper interface circuit in response to the external data access description; 41. The system of claim 40, further comprising:

42. 42. The system of claim 41, wherein the external data access description includes authorization to send or receive communications to or from the external device terminating in the first network zone or the second network zone.

43. 42. The system of claim 41, wherein the external data access description includes authorizations for applications associated with coordinated communications.

44. 44. The system of claim 43, wherein the gatekeeper interface circuitry is further configured to coordinate communications based on associations of communicating devices including one of the external device, an endpoint in the first network zone, or an endpoint in the second network zone with the application.

45. 42. The system of claim 41, wherein the external data access description includes flow authorizations associated with coordinated communications.

46. 46. ​​The system of claim 45, wherein the gatekeeper interface circuitry is further configured to coordinate communications based on an association with the flow of communicating devices including one of the external device, an endpoint of the first network zone, or an endpoint of the second network zone.

47. 42. The system of claim 41, wherein the external data access description includes a subscription status associated with coordinated communications.

48. 48. The system of claim 47, wherein the gatekeeper interface circuitry is further configured to coordinate communications based on an association with the subscription status of a communicating device including one of a vehicle controller, a flow, a vehicle function, an application, an endpoint of one of the first network zone or the second network zone, or the external device.

49. a policy management circuit structured to interpret a policy including an external data routing description; a configuration circuit structured to configure the gatekeeper interface circuit in response to the external data routing description; 41. The system of claim 40, further comprising:

50. 50. The system of claim 49, wherein the external data routing description includes a local domain name server (DNS) that includes, for an endpoint in the first network zone or the second network zone, a plurality of local address values ​​each corresponding to at least one non-local address value for the endpoint in the first network zone or the second network zone.

51. 51. The system of claim 50, wherein at least one of the non-local address values ​​comprises an address value utilized by an external device.

52. 52. The system of claim 51, wherein the address value utilized by the external device comprises at least one of a standard value for the endpoint or a proprietary value for the endpoint.

53. 52. The system of claim 51, wherein the address value utilized by the external device comprises a previous local address value for an endpoint in the first network zone or the second network zone.

54. 1. A system comprising: a vehicle having a first network zone and a second network zone of a different type than the first network zone, the second network zone utilizing an IP addressing protocol; a policy management circuit configured to interpret a policy including an external data routing description, the external data routing description including a local domain name server (DNS) including, with respect to an end point in the second network zone, a plurality of local address values ​​each corresponding to at least one non-local address value for the end point in the second network zone; a configuration circuit structured to configure a gatekeeper interface circuit in response to said external data routing description; a gatekeeper interface circuit interposed between the first network zone and a transceiver selectively coupleable to an external device, and further interposed between the second network zone and the transceiver; Including, the gatekeeper interface circuit is configured to coordinate communications between an endpoint in the first network zone and the transceiver, and to coordinate communications between an endpoint in the second network zone and the transceiver; system.

55. 55. The system of claim 54, wherein the policy management circuitry is further configured to determine an address change of an endpoint in the second network zone and update the local DNS in response to the address change.

56. 55. The system of claim 54, wherein the external data routing description includes an external domain name server (DNS) that includes a plurality of external address values ​​for external network access locations, each corresponding to an endpoint in the second network zone.

57. 57. The system of claim 56, wherein at least a portion of the plurality of external address values ​​includes both a corresponding IPv4 external address and a corresponding IPv6 address.

58. 1. A system comprising: a vehicle having at least one network zone; a policy management circuit configured to interpret a policy including an external data routing description, the policy including a default policy value; a configuration circuit structured to configure a gatekeeper interface circuit in response to said external data routing description and said external data service description; the gatekeeper interface circuit interposed between the at least one network zone and at least one external communication portal selectively coupleable to an external device; Including, the gatekeeper interface circuit is configured to coordinate communications between an end point in the first network zone and the at least one external communication portal, and to coordinate communications between an end point in the second network zone and the at least one external communication portal. system.

59. the policy further includes a primary policy value; the configuration circuitry is further configured to configure the gatekeeper interface circuitry in response to the primary policy value.

59. The system of claim 58.

60. 60. The system of claim 59, wherein the configuration circuitry is further configured to determine whether the primary policy value is present, and, in response to determining that the primary policy value is present, utilize the primary policy value as the policy instead of the default policy value.

61. the policy further includes a secondary policy value; the configuration circuitry is further configured to configure the gatekeeper interface circuitry in response to the secondary policy value.

60. The system of claim 59.

62. 62. The system of claim 61 , wherein the configuration circuitry is further configured to determine whether the secondary policy value is present, and, in response to determining that the secondary policy value is present, utilize the secondary policy value as the policy instead of either the default policy value or the primary policy value.

63. 62. The system of claim 61, wherein the configuration circuitry is further configured to apply the secondary policy value as the policy and to apply a matching portion of the primary policy value as a further portion of the policy.

64. the default policy values ​​include a permanent storage policy; the primary policy values ​​include tool-supplied policies; 62. The system of claim 61.

65. 65. The system of claim 64, wherein the secondary policy value comprises a post-manufacturing policy.

66. 66. The system of claim 65, wherein the policy management circuitry is further configured to interpret the tool-supplied policy from a second external device.

67. 67. The system of claim 66, wherein the second external device comprises at least one device selected from the group consisting of a service tool, a manufacturing tool, a web-based application, and a cloud-based application.

68. 68. The system of claim 67, wherein the policy management circuitry is further configured to interpret the post-manufacture policy from the second external device.

69. 68. The system of claim 67, wherein the policy management circuitry is further configured to interpret the post-manufacture policy from a third external device.

70. 66. The system of claim 65, wherein the configuration circuitry is further configured to determine whether each of the primary policy value and the secondary policy value is present, and to utilize, in order, the secondary policy value, the primary policy value, or the default policy value.

71. 66. The system of claim 65, wherein the policy management circuitry is further configured to interpret the primary policy value from a second external device in response to the default policy value.

72. 66. The system of claim 65, wherein the policy management circuitry is further configured to interpret the secondary policy value from a second external device in response to at least one of the primary policy value or the default policy value.

73. a vehicle having at least one network zone; a policy management circuit structured to interpret a policy including an external data volume description; a configuration circuit structured to configure a gatekeeper interface circuit in response to said external data quantity description; the gatekeeper interface circuit interposed between the at least one network zone and a transceiver selectively coupleable to an external device, the gatekeeper interface circuit being further configured to coordinate communications between an endpoint of the at least one network zone and the transceiver; Including, the system.

74. 74. The system of claim 73, wherein the external data volume description includes data volume limits corresponding to a plurality of the endpoints of association of the at least one network zone.

75. 75. The system of claim 74, wherein the associated plurality of endpoints comprises a plurality of endpoints associated with corresponding at least one of a source address value, a destination address value, a source port value, a destination port value, a source application identifier, a destination application identifier, a source service set identifier, a destination service set identifier, a source flow of the coordinated communication, or a destination flow of the coordinated communication.

76. The external data quantity description is the amount of communication data corresponding to the selected period; an amount of communication data corresponding to a selected vehicle operating condition; the amount of communication data corresponding to a data provider associated with the application; bandwidth allocation for the transceiver; the bandwidth volume of said transceiver; the bandwidth allocation of the transceiver's channels; or the bandwidth volume of the transceiver channel; and at least one data restriction selected from the restrictions consisting of:

74. The system of claim 73.

Images