System, method and apparatus for off-vehicle communication control

Abstract

An example system includes a vehicle having at least one network zone, and policy manager circuitry that interprets a policy comprising a local DNS, an authorization description, and a firewall configuration description. The system includes configuration circuitry that configures a gatekeeper interface circuit in response to the policy, wherein the gatekeeper interface circuit is interposed between one of the network zones and an external communication portal and mediates communications between endpoints of the network zone and the external communication portal.

Description

[0001] CROSS-REFERENCE TO RELATED APPLICATIONS

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

[0003] Each of the above applications is incorporated herein by reference in its entirety. Background Art

[0004] Vehicle communication networks are utilized to connect sensors, actuators, controllers, and communication devices throughout a vehicle. Recent trends have been increasing the burden on these vehicle communication networks, with more devices connected, more data transferred between devices, lower latency requirements to meet vehicle performance, safety, and transmission requirements, and added vehicle features. Furthermore, consumers expect increased connectivity and features that place a greater burden on vehicle communication networks. These trends are expected to continue and accelerate for the foreseeable future.

[0005] Traditional vehicle communication networks (CAN, LIN, FlexRay, MOST, LVDS, etc.) suffer from a number of shortcomings and challenges. These vehicle communication networks have been developed to meet the specific challenges of the vehicle environment and have accordingly evolved independently from other networks, such as computer local area networks, wide area networks, large-scale interconnected networks (e.g., the Internet), and wireless networks. Most vehicle networks consist of a data link layer and an application layer, utilizing robust and specialized equipment (such as the Controller Area Network (CAN) bus), with dedicated or shared wiring between devices utilizing specific data protocols (e.g., J1939, OBD, etc.). Modern vehicles may have multiple network buses with specific commands and communications available, as well as limited customization and data speeds available. For example, the CAN bus typically operates at up to approximately 1 Mbps, with the high-capacity CAN bus operating at up to approximately 10 Mbps. In addition, depending on the configuration, the amount of traffic on the CAN, the priority of specific messages, etc., the CAN bus experiences delays greater than 25 ms and typically higher, ranging from approximately 60 ms to 500 ms.

[0006] As the number of devices and the data rate requirements from the devices increase, traditional vehicle communication networks require the implementation of higher performance buses. Because the automotive industry is a high-volume industry with very low tolerance for component failures, automakers utilize the same components for a long time and across a wide range of vehicles - including sharing components across manufacturers. In addition, changes to nominally more capable components may introduce risk, integration costs, the burden of re-qualification for a given application, or have other undesirable consequences for the system. Accordingly, even if the vehicle communication network transitions to a higher-capability network configuration, it is desirable to keep the network type isolated in the system and to keep a large number of legacy devices (e.g., CAN-compatible) in the system for a long period of time.

[0007] The collection of data from vehicles includes several additional challenges. For example, data collection operations are subject to regulatory and liability risks, particularly with respect to the collection of data that may include private information, personally identifiable information, and / or liability-related information. Data collectors, including entities that may have ownership or possession of sensitive data, are subject to risks in retaining the data, for example, in the event of inadvertent or malicious access to the data. With respect to collecting vehicle data, a large amount of data may be collected, and there may be a large number of purposes for collecting the data, thereby increasing the risk relative to other general data storage applications. Accordingly, it may be desirable to control data collection, storage, and access to reduce risk, and it may be further desirable to include verification of data access, partitioning, or other data exclusion when data is not in use, etc.

[0008] The amount and type of data to be transmitted between vehicles and external devices further complicates data collection for vehicles, where the vehicle's network system is constrained by mobile applications, expenses, and / or bandwidth limitations caused by high data rates and / or large data transmission. Even considering the above, customer demand, market expectations, increasing demands for efficiency in vehicle operation, and improved functional capabilities for data-related applications are continuing to cause a surge in the total amount of data to be transmitted, the number of off-vehicle applications that utilize the transmitted data, the number of purposes for which the data can be used, and the number of users or entities with legitimate needs for portions of the transmitted data. In addition, applications that utilize data continue to improve in sophistication and capability, thereby increasing the demand for data against limited available transmission resources and increasing the cost and complexity of logistical control and storage of the transmitted data. For example, higher-capacity routing or operating algorithms associated with vehicles, increased automation of vehicle functions, increased demand for prognostic determination and / or maintenance support, and increased media streams (both the number of media streams and the quality of those media streams) all drive increased demands for data rates, the amount of data stored, and the number of entities or applications that access the stored data. Summary of the Invention

[0009] As a non-limiting example and for the sake of clarity of this description, the description herein refers to a vehicle application. However, the embodiments herein are applicable to other applications with similar challenges and / or implementations. Without being limited to any other application, the embodiments herein are applicable to any application with multiple endpoints, including multiple data sources, controllers, sensors and / or actuators, and may further include endpoints present in different or distributed network environments, and / or the embodiments herein are applicable to applications with a history or traditional networking or communication system that can be transformed (within a given system, as a system class and / or as an industry) to a newer and / or more capable networking or communication system. Examples and non-limiting embodiments include one or more of the following: 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 should 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, cost parameters (e.g., operating costs, integration costs, operational costs, data communication and / or storage costs, service costs, and / or downtime costs) of a particular application. Accordingly, wherever the present disclosure references a vehicle, a vehicle system, a mobile application, an industrial equipment, a robotic system, and / or a manufacturing system, each of these is also contemplated herein and may be applicable in certain embodiments or not applicable in certain other embodiments, as will be understood by those skilled in the art having the benefit of this disclosure.

[0010] As reflected in the described embodiments, the disclosure herein has recognized that the aforementioned complexities and other challenges have a synergistic effect that makes the complexity of the vehicle data environment even greater than the sum of the individual contributions from each challenge.

[0011] As an example, an increased number of entities or applications accessing data increases the likelihood that an individual data request will overlap, for example, with multiple entities requesting the same or similar data. Further, an increased number of entities or applications accessing data increases the likelihood that members of an access group will share similar authorization levels, such that data access for individual members of the entity or application group will benefit from data management.

[0012] In another example, regulations relating to sensitive data are increasing, which generally increases the data management requirements of the system, but also increases the possibility that data management may be subject to multiple constraints at a given time, and / or constraints that change over time as regulations change, and / or based on relevant jurisdictions that may change as the location of the vehicle changes.

[0013] In yet another example, the complex environment of currently known and evolving vehicle network architectures (e.g., vehicles with mixed network types and / or partitioned networks) increases the complexity of data access for individual entities, which, without certain aspects of the present disclosure, may otherwise require individual entities to determine request parameter specifications for specific data elements and update those request parameters as the vehicle network architecture evolves. Given the increasing number of entities requesting data access, the overall cost of supporting the automotive market increases non-linearly, as each of the entities incurs the cost of tracking the request parameter specifications. Additionally, the trajectory of additional entities requesting data access moves toward entities located further away from core automotive functionality in the technical knowledge space, and accordingly, the intricacies and idiosyncrasies of vehicles and / or automotive applications, including on-vehicle network configurations, specific data descriptions, data request and communication protocols, industry standards or conventions for presenting information, and so forth, are becoming less well-known on average for each incremental new entity, further increasing the cost volume function (e.g., the cost over time to provide a given entity with desired data collection deliverables, where a given entity may be an automotive manufacturer, and / or a vehicle market, a geographic market, and / or an industry such as the automotive industry, the passenger car industry, etc.). For example, consider a nominal cost volume function such as:

[0014] COST = number of entities * basic learning cost * adaptation of transformation trajectory * data trajectory cost * adaptation cost of regulation * data access / storage responsibility cost.

[0015] The COST function described is a non-limiting, nominal example that demonstrates how various challenges and complexities with currently known systems interact and combine to increase the cost of meeting future data collection capabilities for vehicle applications. The cost parameters described are not intended to cover all costs associated with the challenges that exist for the automotive data collection industry or currently known systems. Parameters can be averages or other complex functions, and the values ​​of specific parameters are generally not known specifically. Additionally, the units of COST can be expressed in monetary terms, as resources to meet data collection goals over time (e.g., engineering hours, computing time, etc.), as another non-monetary unit such as equivalent issuance, customer satisfaction, risk incurred, public perceived loss or gain, etc. The number of entity parameters generally reflects the number of entities accessing vehicle data over time; base learning costs reflect the details of data collection requirements and protocols for new entities to learn for specific vehicles, vehicle types, markets, etc.; adaptation to the transition cost trajectory reflects the cost of adapting to changing vehicle network configurations, which includes network types and organization and interactions with endpoints or devices on those networks; data trajectory costs reflect the increasing demand for data collection from relevant vehicles over time, including data communications, storage and resulting functional consequences, such as the cost of not being able to support desired applications or enhancing data communications infrastructure; adaptation costs of regulations reflect the costs associated with the increased number of regulations, the increased number of regulatory frameworks and / or the increased number of regulatory entities; and data access / storage liability costs reflect the costs incurred for compliance and security of data and / or losses incurred due to data breaches, unauthorized use, premature expiration of data, etc.

[0016] Without limitation 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 the data collection system, the basic learning cost for new entities to implement applications using the collected data, the adaptation cost of changing vehicle network configurations, the cost incurred to meet the increased demand for data collection, the cost of adapting to the changed regulatory environment, and / or the cost of losses to security data and / or to violations or unauthorized use. Certain embodiments and / or aspects of the disclosure herein can address one or more of the described cost parameters. Certain embodiments and / or aspects of the disclosure herein can increase one or more given cost parameters, but are beneficial by reducing the overall cost function for the target vehicle, vehicle type, entity, industry, etc. Certain embodiments and / or aspects of the disclosure herein can increase one or more given cost parameters, but provide other advantages such as improved functionality. In certain embodiments, the improved functionality can be achieved at an increased cost but at a lower cost than previously known systems configured to achieve similar improved functionality.

[0017] Without being limited to any other aspect of the present disclosure, embodiments herein provide the configuration of inter-network, intra-network and extra-vehicle communication control using extra-vehicle devices (such as cloud applications, web-based tools or applications, manufacturing tools, OEM tools, service tools, etc.). Embodiments herein provide the execution of activity diagnosis, activity testing, vehicle control operations and / or activity auxiliary operations, including operations involving streams, applications, service combinations and / or vehicle functions of both aspects and / or participating devices on and off the vehicle. Embodiments herein provide convenient monitoring, diagnosis and configuration of inter-network, intra-network and extra-vehicle communication, the communication including communications traveling between endpoints, between networks and / or external devices, and further including communications involving associated endpoints, wherein association is made according to relevant streams, vehicle functions, applications, service groups, source and / or destination addresses and / or source and / or destination ports. Embodiments herein provide the integration (physical and / or logical) of extra-vehicle communication control, regulation, data management, security implementation, authorization implementation, licensing implementation, service implementation and / or subscription implementation. Embodiments herein provide for the scheduled implementation of policies, including updating policies, adjusting policies, and / or verifying authorization for changes to policies. Embodiments herein provide for the scheduled implementation of communication device levels and / or QoS implementations, including for communications related to ports, flows, applications, vehicle functions, vehicle controllers, service groups, and / or external communication portals. Embodiments herein provide for the scheduled implementation of data utilization, including utilization of specific external communication portals, APNs, and / or data service providers. Embodiments herein provide for adjustments to external communication portals for external communication of vehicles to reduce costs, improve service levels, limit and / or reduce data utilization of specific external communication portals, improve the overall capabilities of external communication of vehicles, to support vehicle missions, and / or transparently make such adjustments to communication devices (e.g., local communication devices and / or external devices, applications, and / or tools).

[0018] For the purpose of promoting an understanding of the principles of the present disclosure, reference will now be made to the embodiments illustrated in the accompanying drawings and described in the following written specification. It should be understood that no limitation to the scope of the present disclosure is intended thereby. It should be further understood that the present disclosure encompasses any changes and modifications to the illustrated embodiments, and includes further applications of the principles disclosed herein, as would normally occur to one skilled in the art to which the present disclosure pertains. BRIEF DESCRIPTION OF THE DRAWINGS

[0019] Figure 1 is a schematic diagram of an example system for regulating an on-vehicle network according to certain embodiments of the present disclosure.

[0020] Figure 2is an example system and schematic diagram for regulating a network on a vehicle according to certain embodiments of the present disclosure.

[0021] Figure 3 is an example system and schematic diagram for regulating a network on a vehicle according to certain embodiments of the present disclosure.

[0022] Figure 4 is a schematic diagram of a converged network device (CND).

[0023] Figure 5 is a schematic diagram of a converged network device (CND).

[0024] Figure 6 is a schematic diagram of a converged network device (CND).

[0025] Figure 7 is a schematic diagram of a converged network device (CND).

[0026] Figure 8 is a schematic diagram of a converged network device (CND).

[0027] Figure 9 is a schematic diagram of a converged network device (CND).

[0028] Figure 10 is a diagram of a configurable Ethernet switch.

[0029] Figure 11 is a schematic diagram of a configurable edge gateway.

[0030] Figure 12 is a schematic diagram of an example system for regulating an on-vehicle network according to certain embodiments of the present disclosure.

[0031] Figure 13 is a schematic diagram of an example system for regulating an on-vehicle network according to certain embodiments of the present disclosure.

[0032] Figure 14 is a schematic diagram of an example system for regulating an on-vehicle network according to certain embodiments of the present disclosure.

[0033] Figure 15 is a schematic diagram of an example system for regulating an on-vehicle network according to certain embodiments of the present disclosure.

[0034] Figure 16 is a schematic diagram of a system for regulating network communications for a vehicle.

[0035] Figure 17 It is a schematic diagram of CND.

[0036] Figure 18is a schematic diagram of endpoints of a network responsive to actuator command values.

[0037] Figure 19 is a schematic diagram of a system for regulating network communications for a vehicle.

[0038] Figure 20 is a schematic diagram of a system for providing visualization data of a transportation network.

[0039] Figure 21 is a schematic illustrative example of a local DNS table.

[0040] Figure 22 is a schematic illustrative example of vehicle communication data.

[0041] Figure 23 is a schematic, pictorial example of visualizing data.

[0042] Figure 24 is a schematic, pictorial example of visualizing data.

[0043] Figure 25 is a schematic, pictorial example of visualizing data.

[0044] Figure 26 is a schematic, pictorial example of visualizing data.

[0045] Figure 27 is a schematic, pictorial example of visualizing data.

[0046] Figure 28 is a schematic diagram of a system for regulating an onboard network according to certain embodiments of the present disclosure.

[0047] Figure 29 is a schematic pictorial example of a strategy.

[0048] Figure 30 is a schematic pictorial example of a strategy.

[0049] Figure 31 is a schematic pictorial example of a strategy.

[0050] Figure 32 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0051] Figure 33 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0052] Figure 34 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0053] Figure 35 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0054] Figure 36 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0055] Figure 37 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0056] Figure 38 is a schematic pictorial example of a strategy.

[0057] Figure 39 is a schematic illustrative example of a local DNS table.

[0058] Figure 40 is a schematic illustrative example of a local DNS table.

[0059] Figure 41 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0060] Figure 42 is a schematic pictorial example of a strategy.

[0061] Figure 43 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0062] Figure 44 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0063] Figure 45 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0064] Figure 46 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0065] Figure 47 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0066] Figure 48 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0067] Figure 49 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0068] Figure 50is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0069] Figure 51 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0070] Figure 52 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0071] Figure 53 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0072] Figure 54 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0073] Figure 55 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0074] Figure 56 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0075] Figure 57 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0076] Figure 58 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0077] Figure 59 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0078] Figure 60 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0079] Figure 61 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0080] Figure 62 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0081] Figure 63 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0082] Figure 64 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0083] Figure 65is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0084] Figure 66 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0085] Figure 67 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0086] Figure 68 Depicts illustrative operations for processing messages.

[0087] Figure 69 An illustrative operation of downsampling a message is depicted.

[0088] Figure 70 An illustrative operation of upsampling a message is depicted.

[0089] Figure 71 is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0090] Figure 72 is a schematic pictorial example of a strategy.

[0091] Figure 73 is a schematic pictorial example of a strategy.

[0092] Figure 74 is a schematic pictorial example of a strategy.

[0093] Figure 75 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0094] Figure 76 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0095] Figure 77 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0096] Figure 78 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0097] Figure 79 is a schematic flow chart depicting an example process for regulating communications in a vehicle.

[0098] Figure 80 is a schematic diagram depicting a system for regulating out-of-vehicle communications according to certain embodiments of the present disclosure.

[0099] Figure 81is a schematic diagram of a system for regulating out-of-vehicle communications, according to certain embodiments of the present disclosure.

[0100] Figure 82 is a schematic depiction of a visual management controller.

[0101] Figure 83 is a schematic flow chart of the process used to provide visual data.

[0102] Figure 84 is a schematic flow chart of a process for updating a policy. DETAILED DESCRIPTION

[0103] refer to Figure 1 , an example system schematically depicts aspects of an embodiment of the present disclosure. The example system includes an application 102 (e.g., a vehicle) having a first network 104 and a second network 106 thereon. As utilized herein, a network should be broadly construed and may include one or more aspects such as: hardware implementation (e.g., wire and wiring configuration, applicable standards (such as connectors), insulation, shielding, wire requirements (such as metering, torsion, coaxial arrangement, etc.)), implementation of any layer (e.g., from the ISO 7-layer model, such as: application layer, presentation layer, session layer, transport layer, network layer, data link layer, and / or physical layer; although a given network may have fewer layers and / or layers organized in a different manner); and / or may be wired or wireless in whole or in part. Without limiting any aspect of the present disclosure, example and 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 some embodiments, one or more networks may be an electrical signal area (e.g., a device that provides data and / or receives commands as electrical signals (such as, voltage values, frequency values, and indicated resistance values), etc.), such as a sensor or actuator electrically coupled to an interpretation device that is capable of receiving information from and / or transmitting information or commands to one or more electrical devices on the electrical signal area.

[0104] The example system includes a first network 104 that is a different type from a second network 106. As utilized herein, two networks of different types should be broadly construed and include networks having different protocols, at least one layer that is different from one another (e.g., having different application layers, presentation layers, etc.), two networks that are operationally incompatible (e.g., a device coupled to one of the networks will not function on the second network without changes to connectivity, communication, or other aspects), and / or two networks that are message-incompatible (e.g., a message configured for a first network in the network cannot be directly placed on a second network in the network due to differences such as addressing, frame construction, message logic compatibility, etc.). The example system includes the first network 104 being an Ethernet-implemented network and the second network 106 of a different type, such as a CAN network and / or a LIN network.

[0105] The example system further includes a converged network device (CND) 108 that is interposed between the first network 104 and the second network 106 and is structured to facilitate communications between the first network 104 and the second network 106. The CND 108, interposed between the networks 104 and 106, includes embodiments in which the CND 108 passes communications between the networks 104 and 106, such as receiving communications from the first network 104, translating communications destined for the second network 106 (e.g., encapsulating all or part of the communications into messages destined for the second network 106; converting 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 (e.g., message identifiers), etc.). In some embodiments, the CND 108 does not physically pass communications or only passes portions of communications, but rather can regulate, manage, provide permissions, throttle messages, or otherwise control other devices (e.g., switches, routers, gateways, repeaters, etc.) that perform operations to pass communications between networks. Accordingly, in some embodiments, a CND between the networks 104, 106 may be physically located between the networks 104, 106, wherein communications passed between the networks 104, 106 are physically received by components of the CND 108. In some embodiments, the CND 108 between the networks 104, 106 may have visibility into communications on the networks 104, 106 and control devices for regulating message passing between the networks. In some embodiments, the CND 108 between the networks 104, 106 may have visibility into endpoints on the networks 104, 106 and control devices for regulating message passing between the endpoints of each physical network 104, 106.

[0106] A person skilled in the art having the benefit of the present disclosure may readily arrange CND 108 according to one of these intervention schemes and / or according to a combination of more than one of these intervention schemes having information generally available when considering a particular system. In designing an intervention scheme for CND 108 for a given system, certain considerations include, but are not limited to: the number and type of networks on the vehicle; the capabilities of the individual networks (e.g., throughput, bandwidth, address availability, broadcast / unicast / multicast availability and desirability of each network and / or endpoint on the network, the requirement and / or availability of affirmative acknowledgement for each network and / or endpoint, and / or the requirement and / or availability of encryption for each network and / or endpoint); the availability, location and / or control of the network implementation controller (e.g., the presence and ownership of switching devices; access to instructions (such as firmware or buffers) for available devices; and / or the connectivity of available devices to one or more networks, such as whether the devices are arranged to implement desired messages passed between networks, desired redundancy and / or desired failure mode responses); the capabilities of the network implementation controller (e.g., buffer sizing and availability, message rate capacity, processing capacity); the availability, location and / or control of the network implementation controller (e.g., the presence and ownership of switching devices; access to instructions (such as firmware or buffers) for available devices; and / or the connectivity of available devices to one or more networks, such as whether the devices are arranged to implement desired messages passed between networks, desired redundancy and / or desired failure mode responses); hardware cost considerations for adding components to the system; hardware cost considerations for providing capabilities for CND operations in other components of the system; integration cost considerations and system capabilities of implementing additional CND-specific components and / or adding capabilities for CND operations in other components of the system); the number, type and / or message throughput of endpoints utilizing cross-network communications; expected changes in any one or more of these aspects over the life of a vehicle (e.g., due to service events, upgrades and / or advertising campaign events (such as, product recall events associated with the vehicle)); and / or expected changes in any one or more of these aspects over the life of an associated group of vehicles (e.g., an associated fleet of vehicles; model years of vehicles; and / or groups of model years associated with the system, such as, vehicles expected to have similar network infrastructure, with changes to device distribution, changes to the network, etc.).

[0107] exist Figure 1In the example of FIG, a first external device 110 is depicted as being communicatively coupled to the application 102. The first external device 110 is directly coupled to the application 102, which may include a direct 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 can be connected to a specific network (e.g., the first network 104 or the second network 106), and / or can be connected to another device (e.g., the CND 108 and / or a device mediated by the CND 108) that directly manages communications with the external device 110. 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 can manage communications so that the external device 110 only receives authorized communications, and can further manage communications so that the external device 110 can request communications from endpoints on any of the networks 104, 106 and still receive the requested information. In some embodiments, the first external device 110 can be a service tool, an original equipment manufacturer's (OEM's) tool, a manufacturer's tool, a body builder's tool, and / or an application (e.g., an application that communicates via a computing device such as a laptop, desktop, mobile device, and / or mobile phone; e.g., an application operated by an owner, servicer, fleet manager, etc.).

[0108] exist Figure 1 In the example of FIG, the second external device 114 is depicted as communicating with the application 102 and / or the first external device 110 via a cloud connection 112. The cloud connection 112 can be any type of connection, including a mobile connection (e.g., a modem on the application 102, connecting using cellular data or another data service), an Internet connection, a wide area network (WAN), and / or a combination of these. The cloud connection 112 can access the application 102 through a transceiver, which can form part of and / or be at least partially mediated by the CND 108. In some embodiments, the application 102 can have more than one transceiver, with one or more or all of the transceivers being at least partially mediated by the CND 108. In some embodiments, the CND 108 can mediate some vehicle communications (e.g., from certain networks, endpoints, devices, data types, streams, and / or applications on the vehicle), but not other communications.

[0109] As used herein, endpoints should be understood broadly. An endpoint is an organizational concept for access to a vehicle's networks 104, 106 and can include specific devices (e.g., engine controllers, transmission controllers, door controllers, infotainment systems, etc.), groups of devices with a single network access (e.g., multiple devices communicating together through a single network access point, where the networks 104, 106 and / or CND 108 may have visibility into individual devices, or may only have visibility into communications from the endpoint as a group). For example, a door controller (not shown) can be an endpoint for one of the networks 104, 106, where communications for underlying devices (e.g., door position sensors, door lock actuators and positions, window actuators and positions, etc.) are passed to the network 104, 106 through the door controller endpoint, where the CND 108 can have visibility into the underlying devices (e.g., messages indicating the door position that include an identifier that the door position sensor is sending the message), or can have visibility only to the door controller endpoint (e.g., messages indicating that the door position is known to be provided by the door controller, but the CND 108 is unaware of which underlying devices may have sent the message). A person skilled in the art, having the benefit of this disclosure and the information generally available regarding 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; messages to be passed between vehicle controllers; the regulatory options to be available for a given endpoint as set forth in this disclosure (e.g., message rates, priorities, data collection, message configuration, identity information for components, addressing management between networks and with external devices, etc.); the desired granularity of data control (e.g., permission for specific devices to provide or request information; permission for applications on or off the vehicle to provide or request information; security authorizations and types, such as per-user, per-entity, per-device, per-application, per-flow, etc.); and / or redundancy options to be available for a given system (e.g., redundancy of network communication capabilities, redundancy of control operations and related equipment, and / or redundancy of CND operations where CND components are distributed in more than one location in a vehicle).

[0110] As used herein, applications should be understood broadly. Example applications include groups of related vehicle functions or operations, such as speed control (e.g., speed control of a vehicle or a subcomponent of a vehicle (such as an engine or drivetrain)), anti-lock braking system (ABS) operation, advanced driver assistance systems (ADAS), performance control (e.g., implementing torque requests, speed requests, or other performance requests from an operator), or other functions of a vehicle. Example applications include groups of related functions other than the vehicle, such as applications that support geolocation and / or navigation to request and / or process service information related to the vehicle, and / or third-party applications that interact with the operator (e.g., to find the nearest hotel, selected events, etc.). Applications can be implemented by vehicle manufacturers, suppliers, original equipment manufacturers, body builders, third parties, operators, service personnel, etc. As used herein, applications provide organizational concepts that can be utilized to relate certain data, certain endpoints, and / or related functions of the vehicle. In certain embodiments, CND 108 may utilize an application to identify a data source, a data destination, permissions available to the application, priority information associated with the application, and the like to implement certain data conditioning operations herein.

[0111] As used herein, streams should be understood broadly. Example streams include related groups of data (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related groups of functions (e.g., among vehicle functions, functions outside of the vehicle (such as service operations and / or data collection), aggregations between related vehicles, and / or combinations of these that are relevant for a particular system), related groups of devices (e.g., door actuators), and / or related groups of applications. As used herein, streams provide an organizational concept that can be utilized to relate certain data, certain endpoints, certain applications, and / or related functions of or in addition to vehicles. In certain embodiments, CND 108 can utilize streams to identify data sources, data destinations, permissions available for the stream, priority information associated with the stream, and the like, to implement certain data conditioning operations herein. In certain embodiments, the utilization of streams allows CND 108 to perform classification 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 an example, if the vehicle speed is being transmitted to support a vehicle speed management application, the CND 108 applies a high priority to the vehicle speed message. However, if the vehicle speed is being transmitted to support a trip planning flow (e.g., where the trip planning flow exists and does not have a high priority), the CND 108 may apply a lower priority to the vehicle speed message. In a further example, a failure of a vehicle controller, a portion of the network, or other non-nominal conditions may cause the vehicle speed management application to migrate to another controller in the system, whereby the vehicle speed message is being transmitted (e.g., where the backup controller is on another network) to support the vehicle speed management application, and the CND 108 may apply a higher priority to the vehicle speed message. Utilizing flows and applications to organize components of the system allows the same or similar information to be regulated by CND 108 in a differential manner to support various functions, thereby allowing improvements in the performance and security of network regulation operations (e.g., reducing unnecessary cross-network traffic, providing information only when needed, and / or regulating communications with external devices), and utilizing flows and applications to organize components of the system supports additional functionality relative to previously known systems, such as redundancy support, distributed control, and granular cross-network messaging.

[0112] As used herein, a service group should be understood broadly. Example service groups include groups of related applications for a vehicle. The related application group can be located entirely on the vehicle (e.g., one or more vehicle systems, functions, or other applications of the vehicle), and / or can include aspects located on an external device (e.g., having support for processing, data collection or storage, data obtained from an external source used by the service group, etc.), which can be a web application, web tool, cloud application, service application, etc. In certain embodiments, any group of local communication devices can be logically related and serve as a service group. Utilizing service groups to organize the components and / or applications of a system allows the same or similar information to be regulated by CND 108 in a differential manner to support various functions, thereby allowing improvements in performance and security of network regulation operations (e.g., reducing unnecessary cross-network traffic, providing information only when needed, and / or regulating communications with external devices), and utilizing service groups to organize the components and / or applications of a system supports additional functionality relative to previously known systems, such as redundancy support, distributed control, and granular cross-network messaging.

[0113] As utilized herein and without limitation to any other aspect of the present disclosure, a regulated component includes any component of a system that is regulated with respect to communications, including data collection, subscriptions, data requests, access to external devices and / or addresses, access to network zones, access to endpoints, utilization of communication resources (e.g., network zone bandwidth, external communication portals, total data limits or amounts, etc.). Regulated components include, but are not limited to, one or more of the following: an endpoint, a flow, an application, a controller, a service group, an interface circuit, a network zone, an external communication 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.

[0114] Example operations for regulating communications between endpoints of a network zone and / or regulating communications with external communication portals and / or external devices include, but are not limited to, operations such as those described below. The regulating operations may be performed for endpoints, for associated endpoint groups, and / or for network zones. Associated endpoint groups may be associated based on flows, applications, service groups, controllers, vehicle functions, source addresses for communications, and / or destination addresses for communications. In certain embodiments, identifiers may be provided to applications, service groups, and / or flows as a means of associating related components such as endpoints. The regulating operations may be performed by, but are not limited to, a CND, a network gateway, a network interface circuit, and / or a gateway interface circuit. The regulating operations are described throughout this disclosure in the context of certain example regulating devices, but embodiments may be configured to have other devices that perform the regulating. Example communication and / or regulating operations include:

[0115] Providing communication between a first endpoint and a second endpoint (in either direction), including configuring the communication (e.g., protocol, message information, metadata, parameter elements, etc.) for a receiving network zone and / or endpoint device;

[0116] Encapsulating a message from a first network zone and providing the encapsulated message to a second network zone;

[0117] Determining whether a requesting device (and / or associated flow) on one of the network zones has permission to request communications from a device on another of the network zones, and providing communications responsive to a permission determination;

[0118] adjusting at least one of a data rate, a requested resolution, and / or a requested response time for communications between devices of the network zones based on an admission determination for the requesting device, communications capabilities of the requesting and / or offering devices, and / or network performance parameters of one or both network zones (e.g., currently available bandwidth, absolute or current network capacity, network utilization, etc.), and / or a priority value for communications associated with the requesting device;

[0119] Performing upsampling and / or downsampling operations on data transferred between network zones;

[0120] Mirroring communications from the first endpoint to a port of the second network zone, including encapsulating, configuring, processing, and / or upsampling or downsampling the mirrored communications;

[0121] providing communications 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 monitoring device, and / or wherein providing communications includes encapsulating, configuring, processing, and / or upsampling or downsampling the provided communications, and / or wherein the provided communications may be unicast, multicast, and / or provided as a subscription service;

[0122] providing communications from the second endpoint device to a device coupled to the first network zone or the second network zone 1908 (such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitoring device), and / or wherein providing communications includes packaging, configuring, processing, and / or upsampling or downsampling the provided communications, and / or wherein the provided communications may be unicast, multicast, and / or provided as a subscription service;

[0123] providing communications from a device coupled to the second network zone (such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitoring device) to the first endpoint, and / or wherein providing the communications includes encapsulating, configuring, processing, and / or upsampling or downsampling the provided communications, and / or wherein the provided communications may be unicast, multicast, and / or provided as a subscription service;

[0124] o further providing communication as a command value, e.g., wherein the first endpoint performs an operation related to the mission of the mobile application in response to the command value (e.g., sets a set point, target value, or threshold in response to the command value);

[0125] providing communications from a device coupled to the second network zone (such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitoring device) to the first endpoint, and / or wherein providing the communications includes encapsulating, configuring, processing, and / or upsampling or downsampling the provided communications, and / or wherein the provided communications may be unicast, multicast, and / or provided as a subscription service;

[0126] o further providing the communication as a test execution value, e.g., wherein the first endpoint performs an operation related to an active context execution operation of the mobile application (e.g., performing certain operations for a service test, an active diagnostic operation, etc.) in response to the command value;

[0127] providing communications from a first endpoint to a plurality of second endpoint devices, wherein the provided communications are configured to meet a superset of the requirements of the second endpoint devices (e.g., data rate, resolution, units, etc.), and wherein the provided communications may be unicast, multicast, and / or provided as a subscription service;

[0128] Parsing a communication value from a first device (e.g., a first endpoint, a second endpoint, and / or a device coupled to a network zone, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitoring device), determining a target device (e.g., a communication recipient and / or a communication provider responsive to the communication value) in response to the parsed communication value, and configuring communications for the target communication recipient and / or communication provider in response to the parsed communication value. For example, the communication value may include a universal and / or normalized component identifier (e.g., turbine temperature, front passenger door actuator, etc.), and the CND determines a corresponding endpoint corresponding to the component identifier based on the current configuration of the mobile application, and may further determine communication routing, packaging, processing, etc. to be converted between the first device and the target device. For example, such operations allow the configuration and placement of devices on the network zone to be changed without requiring the device, service personnel, or other requestors to track the specific configuration and placement of the devices;

[0129] o Additionally or alternatively, such operations include: the CND storing configuration information in response to configuration changes (e.g., replacement or movement of a device from one network zone to another, changes to communication parameters or capabilities of a device, etc.), and / or performing runtime determinations to confirm the location, identity, configuration, communication parameters, and / or capabilities of the device, which may be utilized during runtime operation and / or stored for later utilization and / or stored as a default configuration subject to further updating;

[0130] · Perform any one or more of these operations on a group or subgroup of devices, such as where the devices are integrated in relation to a single endpoint but can be treated as separate devices by other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitoring devices) that communicate with the network zone. For example, such operations allow for multiple configurations, updates, and / or upgrades of a mobile application, where a first configuration has two (or more) devices with separate endpoints and a second configuration has two (or more) devices utilizing a single endpoint (and / or two devices integrated into a single device). Example and non-limiting embodiments include: integrating multiple sensors (e.g., smart sensors with network communication capabilities, multiplexing signals, etc.) that communicate with the network zone through a single interface; and / or replacing the interface of multiple components behind a single network interface (e.g., a single communication device, such as an edge gateway or a configurable edge gateway, that interfaces with a single network zone as a single endpoint and manages communications for the associated devices). In a further example, such operation allows devices to communicate across network zones regardless of changes in configuration to support upgrades and updates related to the relationship of the devices to the endpoints and to support backward compatibility (e.g., later configurations, later distribution of control between devices, etc., where operation of the CND allows earlier systems with different configurations to support updated configurations and / or distribution of control between devices);

[0131] o Additionally or alternatively, such operations include: the CND storing configuration information in response to configuration changes (e.g., intervention of a single endpoint between more than one device and a network zone, integration of devices, etc.), and / or performing runtime determinations to confirm the location, identity, configuration, communication parameters and / or capabilities of a device and / or the integration state of a device, which may be utilized during runtime operation and / or stored for later utilization and / or stored as a default configuration subject to further updating;

[0132] · Performing any one or more of these operations on a group or subgroup of devices, such as where the devices are distributed between more than one endpoint but can be viewed as a single device by other endpoints or devices communicating with the network zone (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitoring devices). For example, such operations allow multiple configurations, updates, and / or upgrades of a mobile application, where a first configuration includes a device with a single endpoint and a second configuration has a device (or portion thereof) utilizing more than one endpoint (and / or a previously integrated device consisting of two or more separate devices in the second configuration). Example and non-limiting embodiments include separating a group of sensors (e.g., smart sensors with network communication capabilities, multiplexing signals, etc.) that communicate with the network zone through a single endpoint into one or more sensors each having a separate endpoint (and / or a subgroup of multiple sensors each having a separate endpoint). In a further example, such operations allow devices to communicate across network zones regardless of changes in configuration to support upgrades and updates related to the relationship of the device to the endpoint and to support backward compatibility (e.g., later configurations, distribution of control between devices, etc., where operation of the CND allows an earlier system with a different configuration to support the later configuration);

[0133] o Additionally or alternatively, such operations include: the CND storing configuration information in response to configuration changes (e.g., partitioning of a device behind a single endpoint on a single network zone into more than one endpoint and / or across more than one network zone, etc.), and / or performing runtime determinations to confirm the location, identity, configuration, communication parameters and / or capabilities of the device and / or the integration state of the device, which may be utilized during runtime operation and / or stored for later utilization and / or stored as a default configuration subject to further updating;

[0134] Implementation of a service-oriented architecture, in which the CND determines available services (e.g., data parameters available for communication, command values ​​available for execution, and / or configurations of these, such as rate information, units, resolution, precision, accuracy, availability descriptions, related data, and / or operating conditions), publishes available services, and / or determines subscribing clients (e.g., devices, streams, and / or endpoints) for available services;

[0135] o Additionally or alternatively, such operations include: CND determining permissions and / or authorizations for publishing available services, for viewing available services (and / or portions of available services), and / or for subscribing to available services;

[0136] o Additionally or alternatively, such operations include: the CND identifying the subscribing entity as an endpoint, device, flow, and / or external device, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitoring device;

[0137] o Additionally or alternatively, such operations include: CND determining a priority of service-oriented communications, which may be dependent on a publishing device, endpoint, or associated flow and / or dependent on a subscribing device, endpoint, or associated flow;

[0138] o Additionally or alternatively, such operations include: the CND adjusting service-oriented architecture operations in response to an operational condition (e.g., a mobile application operational condition, a network status of one or more affected network zones, a communication status of one or more external devices, etc.);

[0139] o Additionally or alternatively, such operations include: CND accessing stored information setting forth available services, publication parameters (permissions, priorities, relevant operating conditions, etc.) and / or subscribing entity information;

[0140] o Additionally or alternatively, such operations include: CND updating stored information in response to one or more of: received updates, such as policy descriptions, service configuration descriptions, etc.; runtime updates from endpoints, devices, and / or flows, such as, but not limited to, those performed during startup or shutdown operations of the mobile application;

[0141] o Additionally or alternatively, such operations include: CND implementing a service-oriented architecture based on runtime operations with or without storing information and / or updating or without updating stored information; and / or

[0142] o Additionally or alternatively, allowing updates to stored information, runtime updates to stored information, and / or runtime operations that implement a service-oriented architecture in response to priorities and / or permissions associated with the device, endpoint, and / or flow requesting the updates and / or runtime implementation;

[0143] Additionally or alternatively, the operation of the example CND includes adjusting the operation of any one or more of the above items in response to an operating condition of the mobile application (e.g., adjusting communication operation during certain operations, such as: high power operation; high transient operation; shutdown operation; startup operation; selected operation descriptions, such as vocational operation, power take-off (PTO) operation, charging operation, cruise control operation, autonomous vehicle operation, etc.). The adjustment of communication can be qualitative (e.g., allowing or disallowing certain communication types, certain communication priority thresholds, etc. during certain operating conditions; and / or capturing certain data values ​​as data capture events during certain operating conditions), quantitative (e.g., controlling communication rates, network zone utilization, external device communication rates, etc.), or a combination thereof (e.g., controlling communication rates for certain communication types, etc.), and can include increasing or decreasing communication capabilities based on the operating condition and / or communication type (e.g., providing reduced device communication capabilities during shutdown operations, but increasing external device communication capabilities during shutdown operations; increasing device communication capabilities for certain devices or flows, but decreasing device communication capabilities for other devices or flows during startup operations, etc.);

[0144] · Additionally or alternatively, operation of the example CND includes: adjusting operation of any one or more of the above items in response to non-nominal operating conditions associated with the mobile application, wherein the non-nominal operating conditions include conditions such as: degradation of a network zone (e.g., loss of throughput, loss of communication with one or more endpoints of the network zone, injection or presence of noise onto the network zone, injection of traffic onto the network zone, physical failure of at least a portion of the network zone, etc.); failure conditions of one or more devices (e.g., wherein the CND adjusts a data source associated with the failed device, adjusts a data rate associated with the failed device, implements a backup data source for the failed device, reroutes data to a backup data recipient for data provided to the failed device, implements an event-driven data collection scheme in which failure of the device is an event, etc.); loss of control functionality of a vehicle controller (e.g., wherein the loss of control functionality indicates that the vehicle controller is lacking data values ​​to perform its mission; wherein the loss of control functionality indicates that the vehicle controller has lost communication with the associated network zone; and / or wherein the loss of control functionality 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 of its mission). Further example operations of the CND in response to non-nominal conditions include one or more of the following:

[0145] o Providing the data value to the vehicle controller from an alternate source (e.g., from a different endpoint, network zone, etc., and which may include packaging, configuring, processing, and / or upsampling or downsampling the alternate source communication, which may result in communication that is identical to the lost original data value or may be sufficient as an alternative communication of the backup data value to the vehicle controller);

[0146] o providing a data value to a second vehicle controller to replace all or part of a lost control function of the vehicle controller, e.g., where the second vehicle controller is configured to act as a backup for the vehicle controller, where the second vehicle controller may be fully capable of performing the lost control function and / or may be capable of performing backup operations in place of the lost control function (e.g., utilizing a more limited capability); the data value provided to the second vehicle controller may be the same data value as the data value provided to the vehicle controller, a backup source communication (e.g., having a different data rate, resolution, units, precision, etc.), or another data value entirely (e.g., where the second vehicle controller utilizes a different data set to perform the fully capable or backup operations). Additionally or alternatively, the CND may be capable of providing data from any network zone to the vehicle controller and / or the second vehicle controller, which may itself be on any network zone;

[0147] o Suppressing communication of one or more data values ​​in response to a non-nominal condition, e.g., wherein a fault condition, loss of a device or endpoint, etc., indicates that the one or more data values ​​are not utilized; wherein the one or more data values ​​are of low priority in view of the non-nominal condition; and / or wherein the one or more data values ​​are indicated as invalid in view of the non-nominal condition (e.g., a sensor value from a sensor having a fault or failure condition);

[0148] o Transferring communications from a first network zone (e.g., a degraded network zone) to a second network zone, such as when an endpoint and / or device is reachable through more than one network zone (e.g., where the zones are logically separate but physically coupled, where more than one physical route is available between the relevant endpoints (e.g., reference Figure 15 ), and / or wherein a second vehicle controller and / or a second endpoint coupled to a second network zone is capable of performing operations (or portions thereof and / or backups thereof) of a first vehicle controller and / or a first endpoint coupled to a first network zone);

[0149] o Repeating the communication from the first network zone (e.g., the downgraded network zone) on the second network zone;

[0150] o Transferring an endpoint from a first network zone (e.g., a downgraded network zone) to a second network zone, e.g., where the transferred endpoint is physically coupled or coupleable to both the first network zone and the second network zone (e.g., where the separation between the network zones is a logical separation, and / or where the endpoint is reachable through more than one network zone, such as Figure 15 ), wherein the operation of the CND includes adjusting addressing, protocols, encapsulation operations and / or any other operations used to achieve the transfer of the endpoint, which may further include updating the location of the transferred endpoint with other devices / endpoints in the system or translating communications with other devices / endpoints in the system without notifying the transfer;

[0151] o A combination of these, such as transferring an endpoint from a first network zone to a second network zone, and transferring related communications to the second network zone and / or repeating related communications on the second network zone;

[0152] Regulating communications between endpoints of 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 monitoring devices, operator devices, cloud computing devices, and / or third-party applications), wherein regulation between endpoints of the first network zone and external devices includes any one or more of the above operations, and / or may further include: limiting communications based on non-nominal conditions of components of the system (e.g., endpoints, devices, flows, network zones, etc.); limiting communications based on operational conditions of mobile applications; limiting communications based on permissions and / or permissions of endpoints, associated flows, and / or external devices. or priority; limiting communications based on an aggregate data value (e.g., corresponding to an associated data service provider for the communication; corresponding to a group of endpoints; corresponding to an associated flow; and / or corresponding to an entity associated with any one or more of these), the aggregate data value being aggregated based on time (e.g., daily, weekly, monthly, etc.), operational status (e.g., journey, event, etc.), and / or wherein the data value includes one or more of a total data sent / received value, a data rate value, and / or a combination of these; and / or limiting communications based on an external data access type (e.g., cellular, WiFi, Bluetooth, hardware / port plug-in, etc.); and / or

[0153] Any one or more combinations of the above.

[0154] refer to Figure 2 , the example system includes a vehicle 202 having a first network 104, a second network 106, and a CND 108 between the networks 104, 106. The example system depicts the vehicle 202 being communicatively coupled to an external device 110 (with Figure 1 ) and / or communicatively coupled to a second external device 114. Figure 2The example depicts another external device 204, which in this example is communicatively coupled to the vehicle 202 via the cloud connection 112. The third external device 204 is schematically depicted as a laptop, for example, as operated by a fleet service manager, owner, and / or vehicle representative (e.g., a claims specialist). Figure 2 The examples are illustrative depictions to illustrate additional contextual options and specific applications as a vehicle, but are otherwise similar to Figure 1 system.

[0155] refer to Figure 3 , schematically depicts an example embodiment including a vehicle 202, illustrating some further details that may be present in certain embodiments. The example system includes the vehicle 202 having a first network 104 and a second network, and a CND 108 interposed between the first network 104 and the second network. Figure 3 In the example of , the second network is an Ethernet network having devices (eg, interactive dashboard 302, door actuator 310, and transmission controller 320) coupled to Ethernet switch 312. Figure 3 In the example of FIG, a third network 318 is shown with the fuel tank sensor 306 coupled to the CND 108. In the example, the third network 318 can be of the same type as one of the other networks, for example, isolated from the other networks to improve installation, risk management, or cost for other considerations, and / or the third network can be of a different type to support devices—for example, sensors operating on a LIN network. The third network 318 can communicate with the CEG 314, the Ethernet switch 312, or another device (not shown) of the CND 108.

[0156] Figure 3 Examples include a first device 314 on a first network 104 (e.g., Figure 3 In the example, for the controller of the prime mover) and multiple devices on the second network (e.g., Figure 3 , interactive dashboard 302, fuel tank sensor 306, and door actuator 310). The system includes one of the devices 302, 310, 320 on the second network communicating with the first device 314 via CND 108. For example, when the vehicle 202 is moving, the door actuator 310 can lock the doors, thereby pulling vehicle movement information (e.g., engine speed, gear, vehicle speed, and / or status parameters such as a "VEHICLE MOVING" Boolean value, bit mask, etc.) from the first device 314.

[0157] Figure 3The arrangement 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, e.g., a controller of prime mover 308 may provide a number of parameters to first network 104, the multiple endpoints may each be provided with an identifier and operated as separate endpoints (e.g., engine temperature from an engine temperature sensor), and / or may include parameters provided as such by the prime mover 308 controller (e.g., engine temperature from an engine controller).

[0158] For illustration Figure 3 In an example of a first network 104, the first network 104 may be a CAN bus network, wherein the desired data (e.g., vehicle movement indicator) is provided as a CAN message according to the considerations for the CAN network. The door actuator 310 is provided on a second network (e.g., an Ethernet network), wherein 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., a port of an Ethernet switch 312 dedicated to the door actuator 310) or a virtual port (e.g., an address location for the second network, which may be on a physical port shared with one or more other devices). Figure 3 In the example of , the door actuator 310 is unable to receive CAN messages indicating vehicle movement, and the CND 108 interprets the request from the door actuator 310 for vehicle movement indication, retrieves the message from the first network 104, and sends the message to the door actuator 310 on the second network.

[0159] The operations performed to send the message can vary depending on the application. For example, CND 108 can publish certain parameters available from the first network (and / or third network 318) to devices on the second network and provide the selected parameters directly to the device (e.g., providing a vehicle movement indicator to the requesting device), or publish data values ​​representing the parameters (e.g., utilizing a proxy (not shown) to make the subscribed parameters available), and those parameters are available to devices that subscribe to those parameters. In some embodiments, CND 108 can limit the publication of parameters to devices, endpoints, applications, and / or flows that are authorized to see those parameters available. In other words, different devices on the second network may see different lists of parameters available depending on the authorization of those devices and / or the applications or flows associated with those devices. In some embodiments, CND 108 can limit the provision of parameters to devices, endpoints, applications, and / or flows that are authorized to receive those parameters - for example, by rejecting subscription requests for the parameters and / or suppressing the sending of parameters to unauthorized devices despite subscription. Accordingly, in some embodiments, a device may be able to see that a parameter is available (e.g., in a published list of available parameters), but may not be able to receive the data value of the parameter. In some embodiments, a device may be restricted from seeing the available parameters that the device is authorized to receive.

[0160] In some embodiments, a device may have only limited availability for receiving parameters, e.g., CND 108 may limit the rate of data values ​​to support reduced network utilization, data security considerations (e.g., limiting the accuracy, resolution, and / or data rate of sensitive parameters such as vehicle location), and / or to support proprietary considerations (e.g., limiting the accuracy, resolution, and / or data rate of parameters that may be relevant to proprietary control operations, e.g., to limit the ability of application engineers to completely transform or otherwise determine how control operations operate).

[0161] In some embodiments, CND 108 determines which parameters to publish, provide, and the conditions under which they are provided based on stored data that defines permissions and / or capabilities of devices, endpoints, applications, flows, etc. In some embodiments, CND 108 further defines stored data for processing or adjusting operations on data (e.g., encapsulation operations (e.g., to pass CAN messages to an Ethernet network), unit conversion, timestamp definitions, etc.). In some embodiments, 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 some embodiments, CND 108 can support prioritization of data flows based on prioritization of related devices, endpoints, applications, flows, or other parameters, including the rate at which devices provide or receive information. In certain embodiments, the CND 108 may support differential prioritization based on vehicle state or operating conditions (e.g., 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 may respond to any defined vehicle condition, such as charging, regeneration, aftertreatment operation, control regime (e.g., cruise versus operator control), emergency conditions, fault conditions, service conditions, and the like.

[0162] Figure 3 The example CND 108 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 some embodiments, the first device 314 converts communications destined for the second network into (e.g., encapsulates the communications, portions of the frames of the communications, and / or the payload of the communications into) messages destined for the second network. In some embodiments, the first device 314 is capable of requesting communications from devices on the first network 104, for example, requesting parameters that are available but not currently being transmitted to the first network 104. In some embodiments, the first device 314 is not part of the CND 108, but is controlled by the CND 108, for example, by responding to commands from the CND 108, accessing stored data written in whole or in part by the CND 108, or by other operations as provided throughout this disclosure.

[0163] Figure 3The example CND 18 includes a second device 312 that communicates with the second network. The example second device 312 includes a configurable Ethernet switch that reads communications from the second network. In some embodiments, the second device 312 receives messages from the first network 104 via the first device 314, for example, in a format transmittable on the second network. The example first device 314 includes a CEG that communicates with the Ethernet switch via a port on the Ethernet switch that is provided for messages from the first device 314. Accordingly, Figure 3 An illustration of a second device 312 on a second network communicating with a first device 314 via the CND 108 is provided.

[0164] The example system includes external devices 110, 114, 204 in communication with CND 108. Figure 3 In the example of FIG, the external device 110, 114, 204 can communicate through the transceiver 304 and / or via direct access to the network of the vehicle 202 (e.g., using a service port, an OBD port, WiFi, Bluetooth, etc.). The external device is structured to adjust the configuration of the CND 108 - for example, by changing the stored data providing published available data, associated permissions, defined applications, defined flows, defined endpoints, defined devices, etc. In some embodiments, the external device has an associated permission value, and the CND 108 permits changes based on the associated permission value, such as preventing adjustments to changes associated with certain networks, devices, endpoints, applications, flows, etc.

[0165] The example system includes a first network as a bus network, which can further be a CAN bus network. The example system includes a second network as an Ethernet network, which can have any selected topology, such as a data bus architecture. In some embodiments, the Ethernet network can have a data bus architecture as a hardware topology, but logically operate differently (e.g., as a switched network).

[0166] refer to Figure 4 , the example system includes CND 108 having a first network gateway device 404 and a second network gateway device 402. Figure 4 In the example, the first network gateway device 404 is: a CEG that accesses one or more CAN-based networks 406, each having one or more endpoints 408 - for example, devices coupled to the CAN networks 406 that provide communications to the corresponding CAN networks 406 and / or receive communications from the corresponding CAN networks 406. Figure 4The example depicts two CAN networks 406, which can be arranged to facilitate integration (e.g., to logically divide components of a vehicle by function, by location in the vehicle, and / or any other arrangement, such as groups of related components communicating on a common CAN network 406). In the example, the first network gateway device 404 communicates with both CAN networks 406, although the CND 108 may include and / or may be configured to accommodate more than one CEG, e.g., using a CEG to access each CAN network 406 and / or each CEG to access a subset of the CAN networks 406 on the vehicle. Figure 4 The example of FIG. 4 depicts a bus network 406, and for purposes of illustration, the network 406 is described as a CAN network, but the network 406 can be any type of network as described throughout this disclosure. The endpoint 408 can be any type of endpoint capable of communicating with the network 406 (such as a controller, smart sensor, or actuator) or other device capable of providing communications to and / or receiving communications from the network 406.

[0167] Figure 4 The examples describe CND 108 as including network gateway devices 402, 404, but CND 108 may be separate from one or more of the network gateway devices 402, 404 and may configure the operation of the network gateway devices 402, 402, such as by adjusting stored data thereon, adjusting stored data accessible to the devices 402, 404, providing commands thereto, and / or performing any other operations as set forth throughout this disclosure.

[0168] exist Figure 4In the example of , the second network gateway device 402 is an Ethernet switch that accesses an Ethernet-based network 410, schematically depicted as a plurality of endpoints 412 communicating with a plurality of ports 414 of the Ethernet switch 402. The ports 414 are schematically depicted and can be logical ports, hardware ports, or a combination of these. The physical topology of the Ethernet network 410 can be a bus arrangement, a hub arrangement, a star arrangement, or any other type of network topology, and it can be different from the logical topology of the Ethernet network 410. The second network gateway device 402 is depicted as having a network interface 416, which can include physical port connections. In some embodiments, the second network gateway device 402 is a configurable Ethernet switch that can include a processor, computer-readable storage (e.g., for storing instructions, configuration information, buffers for data communication and / or collection operations, etc.). For clarity of illustration and disclosure, these aspects are not shown, but they may reside on the second network gateway device 402, within the same housing as the second network gateway device, on a board separate from the network interface 416 and / or from the rest of the second network gateway device 402 (e.g., mounted on a separate printed circuit board), located on another device in the system and in communication with the second network gateway device 402 (e.g., on the first network gateway device 404, on a vehicle controller, and / or on another controller in the system), and / or distributed across a combination of these locations.

[0169] exist Figure 4 In the example of FIG4 , the first network gateway device 404 includes one or more network interfaces 418 (and / or network interface circuitry) that communicatively couple the first network gateway device 404 to the network 406, and translation circuitry 420 that configures messages from the Ethernet network 410 for transmission to the network 406 and / or configures messages from the network 406 for transmission to the Ethernet network 410. Additionally or alternatively, the translation circuitry 420 configures messages for delivery from one of the networks 406 to another of the networks 406—for example, where the networks 406 are of different types, utilize different protocols, would otherwise have conflicting source or destination information, and / or would otherwise have different characteristics that are managed by the first network gateway device 404 to ensure message compatibility, successful mission operation of the vehicle, and / or to achieve any other configuration operations as set forth in this disclosure. The conversion circuitry 420 is schematically depicted as a single device, but may be implemented as one or more devices, for example where multiple conversion circuitry 420 components each implement one type of configuration, interact with one type of network 406, distribute the processing and / or memory operations of the conversion circuitry 420, or for any other reason depending on the particular system. Figure 4In the example of , the first network gateway device 404 provides a message to the Ethernet switch in response to a corresponding message on the CAN-based network 406. Figure 4 In the example of , the first network gateway device 404 provides the message to the port 414 of the Ethernet switch. Figure 4 In the example shown, any messages provided from network 406 appear on Ethernet network 410 as messages on a port between translation circuitry 420 and network interface 416, and are received from Ethernet network 410 via a port between translation circuitry 420 and network interface 416. Translation circuitry 420 allows for configuration operations between messages between which endpoints on each network 406, 410 can communicate, as mediated by CND 108.

[0170] Figure 4 The example further includes an on-board diagnostic (OBD) interface 422, which in the example communicates with a dedicated OBD port 424. For purposes of illustration, Figure 4 The examples are non-limiting, and the OBD interface 422 can be associated with any network or more than one network (e.g., to support multiple OBD tools that can be received by a vehicle). Example embodiments include an OBD interface 422 associated with a second network gateway device 402, such as where the OBD system is largely CAN-based, thereby allowing for reduced traffic between the translation circuit 420 and the network interface 416 due to many OBD parameters being native to one or more of the CAN networks 406. The OBD interface 422 can alternatively reside on an Ethernet network 410 or on more than one network 406, 410 of the system. Regardless of the location of the OBD interface 422 and the networks 406, 410, the origin of the OBD-related data, 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) via operation of the CND 108 to authorize and provide cross-network communication from endpoints of either of the networks 406, 410. Additionally, Figure 4 The example utilizes the OBD interface 422 as a non-limiting example, but subject to configurable adjustments by the CND 108, any type of special, dedicated and / or proprietary interface may be provided in a manner similar to the interfaces and ports that may make any data from any endpoint on the networks 406, 410 available.

[0171] The example system includes a CND 108 interposed between an electrical sensor and one of networks 406 and 410 and configured to provide a sensed value on the network in response to an electrical response of the electrical sensor. For example, one of the networks 406 may be an electrical connection to a second network gateway device 402 having a corresponding endpoint 408 as an electrical sensor, and whereby a conversion circuit 420 converts an electrical signal from the sensor into communication for a corresponding network (e.g., network 410 or another network 406). In an example, the conversion circuit 420 may perform processing operations on the electrical signal, such as analog / digital (A / D) processing, determination of an indicated bit, determination of an indicated value, debouncing the signal, filtering the signal, diagnostic bit detection (e.g., determination of a fault and conversion to a corresponding fault value and / or conversion of a predetermined voltage value to a corresponding fault value), saturation management (e.g., limiting an output to a predetermined value), slew limiting (e.g., applying a rate of change limit to the indicated value), and the like. The electrical signal from the sensor, where present, may be a voltage value, a frequency value, an indicated resistance value, or any other type of sensor electrical value as known in the art.

[0172] In another example, a system includes a CND 108 interposed between an electrical actuator and one of the networks 406 and 410 and configured to provide a command value from the network as a configured electrical response to the electrical actuator. For example, one of the networks 406 may be an electrical connection to a second network gateway device 402 having a corresponding endpoint 408 as an electrical actuator, and whereby a conversion circuit 420 converts communications from the corresponding network (e.g., network 410 or another network 406) into an electrical signal for the actuator. In an example, the conversion circuit 420 may perform processing operations on the electrical signal, such as digital-to-analog processing, determination of a corresponding value from an indicated bit, provision of a diagnostic bit, saturation management, slew limiting, and the like. The electrical signal to the actuator (if present) may be a voltage value, a frequency value, a modulated value, or any other type of actuator electrical value as known in the art. In some embodiments, the electrical actuator may additionally have sensed values ​​(e.g., position feedback, acknowledgement, etc.) and / or other feedback values ​​(e.g., certain electrical values ​​indicating that the actuator has a fault condition, is non-responsive, is stuck, is saturated, etc.) that may be provided on the same or different electrical connections, and which may be logically part of the same network 406 or different networks (e.g., actuation on one network 406 and feedback on a second network 406).

[0173] It can be seen that in cases where an endpoint does not require knowledge about how communications to other endpoints are to be performed or where other endpoints are located, Figure 4 The embodiment provides communication between endpoints on different networks. Without limitation to any other aspects of the present disclosure, Figure 4 Embodiments of the present invention provide the capability to operate a vehicle network having devices distributed across different networks, including networks of different types. Additionally, Figure 4 Embodiments provide for operation of a vehicle as a device moves between networks, regardless of whether the device has changed communications capabilities. For example, a first device on a CAN network that is moved to an Ethernet network can continue to operate utilizing an appropriate configuration of CND 108, as messages utilized by devices from a CAN network can be moved to an Ethernet network and made available to devices in the new location. In certain embodiments, the migrated device can continue to utilize a previous algorithm (e.g., the same local control) - for example, computer-readable instructions specifically constructed for the details of the previous CAN message, including bit depth, resolution information, message rate, floating / fixed point data properties, etc., wherein CND 108 is configured to encapsulate the entire original CAN message into an Ethernet message (e.g., frames, packets, and / or in a specified manner) so that the migrated device can receive the previous CAN message as originally presented and utilized by the same local control. Accordingly, Figure 4 Examples and Figure 4 The principles set forth allow changes in the mix of endpoint devices between networks, whether across multiple vehicles (e.g., changes that occur during a design revision, model year, etc.) or within the same vehicle (e.g., changes that occur during service, upgrades or changes to endpoints, upgrades, fittings, recall replacements, etc.), with only updates to the CND 108 being required to support the changes. In certain embodiments, Figure 4 Examples and Figure 4 The principles set forth allow for changes in the mix of endpoint devices between networks without requiring an update to the configuration of CND 108, such as where a range of endpoints are considered available in more than one possible network location and / or configuration and where CND 108 is configured to determine the arrangement of endpoints present on a vehicle and utilize a selected configuration accordingly (e.g., from among two or more available configurations). Figure 4 Examples and Figure 4 The principles set forth further allow for changes to the mix of endpoint devices between networks, at least within a predetermined range of endpoint devices and configurations, to support vehicle operation without any changes to the vehicle and even with only intermittent or no communication with external devices for the configuration of CND 108.

[0174] refer to Figure 5, an example system includes: a CND 108 that regulates communications between networks on a vehicle, where the networks may be physically, logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme), and / or two or more of the networks may be of different types. Figure 5 The embodiments are generally Figure 4 The present disclosure is consistent with the embodiments of the present disclosure, with some differences being depicted to highlight certain aspects of the present disclosure. Figure 5 Examples include: additional interfaces 504 , 506 , which may be separate networks or network zones relative to network 406 . Figure 5 The example depicts a vehicle control device interface (VCDI) 508, which can be an interface to any type of vehicle controller (e.g., an engine controller, a transmission controller, an anti-lock braking system (ABS), an advanced driver assistance system (ADAS) controller, a door controller, a battery controller, a head unit, an interactive instrument panel, etc.), including a controller that provides communications at endpoint 504 and / or an electrical interface such as to sensors, actuators, or a combination of sensors and actuators. Figure 5 The example depicts an additional interface 506 towards endpoint 502, which may be any type of communication device as understood in the art or as described herein. Figure 5 In the embodiment of FIG, network interface circuits 418, 416 are depicted between endpoints 408, 502 and translation circuit 420 to allow translation circuit 420 to interface with many types of networks that may be present on a vehicle. Interface circuits 418, 416 may be located with translation circuit 420 or located elsewhere and communicatively coupled to the associated network and translation circuit 420. Figure 5The example further depicts networks 512, 514, which are communicatively coupled to the first network gateway device 404 via endpoint 412 on the same network as the network interface 416. In some embodiments, the CND 108 does not have or require specific knowledge of the networks 512, 514 or the associated endpoints 516, 518, as communication to the networks 512, 514 is provided via endpoint 412. However, the CND 108 is structured to provide communications from networks in communication with the second network gateway device 402 (such as network 406) and / or networks interfaced at endpoints 504, 506. Communications from the second network gateway device 402 may provide the requested information (e.g., ambient temperature, door position, vehicle speed), for example, as an encapsulated payload providing the information or as a native message (e.g., a CAN message indicating ambient temperature, door position, vehicle speed; and / or a LIN message with associated sensor information). Accordingly, endpoints 516 , 518 may send and receive tunneled messages with network 406 (or other networks) in a shared format, or otherwise receive information from any network onboard the vehicle, subject to mediation by CND 108 .

[0175] refer to Figure 6 , an example system includes: a CND 108 that regulates communications between networks on a vehicle, where the networks may be physically, logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme), and / or two or more of the networks may be of different types. Figure 6 The embodiments are generally Figure 4 The embodiments of the present invention are consistent with those of the present invention, with some differences being depicted to highlight certain aspects of the present disclosure. Figure 4 Any flexibility in the arrangements depicted, Figure 6 The example of FIG. 4 depicts translation circuitry 420 located in first network gateway device 404 .

[0176] Without limiting any other aspects of the present disclosure, Figure 6Co-location as depicted in and utilized herein may indicate physical co-location (e.g., translation circuitry 420 located within a shared housing with first network gateway device 404 and / or on the same board as first network gateway device 404) and / or logical co-location (e.g., grouping of operational responsibilities of hardware, such as connections, connectivity, operational instructions, stored data, data storage, and / or processing resources, etc.). Determining a co-location scheme depends on: the purpose of co-location (e.g., sharing hardware resources, reducing external interfaces, simplifying and / or diversifying the risk profile of the co-located component and / or other components in the system associated with the co-located component); the nature of the co-located component (e.g., hardware implementation, processing, and / or memory resources associated with the co-located component); the division of ownership of the co-located component (e.g., manufacturer, supplier, service provider, vehicle owner, vehicle operator); operational responsibilities of the component and / or vehicle (e.g., warranty, operational liability, service, insurance, uptime responsibility, etc.); and / or integration responsibilities of the component (e.g., installation, design, meeting floor space requirements, trade-offs between components, and / or the ability to influence these). Accordingly, in certain embodiments, co-locating components may include one or more of the following: locating components within a shared housing or housing group; locating components in selected geometric proximity; locating components in a selected logical arrangement (e.g., associated in the same flow or flow group, associated in the same application or application group, providing operational constraints such as parameter naming, memory assignment, execution order, etc.); locating components in a selected risk profile arrangement (e.g., located in the same impact zone, same temperature environment, same NVH environment, same EMI environment, subject to the same failure mode (e.g., electrical, logical, fault, physical impact and / or dependent on physical components such as pumps, cooling systems, etc.)); on the same board; and / or within a shared memory location (e.g., computer readable instructions located in a shared memory location and / or executed by the same processor resources). In the example, NVH is a "noise, vibration and harshness" environment, and EMI is an "electromagnetic interference" environment. One skilled in the art, having the benefit of this disclosure and information generally available when considering a particular system, can readily determine the implementation of co-located components as set forth in this disclosure. It will be appreciated that components arranged in one or more of the described co-location schemes may be co-located for some embodiments or not co-located for other embodiments, and / or may be co-located for purposes of some operating conditions but not co-located for purposes of other operating conditions.Certain considerations used to determine whether components are to be co-located and the co-location scheme selected for those components include (but are not limited to): the purpose of the co-location; the operating cost of the resources (e.g., communications, processing resources, operational limitations on the vehicle mission, operational impacts on the vehicle mission such as cooling requirements, power consumption, etc.); the capital cost of the resources (e.g., computing power, network infrastructure, memory resources, individual component quality or capability requirements, shielding requirements, data throughput whether inside or outside the vehicle, etc.); the integration cost for the components (e.g., floor space availability and cost, interface management, design flexibility and action limitation trajectory, and / or the ability to trade off and / or optimize with other aspects of the system); and / or the ability to distribute costs to other interested parties associated with the system (e.g., suppliers, manufacturers, customers and or service providers; and which may include the ability to distribute increased costs associated with increased capabilities and / or transaction costs between interested parties).

[0177] exist Figure 6 In the example of , translation circuitry 420 may provide communication by, without limitation, populating and / or reading from shared memory using network interface 416 and / or by communicating with port 414 (not shown).

[0178] refer to Figure 7 , an example system includes: a CND 108 that regulates communications between networks on a vehicle, where the networks may be physically, logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme), and / or two or more of the networks may be of different types. Figure 7 The embodiments are generally Figure 4 The embodiments of the present invention are consistent with those of the present invention, with some differences being depicted to highlight certain aspects of the present disclosure. Figure 4 Any flexibility in the arrangements depicted, Figure 7 The example depicts translation circuitry 420 having a first portion 702 co-located with second network gateway device 402 and a second portion 704 co-located with first network gateway device 404. Portions 702, 704 of translation circuitry 420 may be separated for any reason, including at least separating translation operations by network (e.g., which network 406 is being served), by predetermined endpoints, by stream, by translation operations (e.g., processing of frame information, processing of payload information, managing capability differences through downsampling, upsampling, buffering, providing communication commands, encapsulating messages into another message format, etc.), and / or by communication direction (e.g., between selected networks, between gateway devices, between endpoints, between streams, or a combination thereof).

[0179] refer to Figure 8, an example system includes: a CND 108 that regulates communications between networks on a vehicle, where the networks may be physically, logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme), and / or two or more of the networks may be of different types. Figure 8 The embodiments are generally Figure 4 The embodiments of the present invention are consistent with those of the present invention, with some differences being depicted to highlight certain aspects of the present disclosure. Figure 8 In the example of , the first network gateway device and the second network gateway device are co-located and omitted as being depicted as part of CND 108. In some embodiments, Figure 8 CND 108 may alternatively be a combined gateway device regulated by CND 108 rather than forming part of CND 108. In some embodiments, one or more portions of the combined gateway device may form part of CND 108, with other portions of the combined gateway device being regulated by CND 108.

[0180] As utilized herein and without limitation to any other aspects of the present disclosure, a policy includes a description of the data to be collected, such as data parameters, collection rates, resolution information, priority values ​​(e.g., to sort data collection values ​​for selection in response to non-nominal conditions where not all data collection parameters can be serviced, etc.). In certain embodiments, a policy further includes event information, which can be specified as parameter or quantity-based events (e.g., a given data value exceeds a threshold, etc.) and / or categorized events (e.g., a particular fault code, operating condition or state, or vehicle location / jurisdiction occurs). In certain embodiments, a policy further includes event responses (e.g., data values ​​to be captured in response to the occurrence of an event) and / or other changes in the data collection scheme (e.g., an increased or decreased data collection rate, a change in the resolution collected, etc.). In some embodiments, the event response further includes a time frame associated with the occurrence of the event, for example, a time period after the event occurs to utilize the modified data collection scheme and / or a time period prior to the event occurs (e.g., utilizing a rolling buffer or other data collection operation to provide temporary information that can be captured later in the event). In some embodiments, changes to the data collection scheme for an event can include multiple changes - for example, changes over a period of time, further changes based on the progression of the event (e.g., if the severity of the event becomes worse), and / or criteria for determining that the event is cleared. In some embodiments, changes to the data collection scheme can be implemented based on event-related clearing of the same or another event, for example, implementing data collection changes until the next downtime event of the vehicle, until a service technician clears the event, due to a selected number of downtime events, etc. The strategy may additionally or alternatively include parameters for performing any adjustment operation for any adjusted component as set forth throughout this disclosure.

[0181] The utilization of policies herein may reference a partial policy, e.g., an implied policy to be implemented in response to a single data collection scenario from a single user, where the full policy is prepared, verified, and transmitted to the vehicle after one or more partial policies are aggregated. The utilization of policies herein may reference an unverified policy, e.g., after policies in response to multiple users are aggregated, but a verification operation for the policy has not yet been completed (e.g., before determining whether the data collection implied by the policy can be performed). The utilization of policies herein may reference a previously applied policy (e.g., a policy that existed on the vehicle before an updated version of the policy was transmitted to the vehicle and / or implemented on the vehicle). The utilization of policies herein may reference an updated policy, e.g., a verified policy that is pending for communication to the vehicle and / or confirmed by the vehicle (e.g., from CND 108).

[0182] refer to Figure 9, an example system includes: a CND 108 that regulates communications between networks on a vehicle, where the networks may be physically, logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme), and / or two or more of the networks may be of different types. Figure 9 The embodiments are generally Figure 4 The embodiments of the present invention are consistent with those of the present invention, with some differences being depicted to highlight certain aspects of the present disclosure. Figure 9 In the example of , the first network gateway device 404 and the second network gateway device 402 are not co-located, and the CND 108 is depicted as communicating with the first network gateway device 404. The CND 108 can communicate with any one or more of the network gateway devices and / or can be located at least partially on one or more of the network gateway devices. Additionally or alternatively, the CND 108 can regulate communications between networks by accessing and / or adjusting memory locations available to one or more of the network gateway devices (e.g., policies, configuration instructions, configurable tables, etc.), where if the CND 108 does not communicate directly with the other network gateway devices, the relevant portions of the instructions (if any) can be passed to those devices. In some embodiments (not shown), the CND 108 can communicate with one or more of the network gateway devices using one or more of the networks (e.g., at port 414 of the first network gateway device 404). In some 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) in components (e.g., conversion circuitry and / or network interface circuitry) of one or more of the network gateway devices.

[0183] refer to Figure 10 , depicting an example first network gateway device 404. Figure 10 In the example of , the first network gateway device 404 is a configurable Ethernet switch that includes an Ethernet network interface 416 (or Ethernet network interface circuit) having a plurality of ports 414 for communicating with an Ethernet network. The ports 414 can be physical ports, logical ports, or a combination thereof.

[0184] refer to Figure 11 , depicts an example second network gateway device 402. Figure 11In the example of , 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 references to the secondary and primary of the networks merely indicates a logical arrangement of the networks, where interfaces facing networks other than the primary are referenced as edge interfaces (e.g., interfacing with an edge gateway). In some embodiments, the primary network may have higher capabilities (e.g., bandwidth, throughput, and / or resource dedication), a larger number of devices or endpoints on it, a migration target network for endpoints over time (e.g., within the life of a vehicle, a group of vehicles, a model year, 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. Figure 11 The example of depicts an optional OBD interface 422 , which may be present elsewhere in the system or not present in the system.

[0185] refer to Figure 12 , schematically depicts a vehicle having multiple networks thereon, wherein communication between the networks is mediated by CND 108 . Figure 12 The arrangements are provided to illustrate certain aspects of the present disclosure and are non-limiting arrangements. Figure 12 Examples include endpoints 1202, 1204 coupled to a first network 406 (e.g., one or more vehicle controllers) and a plurality of endpoints 1206, 1208, 1210, 1212 coupled to a second network (e.g., an Ethernet network with a switch co-located with and / or at least partially separated from the CND 108). Figure 12 In the example of FIG100 , controllers 1202, 1204, 1206, 1208, 1210, 1212 are capable of passing communications between disparate networks of a vehicle, as mediated by CND 108. In certain embodiments, a given controller can be switched between networks, and communications with other controllers within the vehicle and / or communications external to the vehicle can be maintained, and further can be maintained regardless of whether the relevant controller (or external controller, application, or device) has knowledge of the switch.

[0186] refer to Figure 13 , schematically depicts a vehicle having multiple networks thereon, wherein communication between the networks is mediated by CND 108. For purposes of illustration, Figure 13 Examples include Figure 12 The same network and controller set are shown in the example. Figure 13In the example of FIG. 1 , controllers 1204, 1208, 1210, and 1212 have been co-located 1302, and controller 1204 has additionally been moved from first network 406 to second network. Co-location 1302 of controllers 1204, 1208, 1210, 1212 can be implemented in any manner, including consolidating the controllers into a fewer number of housings (e.g., 1-3 total housings instead of 4), onto a fewer number of boards (e.g., 1-3 boards instead of 4), and / or utilizing at least partially shared computing resources (e.g., shared processing, shared memory, shared cache, and / or a combination thereof). In some embodiments, utilization of CND 108 allows Figure 13 An arrangement that includes integrating vehicle controllers by providing communication accommodation and maintained connectivity with only a configuration update to CND 108 and / or with changes to the integration of vehicle controllers within an available predetermined configuration of CND 108 (and thus can be achieved without an update to CND 108). Additionally, the integrated controllers can provide multiple advantages, such as a reduction in network costs, a reduction in network traffic, a selected risk profile (e.g., placement of controllers and / or network routing in lower risk or diversified risk locations; and / or a reduction in risk to another system component that takes advantage of the footprint gains and / or cost savings of controller integration). In certain embodiments, the integrated controllers can enable deeper sharing of information between controllers (e.g., due to increased available network capacity, bypassing network limitations with respect to shared controllers, and / or utilization of shared memory resources), which can allow for more capable operation of the controllers and / or operation that was previously unavailable because shared information between controllers was not as readily available. In certain embodiments, CND 108 further enables the consolidation of controllers by decoupling the locations of the controllers from the endpoint locations (not shown) where they are required to be distributed (e.g., sensors and actuators that need to be placed in certain locations to perform their functions no longer need to be located near the respective controllers due to the operation of CND 108 and / or CEG 402). In certain embodiments, the consolidation of controllers allows for reduced costs and / or increased capabilities, such as by reducing hardware costs for shared computing resources, enabling higher capacity (e.g., processing power and / or memory) computing resources, or a combination of these. The operation of CND 108 thus allows for the consolidation of previously unavailable vehicle controllers. In certain embodiments, Figure 13 An example of this could be relative to Figure 12 Illustration of controller integration and / or unrelated embodiments.

[0187] refer to Figure 14, schematically depicts a vehicle having multiple networks thereon, wherein communication between the networks is mediated by CND 108. For purposes of illustration, Figure 14 Examples include Figure 12 Example of the same network and similar controller collection. Figure 14 In the example of FIG, the co-located controller 1302 includes a set of controllers 1402, 1404, 1406 and a CND 108 depicted as controllers on the co-located controller 1302. The CND 108 may be at least partially located on one or more of the co-located controllers 1402, 1404, 1406 and / or may be separate as depicted. In some embodiments, Figure 14 An example of this could be relative to Figure 13 Further controller integration and / or with Figure 12 and 13 An example of an unrelated co-located controller 1302 is shown.

[0188] refer to Figure 15 , schematically depicts a vehicle having multiple networks thereon, wherein communication between the networks is mediated by CNDs 1502, 1504. For purposes of illustration, Figure 15 The example utilizes two integrated controllers 1302, 1506, each comprising a set of co-located vehicle controllers as set forth throughout this disclosure. Figure 15 Examples include a first CND 1502 (or CND portion) interposed between the first network 406 and the second network (endpoint 412 directly coupled to CND 1502 and integrated controller 1506 directly coupled to CND 1502), and a second CND 1502 (or CND portion) interposed between the first network 406 and the second network (endpoint 412 directly coupled to CND 1504 and integrated controller 1302 directly coupled to CND 1502). In some embodiments, the second network associated with the first CND 1502 may be a separate network relative to the second network associated with the second CND 1504, but may be the same type of network (e.g., an Ethernet network) and / or may utilize the same or electrically coupled hardware relative to each other. Figure 15 The example illustrates CND 1504 as having primary network regulation for the first network 406, but regulation of the first network 406 may be distributed, shared, regulated based on endpoints, applications, and / or flows, etc. In some embodiments, regulation of the second network may be performed by only one of CNDs 1502, 1504 and / or be distributed, shared, regulated based on endpoints, applications, and / or flows.

[0189] The following description Figure 15 of multiple representative aspects, any one or more of which may be present in certain embodiments. Figure 15 Example aspects include shared regulation of networks by CNDs 1502, 1504, where either CND 1502, 1504 is fully or partially capable of supporting regulation of all networks, for example, if an endpoint, a network, another CND (or portion), and / or a controller experiences a failure, malfunction, or decreased operational capability. Figure 15 Example aspects include primary regulation of the network by one of the CNDs 1502, 1504, with the other CND being able to fully or partially support regulation of the network, for example, if an endpoint, network, master CND, and / or controller experiences a failure, malfunction, or reduced operational capability. Figure 15Example aspects of the integrated controllers 1302, 1506 include one or more of the integrated controllers 1506, 1302 being able to at least partially assume control operations for another of the integrated controllers 1506, 1302 if one of the integrated controllers loses capability, connectivity with endpoints, etc. In some embodiments, the CNDs 1502, 1504 are able to pass along parameters that were previously available only to the original controller 1302, 1506 in response to control operations being assumed by the replacement controller 1506, 1302. In some embodiments, redundant network routing availability may be used by the CNDs 1502, 1504 to provide at least partial connectivity between endpoints that lose connectivity when a portion of the network fails. CNDs 1502, 1504 may provide equivalent parameters (e.g., another endpoint capable of providing equivalent data), alternative parameters (e.g., another endpoint capable of providing alternative or backup parameters that may be used, at least in part, as a substitute for a lost parameter), identical parameters (e.g., where data from the original endpoint or identical data values ​​from another endpoint may be routed through the remaining network infrastructure), and / or management parameters such as controller handoff communications, heartbeat or status communications, etc. In certain embodiments, one or both of CNDs 1502, 1504, or portions of a CND, may be co-located with another system component (e.g., one of the integrated controllers 1302, 1506). In certain embodiments, network routing for on-vehicle networks is provided to generate different risk profiles for on-vehicle networks, thereby reducing the risk of a single failure rendering the vehicle inoperable for the mission and / or inoperable for at least limp home operations, controlled shutdowns, data capture, etc. In certain embodiments, controllers, CNDs, and / or integrated controller locations may be selected to provide different risk profiles for associated equipment, thereby reducing the risk of a single failure rendering the vehicle inoperable for the mission and / or inoperable for at least limp home operation, controlled shutdown, data capture, etc. In certain embodiments, network routing for the on-vehicle network is provided to result in lower operating cost, installation cost, integration cost, overall risk profile, distribution of weight and / or footprint of components on the vehicle, etc.

[0190] Resolution of competing priority interests can be performed in any manner, such as: always favoring the highest priority requester; providing weighted responses based on priority (e.g., servicing high priority requests more often than lower priority requests); and / or utilizing a credit-based scheme that allows lower priority requests to be served after a period of time and / or multiple requests while favoring higher priority requests. Resolution of competing priority interests can include: meeting service performance requirements (e.g., QoS values) for higher priority requests; and servicing lower priority requests to the extent possible while meeting performance requirements for higher priority requests.

[0191] As used herein, the mission of a device (e.g., a controller, endpoint, vehicle, mobile application, etc.) should be broadly construed to include at least the relevant functionality, structure, capabilities, and operations of the device to support the operation of the mobile application to perform the intended functionality or primary functionality of the mobile application. Without limitation to any other aspect of the present disclosure, the intended functionality or primary functionality of the mobile application includes one or more of the following: motorized operation of the mobile application according to designed motorized capabilities (e.g., with specified torque, speed, responsiveness, etc.); and / or non-motorized operation of the mobile application (e.g., industrial operation, vocational operation, pumping operation, provision of shaft power, range of motion, and control thereof) with designed non-motorized capabilities. In certain embodiments, the intended functionality or primary functionality of the mobile application includes non-nominal operational responses that may be less capable than the designed motorized or non-motorized capabilities, such as operation in a limp home mode, communication of a fault or failure condition, and / or prevention of further degradation of the vehicle and / or mobile application. In certain embodiments, the intended functionality or primary functionality of the mobile application includes sending and / or receiving external data, performing update operations, facilitating service operations, facilitating update and / or upgrade operations, and the like. Accordingly, the mission of the device can vary between mobile applications based on the current operating conditions of the mobile application and / or based on the current state of the mobile application and / or components, devices, and / or their controllers. Those skilled in the art, having the benefit of this disclosure and generally available information when considering a specific mobile application, should readily understand the mission of a mobile application, the mission of the device of the mobile application, and the variability of these operating conditions and state conditions across mobile applications.

[0192] refer to Figure 16, an example system 1600 for providing off-vehicle communication control consistent with embodiments of the present disclosure is provided. The systems described throughout this disclosure can be provided on a mobile application such as a vehicle or as described throughout this disclosure. The example systems herein describe a specific arrangement of, for example, a converged network device (CND) 108, circuits, controllers, or other components. The arrangement is provided for clarity of the description, but the components may be distributed, combined, partitioned, and / or have a different relationship to those components depicted as forming a system and performing the processes described herein.

[0193] The circuits, controllers, processors, or other devices described herein are configured to functionally perform the operations described herein and may include computing components such as processors, memory, and / or communication components. Additionally or alternatively, such devices may include logic circuits, hardware configured to perform one or more functions of the device, sensors, actuators, and / or any type of display device. A given circuit, controller, processor, or other such device may be distributed and / or grouped with other such devices, in whole or in part.

[0194] 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 operation includes: 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.); retrieving a parameter value from a memory location accessible to an interpreting or receiving device; receiving a parameter value as a command; receiving a parameter value as a response to a request from a receiving or interpreting device; and / or receiving a precursor value from which a parameter is at least partially determined (e.g., operating a virtual sensor using other information to determine an interpreted or received parameter value; determining a state value based on the received information, where the state value is the received or interpreted value for the purposes of this description; and / or using the received information to infer the interpreted value). Any such operations may further include more than these (e.g., interpreting parameter values ​​in different manners at different times, operating conditions, during non-nominal conditions, depending on the source of the parameter value and / or depending on the use or purpose of the interpreted parameter value at a given time or during certain operating conditions) and / or combinations of these (e.g., operating a virtual sensor on the received information to determine a precursor value, and determining the interpreted parameter value in response to the precursor value).

[0195] The example system 1600 includes a vehicle 102 having a first network zone 1612 and a second network zone 1614, wherein the first network zone 1612 and the second network zone 1614 are different types of networks. Without limitation to any other aspect of the present disclosure, the different types of networks described herein take into account any differences in the 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 framing requirements; addressing scheme; acknowledgement type, requirements, or capabilities; broadcast availability, such as 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 the foregoing; and / or proprietary versions of any one or more of the foregoing). Example network regions include electrical signal regions (e.g., networks in which corresponding network interface circuitry interprets electrical signal values ​​as communications and / or provides electrical signal values ​​as communications to endpoints of the electrical signal region, such as sensors that provide certain electrical values ​​indicative of sensed parameter values, diagnostic values, and / or actuators that respond to certain electrical values ​​to move to a selected position and / or apply a selected force, and / or in which the actuators can additionally or alternatively provide feedback information and / or diagnostic information on the electrical signal region). The electrical signals for the electrical signal region can be of any type, including at least: voltage values; frequency values; current values; and / or configured pulse width modulation (PWM) values, such as duty cycle, amplitude, selected period, and / or the like.

[0196] 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 configures 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 may be provided by an external device 1618 and / or may be previously stored (e.g., at the time of manufacture, assembly, and / or during a previous update from the external device 1618), wherein the policy 1606 includes the network regulation description with selected indications of the device's capabilities for utilizing the network zones 1612, 1614, communicating between zones, and / or communicating with the external device 1618.

[0197] The example system 1600 includes a first network interface circuit 1608 provided as part of a CEG, wherein a first network zone 1612 is a CAN bus network; and a second network interface circuit 1610 provided as part of a CES, wherein a second network zone 1614 is provided as an Ethernet network. In the example, the first network interface circuit 1608 provides selected communications from the first network zone 1612 to the second network interface circuit 1610 at a selected port of the Ethernet network and / or receives selected communications from the second network zone 1614 at a selected port of the Ethernet network, thereby providing inter-network communication between the first network zone 1612 and the second network zone 1614. In an example, communication from the first network zone 1612 to the external device 1618 can be provided through the second network zone 1614 (e.g., where 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., where the external device 1618 is directly coupled to the first network zone 1612 or a CAN bus).

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

[0199] Devices on the vehicle 102 that are regulated by the policy include, but are not limited to, one or more of the following: endpoints in a network zone; flows associated with a communication device (e.g., an endpoint or application); and applications associated with a communication device (e.g., an endpoint). For example, an endpoint in the first network zone 1612 (e.g., a backup camera on the vehicle 102) may request or perform communications on the vehicle's network, but may be associated with more than one application or flow (e.g., associated with a first flow associated with a vehicle reverse motion operation at a first operating condition, and associated with a second flow associated with a vehicle safety operation at a second operating condition), and accordingly, communications for the backup camera on the vehicle 102 may have different regulation parameters depending on the flow associated with the current operation. In some embodiments, an endpoint is associated with more than one application or flow, and the endpoint is regulated based on the highest priority of the associated applications or flows (e.g., to reduce communication requirements, such as determining which application or flow is requesting immediate communication to be regulated, and / or to reduce processing time to determine which application or flow is requesting immediate communication). In some embodiments, an endpoint is associated with more than one application or flow, and the endpoint is regulated based on the priority of the application or flow requesting immediate communication.

[0200] Devices on vehicle 102 that are regulated by policy may be referred to herein as, without limitation, local communication devices. Local communication devices include, but are not limited to: endpoints of a network zone; 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 brake system (ABS) controller, advanced driver assistance system (ADAS) controller, etc.). It can be seen that a given component (e.g., an endpoint of a network zone) can be a first local communication device during one operating condition and a second local communication device during another operating condition—for example, depending on the vehicle operating condition (e.g., shutdown, maneuvering, parking, etc.), and / or can be a first local communication device for a first purpose (e.g., a brake controller performing an 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 operations). Furthermore, it can be seen that the distribution of communication devices among applications, flows, controllers, vehicle functions, etc. depends on the organizational policies of a particular system, design choices made by a manufacturer or other entity with control over the design and / or configuration of the system, and so forth. For example, traction control may be provided by a unified vehicle controller for a given system (e.g., which may treat traction control as a vehicle controller for network regulation purposes); provided by a distributed controller for another system (e.g., which may treat traction control as a vehicle function for network regulation purposes); and / or may be considered a logically grouped collection of operations for another system (e.g., which may have any hardware organization including the organization previously described, and which may treat traction control as an application or flow for network regulation purposes). An organizational scheme and network regulation for local communication devices of a system may be readily determined by one skilled in the art having the benefit of this disclosure and the information generally available when considering a particular system. The organizational scheme for local communication devices includes the inclusion and / or association of endpoints of a network zone and / or certain communications (including source or destination communications for an endpoint) with one or more of the following: specific endpoints of the system, vehicle controllers, vehicle functions, applications, and / or flows.

[0201] Certain considerations in determining the organizational scheme include, but are not limited to: the number, type, capabilities, and inter-connection bandwidth of the system's network zones; the available size and / or granularity of policies for the system; the available processing power available to implement the system's policies; the number and distribution of vehicle controllers and other controllers throughout the system; expected changes to the system over time (e.g., the availability of reconfigured, remanufactured, and / or re-engineered vehicles; expected changes in upcoming model years associated with vehicles; and / or the level of consumer and / or third-party customization of vehicles that are available or desired); the number and distribution of sensors and / or actuators throughout the system and the connectivity of the sensors and / or actuators to the network zones (e.g., integration and / or use of sensors at the controllers); integration of smart sensors / actuators capable of directly interfacing with the network zone); the presence, number, and distribution of multi-purpose communication elements on the system (e.g., sensors, actuators, controllers, and / or data values ​​that serve multiple vehicle functions, flows, and / or applications); the presence, number, and distribution of multi-purpose data elements on the system (e.g., sensors, actuators, controllers, and / or data values ​​that provide redundant capabilities to support a given vehicle function, flow, and / or application); and / or the expected utilization of network aspects (e.g., communications on the network zone, external communication bandwidth, external communication data limits, inter-network communications, etc.) relative to relevant capacities (e.g., bandwidth of the network zone, external communication bandwidth, external communication data limits, inter-network communications, etc.).

[0202] The example policy manager circuit 1602 receives policy communications 1616 from an external device 1618 and interprets the policy 1606 by performing operations such as storing the policy 1606 (e.g., in a memory location accessible to the policy filter circuit 1602 and / or distributed across multiple memory locations) and / or updating the stored policy 1606. In some embodiments, the policy manager circuit 1602 configures the policy 1606 for utilization by the network regulation aspect of the system 1600, for example, by updating a plurality of configuration files utilized by the interface circuits 1608, 1610, adjusting a high-level description of the policy communication 1616 by the network regulation aspect of the system 1600 (e.g., limiting external communication data to 32GB per month) to executable commands, adjusting reference values ​​of the policy communication 1616 (e.g., associating local address values ​​of endpoints referenced in the policy communication 1616, such as when an endpoint has been moved to an external device 1618 without notification, and / or where specific addressing information of the local device is abstracted from the external device 1618, etc.), associating system-specific nomenclature with elements of the policy description 1620 (e.g., local parameter value names or IDs, flow names or IDs, application names or IDs, etc.), and the like.

[0203] The example system 1600 includes an external device 1618 communicatively coupled to the policy manager circuit 1602 via at least one of the first network zone 1612 or the second network zone 1614—e.g., 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 the external device 1618 communicatively coupled to the policy manager circuit 1602 via a wireless connection, such as a WiFi connection, a cellular connection, and / or a Bluetooth connection.

[0204] The example system 1600 includes a policy manager circuit 1602 that validates a policy 1606 as communicated by a policy communication 1616 before executing storage and / or updating of the policy 1606. For example, the policy manager circuit 1602 may require authentication of an external device 1618 and / or determination of permissions associated with the external device 1618 before executing changes to the policy 1606. In some embodiments, the policy manager circuit 1602 may determine permissions associated with the external device 1618, an entity utilizing the external device 1618, an application or flow utilizing the external device 1618, etc., before executing changes to the policy 1606. In some embodiments, the policy manager circuit 1602 may reject the policy communication 1616 if the policy 1606 implied by the policy communication 1606 exceeds the rights associated with the external device 1618 and / or if the policy 1606 cannot be implemented (e.g., executing the policy 1606 would exceed the capabilities of the system 1600, such as the bandwidth of a network zone, external communication limits, memory storage limits, etc.). In some embodiments, if the policy 1606 implied by the policy communication exceeds the authority associated with the external device 1618, and / or if the policy 1606 cannot be fully implemented, the policy manager circuitry 1602 may partially implement the policy communication 1616. For example, the policy manager circuitry 1602 may implement the authorized portion of the policy communication 1616 and / or implement the portion of the policy communication 1616 that the system 1600 is capable of implementing. In some embodiments, the policy manager circuitry 1602 implements the portion of the policy communication 1616 (e.g., where the system capabilities will be fully implemented) based on: the priority of the associated endpoint, flow, application, vehicle function, etc. of the policy communication 1616 (e.g., implementing higher priority aspects until a limit is reached); and / or maximizing the implemented value of the policy communication 1616 (e.g., associating a value for each aspect based on the given aspect's associated priority, importance, merit description, etc.; e.g., where satisfying a set of slightly lower priority aspects of the policy will exceed the value of satisfying only a single higher priority aspect of the policy).

[0205] In response to validating policy 1606, the example policy manager circuitry 1602 provides a policy notification 1620 to the external device 1618. The example policy notification 1620 includes a confirmation that policy 1606 was updated and / or stored according to policy communication 1616. The example policy notification 1620 includes a notification that policy 1606 was not implemented (e.g., where the external device 1618 does not have authorization to implement policy communication 1616). The example policy notification 1620 includes a reason for rejecting policy communication 1616 (e.g., lack of authorization, lack of capability, etc.). The example policy notification 1620 includes one or more aspects of the partial implementation of policy communication 1616, e.g., a description of which aspects of policy communication 1616 were implemented or rejected and / or the reason for the partial implementation. In some embodiments, instead of and / or in addition to providing policy notification 1620 to the first external device 1618, the policy manager circuitry 1602 may provide policy notification 1620 to a separate external device (not shown). In some embodiments, the policy notifications 1620 to the separate external devices may include the same information or separate information. For example, the policy manager circuitry 1602 may provide a simple policy notification 1620 to the requesting external device 1618 (e.g., a rejection of the policy communication 1616) and provide a more detailed policy notification 1620 to the separate external device (e.g., indicating authorization to prevent implementation of the policy notification 1616, the ability to prevent implementation of the policy communication 1616, and / or details related to partial implementation of the policy communication 1616). In some embodiments, the policy manager circuitry 1602 may provide the more detailed policy communication 1616 to the requesting external device 1618 and provide the simpler policy communication 1616 to the separate external device.

[0206] In some embodiments, the policy notification 1620 may include providing a prompt to a user interface of an external device (not shown), e.g., allowing an authorized external device, user, entity, etc., to provide permission to allow the policy 1606 to be updated in response to the policy communication 1616. In a further example, the prompt to the user interface of the external device may include a prompt to one or more of a vehicle owner, a vehicle operator, a vehicle manufacturer, an administrator associated with the vehicle (e.g., a network administrator, a fleet owner, a fleet service operator, a compliance officer associated with the vehicle, etc.).

[0207] Without limitation to any other aspects of the present disclosure, example aspects of policy 1606 include: data collection parameters (e.g., data available to at least one network zone of the vehicle, such as data from any sensors, actuators, controllers, and / or endpoints that are at least selectively coupleable to the network zone and / or in communication with endpoints of the network zone); data collection permission values ​​(e.g., sampling or communication rate; permission to provide data values ​​to the network zone; permission to request data values ​​from the network zone; resolution values ​​associated with the data; time lag permissions associated with the data; storage permissions associated with the data (e.g., amount of authorized data storage); data expiration criteria, and aging data processing parameters (e.g., actions to be performed on aged data and / or actions to be performed on the permitted storage due to an inability to externally transmit the stored data); becomes limited or competing storage priorities interfere with the planned available storage); service publication permission values ​​(e.g., authorization to publish the availability of a service, which may include scheduled authorization to publish to some local communication devices, external applications, etc. but not to others; and / or authorization to publish details of available services (such as provided data parameters, available actuators, etc.)); service subscription permission values ​​(e.g., published services visible to associated local communication devices; service details 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, association parameters, allowed external addresses, allowed APNs, aggregated data communication permissions, etc.). Policy 1606 includes any one or more of the above items associated with local communication devices (e.g., endpoints, controllers, vehicle functions, flows, applications, etc.), external devices (e.g., specific devices or device classes, entities, and / or applications). In some embodiments, a given flow, application, or vehicle functionality may include aspects associated with a local communication device and other aspects associated with an external device (e.g., a route predictor application utilizing a local communication device in combination with an external application such as a cloud-based application or a web-based application).

[0208] refer to Figure 17, an example system 1700 for providing off-vehicle communication control consistent with embodiments of the present disclosure is provided. 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 between the first network zone 1612 and the second network zone 1614. CND 108 between network zones 1612, 1614 includes physical intervention (e.g., communication between network zones 1612, 1614 passes through CND 108 and / or passes through equipment controlled by CND 108, such as CEG, CES or other network interface circuits) and / or logical intervention (e.g., where communication between network zones 1612, 1614 passes through equipment controlled by CND 108, and / or where CND 108 regulates communication between network zones 1612, 1614, such as passed data values, configuration of data values, data rates, upsampling and / or downsampling of data, encapsulation operations, frame inclusion and / or processing of passed communications, etc.).

[0209] Example system 1700 further includes: policy manager circuitry 1602 that interprets policy 1606 including active diagnostic description 1705; and diagnostic execution circuitry 1702 that provides diagnostic command values ​​1712 to endpoints in network zones 1612, 1614 in response to active diagnostic description 1705. Example system 1700 includes endpoints in first network zone 1612 (endpoint 1708) and second network zone 1614 (endpoint 1710). In example system 1700, endpoints 1708, 1710 comprise devices responsive to diagnostic command values ​​1712. Example 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 vehicle functions (e.g., to provide engine speed, power level, or higher-level functions such as executing a regeneration mode, a scheduled test operation, etc.). The example system 1700 allows the execution of active diagnostic tests requested by an external device to be successfully performed regardless of the distribution of endpoints 1708, 1710 throughout the vehicle's network, including where endpoints have moved between networks and / or where a given diagnostic command value 1712 is utilized to provide active diagnostic tests across a range of vehicles having varying network configurations and distributions of endpoints 1708, 1710.

[0210] refer to Figure 18, example endpoint 1708 includes device control circuitry 1802 that interprets a diagnostic command value 1712 and provides an actuator command value 1804 in response to the diagnostic command value 1712. Example endpoint 1708 includes or is associated with an actuator 1806 that responds to the actuator command value 1804. For example, diagnostic command value 1712 may include commands such as "lock driver's door," "close exhaust gas recirculation valve," "raise motor temperature to 80°C," etc., thereby allowing for abstraction between diagnostic command value 1712 and actuator 1806 responses to implement diagnostic command value 1712. Additionally or alternatively, diagnostic command value 1712 may be associated with a complex operation or series of operations, such as a complete test sequence, and accordingly, numerous endpoints 1708, 1710, and / or actuators 1806 throughout system 1700 may be involved by a single diagnostic command value 1712.

[0211] The example system 1700 further includes a diagnostic execution circuit 1702 that determines whether a vehicle operating condition 1720 is consistent with the diagnostic command value 1712 before providing the diagnostic command value 1712 to the endpoints 1708 and 1710. For example, the diagnostic command value 1712 may include a diagnostic test that adjusts the torque delivery of the vehicle's prime mover, and the associated vehicle operating condition 1720 may include parameters such as: ensuring the vehicle is immobile; ensuring the vehicle is not in a motorized power mode; and / or ensuring the vehicle is in a selected test mode. In some embodiments, the vehicle operating condition 1720 for a given diagnostic command value 1712 may be described in the active diagnostic description 1705, thereby allowing active control of the vehicle operating condition 1720 for test performance (e.g., target temperature; diagnosing specific conditions such as vehicle launch, high altitude operation, etc.) and / or additional test considerations (e.g., operator or service personnel safety, fuel economy or emissions, impact on network communication rates, processing requirements and / or memory storage, etc.). In certain embodiments, the vehicle operating condition 1720 for a given diagnostic command value 1712 may be mandated by another flow, application, vehicle function, etc. associated with the vehicle (e.g., the torque command cannot be adjusted separately from an operator command unless a specified vehicle condition 1720 exists, etc.). The example system 1700 includes a strategy 1606 including a diagnostic execution condition 1706, wherein the diagnostic execution circuit 1702 further determines whether the vehicle operating condition 1720 is consistent with the diagnostic command value 1712 in response to the diagnostic execution condition 1706.

[0212] Example system 1700 includes diagnostic execution circuitry 1702 that further executes diagnostic data collection operations in response to active diagnostic descriptions 1705 and stores diagnostic data sets 1714 in response to the diagnostic data collection operations. For example, active diagnostic descriptions 1705 may include a plurality of data parameters to be collected, vehicle status conditions to be monitored, and / or parameter thresholds to be determined (e.g., temperatures above a threshold). Stored diagnostic data sets 1714 may include the collected data, vehicle status conditions determined based on the collected data, parameter threshold confirmation values ​​determined based on the collected data, or a combination thereof. The collected data may be from endpoints 1708, 1710 that are responsive to diagnostic command values ​​1712 (e.g., confirmation that an actuator has responded to a command, diagnostic data, or fault code associated with a responsive actuator) or from endpoints 1708, 1710 other than those that are responsive to commands (e.g., observations of temperature, pressure, speed values, status confirmations, etc. not directly associated with actuating endpoints 1708, 1710).

[0213] The example diagnostic execution circuit 1702 performs processing operations on the data collected in the diagnostic data collection operation and stores a diagnostic data set 1714 in response to the processing operations. For example, the stored diagnostic data set 1714 may include state information, virtual sensor information, negative information (e.g., only storing data associated with operations in which a threshold value is not met), upsampling and / or downsampling values ​​for the collected data, and / or any other processing operations set forth throughout this disclosure. Example and non-limiting processing operations, or portions thereof, for the collected data include: compressing the collected data; summarizing the collected data; operating a virtual sensor using the collected data; determining a vehicle operating condition parameter in response to the collected data; determining a diagnostic data set in response to the determined vehicle operating parameter; performing an upsampling operation on the collected data; and / or performing a downsampling operation on the collected data.

[0214] The example diagnostic execution circuitry 1702 further transmits a diagnostic data set 1714 to an external device (e.g., 1618) in response to the diagnostic data collection operation. The external device that receives the diagnostic data set 1714 may be the same or a different external device than the external device that supplied the active diagnostic description 1705. The example diagnostic execution circuitry 1702 further processes the collected data before transmitting to the external device, which may include determining initial processing of the stored diagnostic data set 1714 and / or further processing operations on the stored diagnostic data set 1714 before transmitting to the external device. For example, the diagnostic execution circuitry 1702 may store the diagnostic data set 1714 and send portions 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 transmitting it to the external device (e.g., to reduce external data communications in response to selected data for transmission to the external device, etc.); transmitting the diagnostic dataset 1714 to the external device (e.g., in response to the availability of external communications such as a WiFi connection, a connected external device, etc.; and / or in response to a request from the external device for all of the diagnostic dataset 1714); transmitting selected additional portions of the diagnostic dataset 1714 (e.g., data requested by the external device); maintaining the diagnostic dataset 1714 and / or a further processed form of the diagnostic dataset 1714 stored for a selected time period; and / or deleting the diagnostic dataset 1714 after the diagnostic execution operation (e.g., based on the results of an active diagnostic test and / or based on a request from an external device). As can be seen, the operation of system 1700 allows active diagnostic operations to be performed by an external device (e.g., a service tool, a service application, a cloud-based application, a team service computing device, and / or a third-party application) that engages endpoints on a vehicle across a hybrid network, thereby allowing diagnostic operations that do not require knowledge of the location and / or organization of the endpoints on the vehicle, which knowledge can support multiple configurations of the vehicle and / or can support changing configurations of the vehicle. Additionally or alternatively, the operation of system 1700 allows for scheduled data transmission including a reduction in data transmitted when implementing robust active diagnostic capabilities and scheduled consumption of processing, memory, and inter-network communication resources on the vehicle when implementing robust active diagnostic capabilities.

[0215] The example system 1700 includes a diagnostic verification circuit 1704 that determines a diagnostic confirmation value 1716 based on an actuator's response to a diagnostic command value 1712 (e.g., to confirm whether the actuator performed the commanded function and / or to confirm across a group of actuators whether the vehicle has performed an active diagnostic according to an active diagnostic description 1705). The example diagnostic verification circuit 1704 stores the diagnostic confirmation value 1716 (e.g., as part of a diagnostic dataset 1714) and / or transmits the diagnostic confirmation value 1716 to an external device. In certain embodiments, the diagnostic verification circuit 1704 adjusts the storage and / or communication of the diagnostic dataset 1714 in response to the diagnostic confirmation value 1716—e.g., to ensure that the diagnostic dataset 1714 is relevant to the performance of the active diagnostic. In some embodiments, the diagnostic execution circuitry 1702 may store all or a portion of the diagnostic data set 1714 as a rolling buffer of data, thereby saving selected portions of the diagnostic data set 1714 in response to the diagnostic verification circuitry 1704 providing a diagnostic confirmation value 1716 (e.g., where a diagnostic has a timing value or actuator position as part of the diagnostic execution, thereby allowing the diagnostic to be determined to be complete when a timer or other accumulated condition is completed).

[0216] 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 does not identify on which network zone 1612, 1614 the endpoint corresponding to the target device description 1718 is located. The example system includes configuration circuitry 1604 that determines a network address value 1722 for the endpoint in response to the target device description 1718 (e.g., a port number for an Ethernet network, a message ID for a CAN network, etc.), and diagnostic execution circuitry 1702 further provides a diagnostic command value 1712 to the endpoint in response to the network address value 1722. For example, the target device description 1718 may include a standardized description for the endpoint (e.g., engine speed, ambient temperature, passenger seat occupancy sensor, etc.), and the configuration circuitry 1604 may access a configuration table that associates the standardized description with a local network address for the intended component. Additionally or alternatively, the target device description 1718 can have a description that matches a baseline product (e.g., a 2020LX version of a given vehicle), a description that matches an original version of the vehicle (e.g., when the vehicle was configured after manufacture), and / or a description that matches an earlier version of the vehicle (e.g., when the vehicle was configured as of a certain date). In some embodiments, the configuration table or other information utilized by the configuration circuitry 1604 to determine the network address value 1722 can be one or more configuration files maintained by the network interface circuitry, a configuration file maintained by the policy manager circuitry, a configuration file maintained by the CND, and / or a configuration file maintained as part of the policy 1606.

[0217] 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 as being on one network zone (e.g., the first network zone 1612), and the configuration circuitry 1604 determines, in response to the target device description 1718, that the endpoint is on another network zone (e.g., the second network zone 1614). For example, the configuration circuitry 1604 may determine that the target device description 1718 is pointing to an incorrect device or a non-existent device, and / or may further determine that the external device is utilizing a previous, different, and / or standardized configuration file to provide the target device description 1718, wherein the configuration circuitry 1604 utilizes the local configuration file to determine an appropriate network address value and / or network zone for the endpoint intended by the target device description 1718. In some embodiments, the configuration circuitry 1604 utilizes other information from the target device description 1718 (such as parameter names, intended functionality, etc.) to determine an appropriate network address value and / or network zone for the endpoint. Similarly, the configuration circuitry 1604 may correct a target device description 1718 that indicates an incorrect address other than the erroneous network region, such as an address on the first network region, where the correct address is another address on the first network region.

[0218] Operation of the configuration circuitry 1604 allows for: simplification of active diagnostic definitions (e.g., external devices do not require system-specific information regarding endpoint location and network distribution); adaptation of diagnostic execution as a vehicle's endpoints and / or local communication devices are moved and / or upgraded; and / or allowing a layer of abstraction between external devices and the vehicle's configuration. The simplification and / or abstraction of active diagnostic definitions from the vehicle's network configuration allows for reduced cost of active diagnostic development and rollout and an increased user base for active diagnostic development (e.g., utilizing enhanced protection of confidential information (such as vehicle configuration information) and / or data compartmentalization), which can enhance overall diagnostic capabilities, enhance the vehicle operator experience, and increase competition and implicit competition for active diagnostic development and implementation.

[0219] refer to Figure 19 , the example system 1900 includes a vehicle 102 having a first traditional network area 1902 and a second high-capability network area 1904. For example, the first traditional network area 1902 can be a first network type, such as a CAN bus, and the second high-capability network area 1904 can be a second network type, such as an Ethernet network. In some embodiments, the second high-capability network area 1904 can be the same type as the first traditional network area 1902, but can be a higher-capability version, such as a high-speed CAN bus, a higher-speed Ethernet network, etc. In some embodiments, such as Figure 19A system such as the one depicted in 1900 may exist where a vehicle is migrating to an upgraded network type (such as during a transition period within multiple model years of a vehicle), as new components are added to the vehicle that utilize a higher capability network, etc.

[0220] The example system 1900 includes a CND 108 interposed between a first traditional network zone 1902 and a second high-capability network zone 1904, wherein the CND 108 includes a policy manager circuit 1602 that interprets a policy 1606 including an external communication value 1906, and an external communication control circuit 1908 that regulates communications between external devices 1618 and endpoints of the first traditional network zone 1902 and / or endpoints of the second high-capability network zone 1904 in response to the external communication value 1906. For example, external communications between endpoints of the first traditional network zone 1902 may be restricted to reduce the amount of traffic on the first traditional network zone 1902 created by communications to and from external devices 1618 and / or due to the sensitivity of endpoints on the first traditional network zone 1902 (e.g., where vehicle control and / or proprietary information is maintained on the first traditional network zone 1902, and / or where security protocols associated with the first traditional network zone 1902 are more restricted than those available with respect to the second high-capability network zone 1904). In another example, external communications between endpoints of the second high-capability network zone 1904 may be restricted to reduce external transmissions (e.g., via the vehicle's transceiver, utilizing a particular data provider, etc.) from the vehicle (e.g., where the higher-capability devices on the second high-capability network zone 1904 may have the capability to generate high data rates) due to a potentially large number of devices on the second high-capability network zone 1904, including devices that may have been recently added to the vehicle (and accordingly do not have a long history of known usage, security reviews, and / or vehicle operational impact data) and / or devices that may have been added by an entity that is not as tightly controlled as the providers of the devices on the first traditional network zone 1902 (e.g., devices that may be provided by a third party, are related to recently developed vehicle capabilities, and / or are not related to core vehicle functions (such as entertainment providers)). The reasons provided for limiting the amount of external traffic between endpoints on various networks and external devices are non-limiting and provided for illustration, but the external communications control circuitry 1908 may regulate communications between endpoints of any network zone and any external device for any reason.

[0221] The example system 1900 includes external communication values ​​1906 that include active diagnostic descriptions—e.g., diagnostic operations and / or data collection to be performed as diagnostic operations, and the active diagnostic descriptions can involve commands to any endpoint on any network zone of the vehicle, data collected from any endpoint on any network zone of the vehicle, and / or communications with any endpoint on any network zone of the vehicle. The example system 1900 includes external communication values ​​1906 that include active test descriptions—e.g., test operations (e.g., testing of any endpoint, actuator, sensor, flow, application, vehicle function, and / or vehicle controller on the vehicle), and the active test descriptions can involve commands to any endpoint on any network zone of the vehicle, data collected from any endpoint on any network zone of the vehicle, and / or communications with any endpoint on any network zone of the vehicle. The example system 1900 includes external communication values ​​1906, which include data request values ​​(e.g., collection of data parameters from any endpoint and / or processing including data parameters) and / or vehicle command values ​​(e.g., commands to any actuator, display, controller, etc. with any endpoint). Example and non-limiting external devices 1618 include service tools, manufacturer tools, dealer tools, and / or cloud-based tools.

[0222] Example external communication values ​​1906 include a target device description that includes an identification of a target endpoint (e.g., a network zone, a local address, a sensor name, an actuator name, a data parameter name, etc.), wherein the external communication control circuitry 1908 determines that the endpoint has a different configuration (e.g., a different network zone, a local address, a sensor name, an actuator name, a data parameter name, etc.) than the identification provided in the target device description. In some embodiments, the external communication control circuitry 1908 may include or utilize configuration circuitry 1604 (e.g., reference Figure 16 、 17 and related descriptions) to determine the appropriate identification for the target endpoint. The example external communication value 1906 does not include the identification of the target endpoint, and the external communication control circuit 1908 provides the appropriate identification for the target endpoint based on the external communication value 1906 (again refer to Figure 16 、 17 1604). As can be seen, the operation of system 1900 allows external device 1618 to operate across multiple vehicle configurations without specific knowledge of endpoint locations, parameter names, local addresses, etc., to enable active diagnostics, testing, and data collection. A vehicle configuration may represent a change in vehicle after service, replacement of a component (e.g., an endpoint), an upgrade of a component, and / or executable instructions stored on a computer-readable medium, a change over the course of a model year, and / or a change to a vehicle due to a marketing campaign, upgrade, and / or remanufacturing.

[0223] refer to Figure 20 , depicts an example apparatus 2000 for providing an external network view of one or more networks for a vehicle having hybrid networks. The example apparatus 2000 can be utilized in conjunction with any vehicle described throughout this disclosure, and aspects of the apparatus 2000 can be located on the vehicle, on an external device that at least selectively communicates with the vehicle, on a cloud server, and / or on a web application.

[0224] The example apparatus 2000 includes a vehicle communication circuit 2002 that interprets vehicle communication data 2016, which may be data collected from a vehicle and / or data to be provided to the vehicle. The example apparatus 2000 further includes a visualization circuit 2004 that generates visualization data 2018 in response to the vehicle communication data 2016. The example visualization data 2018 includes a first network identifier (e.g., identifying a network zone, endpoint, or other network identifier for corresponding data) and a second network identifier. The example visualization data 2018 may include a network identifier corresponding to each of at least two different network zones of the vehicle and / or each of at least two different 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.

[0225] The example apparatus 2000 further includes display interface circuitry 2006 that communicates visualization data 2018 , provides stored visualization data 2022 , and / or provides visualization data 2018 to the electronic display 2012 . The transmission of visualization data 2018 may include any one or more operations selected from operations such as: transmitting visualization data 2018 from a vehicle to a tool; transmitting visualization data 2018 from a vehicle to a cloud server; transmitting visualization data 2018 from a vehicle to a display device (e.g., an electronic display 2012 (such as a vehicle display), a service tool, an external computing device (such as an operator device, a service device, a manufacturer device, a fleet owner or service device, a vehicle communications administrator device and / or a third-party device), etc.); transmitting visualization data 2018 from a cloud server to a tool; transmitting visualization data 2018 from a cloud server to a display device; and / or transmitting visualization data 2018 from a first cloud server to a second cloud server (e.g., allowing for separate storage criteria for stored visualization data 2022 between cloud servers, including anonymization of data, aggregation of data, compartmentalization of aspects of data, etc.). In some embodiments, the transmission of visualization data 2018 may include: transmitting visualization data 2018 to on-vehicle storage (e.g., dedicated memory space available for stored visualization data 2022 for later access, requested access, and / or later transmission to an off-vehicle location) and / or to tightly coupled storage (e.g., a USB device coupled to the vehicle, to a mobile device (such as an operator's mobile phone), and / or to a computing device in near-field wireless communication (such as a WiFi or Bluetooth connection)). Additionally or alternatively, the transmission of visualization data 2018 may include any one or more operations selected from operations such as: storing visualization data 2018 on shared storage on the vehicle; storing visualization data 2018 on shared storage on the vehicle and selectively transmitting the stored visualization data 2022 to an external device; transmitting visualization data 2018 to protected cloud storage and providing selected access to the stored visualization data 2022 to a monitoring tool, external application, service tool, and / or user device.

[0226] The example apparatus 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 processed visualization elements determined based on the visualization data 2018 and / or the stored visualization data 2022. The example visualization data 2018 includes topology data corresponding to a network topology of a first network and / or a second network (e.g., depicting the networks and / or selected endpoints associated with each of the networks). The topology data may include a visual representation, a tabular listing, or other visualization of the topology data.

[0227] The example visualization circuitry 2004 is further structured to include a portion of metadata for the vehicle communication data 2016 in the visualization data 2018. Example and non-limiting metadata for the vehicle communication data 2016 includes data such as a source address, a destination address, a timestamp, a vehicle operating condition or status, fault code information, status parameters for endpoints, flows, applications, and / or vehicle functions, etc. In certain further embodiments, the metadata for the vehicle communication data 2016 includes information related to the trajectory of the vehicle communication data 2016 through the vehicle network, such as frame data related to the originating communication (e.g., frame data from a communication on the first network 2008, where the communication is encapsulated and passed from the second network 2010 to the vehicle communication circuitry 2002), processing information for the payload and / or frame of the vehicle communication data 2016 (e.g., processing operations performed on the payload and / or frame of the communication, such as reverse calculations described to allow processing, upsampling, and / or downsampling, etc.). In some embodiments, the metadata can have predetermined values, such as a first data value associated with a first processing operation (e.g., filtering, resolution change, etc.), a second data value associated with a second processing operation, whereby the metadata transmits a processing operation (or other operation) based on the value of a selected portion (e.g., a specified bit) of the vehicle communication data 2016.

[0228] The example apparatus 2000 includes monitoring input circuitry 2014 that interprets data filter values ​​2020 (e.g., a description of a filtering operation, such as: selection of certain endpoints and / or local communication devices; selection of certain network zones; communications that meet specified criteria; a down-sampling description for selected communications; communications associated with non-nominal conditions (e.g., endpoints, flows, vehicle functions, and / or applications having associated fault values) and / or communications associated with endpoints having lost packets, high or low expected communication rates, etc.). Example and non-limiting data filter 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 and non-limiting data filter 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 powertrain control system. Still further examples and non-limiting data filter values ​​2020 include references to systems such as safety systems, lighting systems, security systems, environmental control systems, ADAS, and / or infotainment systems.

[0229] The example apparatus 2000 includes a visualization circuit 2004 that filters a portion of vehicle communication data 2016 based at least in part on a data filter value 2020 to generate visualization data 2018. In certain embodiments, the data filter value 2020 may be provided in a policy 2006 that is transmitted from an external device 2018 and / or received via a user interface operating (e.g., by the display interface circuit 2006) on an electronic display 2012, an external tool 2014, and / or a user device, such as a vehicle owner or operator, service personnel, a manufacturer, a fleet owner, a fleet service personnel, a vehicle communication manager, and / or a device interacting with a cloud-based or web-based application.

[0230] refer to Figure 22 , depicts an example user interface for retrieving and filtering vehicle communication data 2016. The example user interface may be implemented on an external device, a web application, a cloud-based application, an external tool, etc. Figure 22 In the example of , "Switch 0" corresponds to the first network zone, and "Switch 1" corresponds to the second network zone, allowing the user to select endpoints from each network zone to be monitored. In the example, the filtering selection allows narrowing down the endpoints to be monitored (e.g., the selections on the left) according to filtering criteria such as including only selected endpoints, flows, applications, etc. (selections on the right). Figure 22 In the example of , the monitored parameter can be further downsampled (selection at the bottom). Figure 22In the example of , a selected mirroring timeout can be set (eg, where port mirroring is used to perform monitoring). Figure 22 The example user interface of illustrates certain aspects of network monitoring and filtering operations described herein and is not limited to the present disclosure.

[0231] The example apparatus 2000 includes visualization data 2018, including a traffic monitoring visualization. For example, the traffic monitoring visualization can provide a visualization corresponding to one or more of: an endpoint on one of the first network or the second network (e.g., showing incoming and / or outgoing traffic from the endpoint); a vehicle system; an application; a flow; a vehicle controller; a vehicle function; a selected one of the first network or the second network; or a port of one of the first network or the second network. The example visualization data 2018 includes a port counter visualization, such as displaying messaging traffic corresponding to a port (physical or logical) of one of the network zones. The example visualization data 2018 includes an endpoint data flow monitoring visualization, such as displaying messaging traffic corresponding to an endpoint of one of the network zones.

[0232] refer to Figure 23 , depicting example visualization data 2018 including traffic volume monitoring visualization. Figure 23 The example depicts network traffic (eg, messages, bits, etc.) for a first endpoint 2302 and a second endpoint 2304 . Figure 23 The examples are non-limiting examples and may be depicted in any manner and traffic monitoring may be organized according to any groupings (such as per network, per port, all traffic associated with an application, all traffic associated with a flow, all traffic associated with a vehicle function, all traffic associated with a service group, etc.).

[0233] The example apparatus 2000 includes visualization data comprising a network activity profile, wherein the network activity profile is provided for one or more of: an endpoint on one of the first network or the second network; a vehicle system; an application; a flow; a vehicle controller; a vehicle function; a selected network zone; and / or a selected port of one of the network zones.

[0234] refer to Figure 24 , depicting example visualization data 2018 including network activity profiles. Figure 24 The example depicts network bandwidth utilization for a selected network zone, having a plurality of utilization graphs 2402, 2404, 2406, 2408, each associated with an endpoint of the selected network zone. Figure 25 , depicts example visualization data 2018 including a network activity profile for a selected network zone. Figure 24The example depicts total activity for network zones at the top, network bandwidth utilization for specific devices in the middle (e.g., ISL 0, ISL 1), and network bandwidth utilization for vehicle controllers (e.g., heads-up display and head unit) at the bottom, where the network bandwidth utilization for the vehicle controllers further depicts utilization for multiple specific devices taken out (e.g., in the example, various cameras). Figure 24 and 25 The examples are non-limiting, and network activity profile data may be determined and displayed in any manner, and further network activity profile data may be grouped and / or subgrouped in any manner (including by endpoint, flow, application, vehicle function, vehicle controller, etc.).

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

[0236] In certain embodiments, retrieving vehicle communication data 2016 including traffic monitoring, network activity, and / or messages corresponding to endpoints of the network zone and / or corresponding to ports of the 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, a first port of the second network zone 2010 may correspond to a port to be monitored, wherein 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., wherein the vehicle communication circuit 2022 and / or a monitoring tool such as the 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.

[0237] refer to Figure 26 , depicts example visualization data 2018 including data flows between selected network participants (eg, endpoints, flows, applications, vehicle controllers, etc.). Figure 26The example depicts data flow between selected endpoints, in the example, depicting data flow with "EP1" (e.g., an endpoint such as a head unit) and other endpoints (e.g., in the example, EP3, EP5, EP10, such as ADAS-related components, parking controllers, etc.). Figure 26 Examples allow monitoring of a network to determine whether expected data traffic is occurring, whether non-nominal data traffic is occurring, etc. Figure 27 , depicts example visualization data 2018 showing total network activity for a selected network zone (at the top) and data pathfinding from a selected endpoint to other endpoints in the system (data paths at the bottom). In an example, user interface elements may be provided, such as allowing selection of a time to utilize for the data pathfinding depiction at the bottom (top depiction), allowing selection of a target endpoint (e.g., EP1 on the left), and / or whether to depict transmission, reception, or both. In some embodiments, visualization data 2018 may be presented as a user interface, such as allowing a user to select a component and have the associated data flow depicted. As can be seen, user interfaces such as Figure 26 and 27 to confirm desired operation, diagnose problems (e.g., degraded conditions of components, diagnosis of network problems, and / or detection of non-nominal operating conditions, such as those indicated by communications between components that more substantially communicate during certain non-nominal operating conditions). Additionally or alternatively, visualizations such as those depicted in FIG. Figure 26 to: improve network topology design, hardware selection, and / or protocol selection; consolidate applications, flows, vehicle functions, etc. on vehicle controllers (e.g., to reduce network traffic requirements); and / or identify potentially redundant or unnecessary network communications.

[0238] refer to Figure 21, depicts an example local address table 2100, schematically depicting configuration information consistent with various embodiments of the present disclosure. The example local address table 2100 can be part of a policy 1606 and / or configuration file (e.g., accessible in whole or in part by an interface circuit and / or configuration circuit). The local address table 2100 can be provided as a data structure in a memory location accessible to the interface circuit, configuration circuit, and / or other implementation components described throughout the present disclosure. The local address table 2100 can be provided as a distributed data structure, with portions of the local address table 2100 provided as data structures in memory locations accessible to implementation components. The example local address table 2100 is schematically depicted to provide an illustration of the type of local address information that can be utilized to implement aspects of the present disclosure, but the organization of the data structure implementing the local address table 2100 and the details of the information stored can be configured according to the implemented embodiment. The example local address table 2100 includes: an endpoint identifier 2102, which can be a local identifier of an endpoint present in the system. In a further example, a non-local endpoint identifier (not shown) may further be included, for example to allow external devices to reference the endpoint using industry standard terminology or other selected terminology. The example local address table 2100 includes a network zone identifier 2104, for example, indicating which network zone the endpoint is considered to be part of. The example address table 2100 further includes a local address value 2106, for example, indicating how to address the corresponding endpoint on the appropriate network zone. In some embodiments, the local address value 2106 may be a TCP / IP address, port number, or other identifier. In some embodiments, for example on a logical bus architecture such as a CAN bus, the local address value 2106 may include a message identifier, such as a value included in a message indicating the intended recipient (or source) of a message to or from the endpoint. The example local address table 2100 includes: an external address value 2108, which may, for example, include an address utilized to identify the endpoint by an external device.

[0239] Utilization of the external address value 2108 allows external devices to abstract knowledge of the endpoint, including local addressing and / or associated network zones, from the operation of utilizing and / or collecting data from the corresponding endpoint. It can be seen that further information can be included in the local address table 2100, such as additional external address values ​​(e.g., to allow multiple external addresses to be associated with a given endpoint of the system) and / or including one or more additional non-local endpoint identifiers (e.g., to allow multiple industry standards, proprietary nomenclatures, informal nomenclatures, etc. to be successfully associated with a given endpoint of the system). In certain embodiments, one or more of the external address 2108 and / or non-local endpoint identifiers can be further associated with a version (e.g., interface version, vehicle model description, etc.), thereby allowing implementation components using the local address table 2100 to interpret data commands and / or requests from external applications, algorithms, etc. to appropriately associate the desired endpoint with the data command and / or request as changes occur within the vehicle (e.g., an endpoint moves between network zones and / or addresses) or outside the vehicle (e.g., updating an external application for an updated vehicle configuration that is no longer applicable to a specific vehicle of the system).

[0240] It can be further seen that utilization of the local address table 2100 allows for multiple addressing support for endpoints of a vehicle, such as providing both IPv4 and IPv6 addressing for endpoints of a vehicle. In certain embodiments, the local address table 2100 can be expanded, or alternatively, a separate data structure can be maintained, thereby allowing endpoints to be associated with applications, flows, vehicle functions, vehicle controllers, APNs, external data routing paths, network zone tracks, and the like. Accordingly, a given application such as "route management" can be associated with a specific endpoint of a vehicle, and the association can survive movement of the endpoint (e.g., from one network zone to another). Utilization of the local address table 2100 and / or extended or alternate data structures as described herein allows for configuration of priorities, permissions, subscription management (both publishing services and subscribing to services), and / or any other communication regulation activities as set forth herein.

[0241] In some embodiments, the local address table 2100 may be augmented, or alternatively, a separate data structure may be maintained, thereby allowing addresses of external devices to be configured based on endpoints, applications, flows, vehicle functions, and / or vehicle controllers. For example, a given vehicle function may be allowed access to a given external resource (e.g., a routing function that accesses an external resource with mappings, traffic reporting, etc.), where an associated external address is associated with the vehicle function that provides access to the external resource. In an example, other vehicle functions may not be allowed access to a given external resource, where an associated external address is associated with those vehicle functions (and / or, depending on the implementation, associated with a lack of association for those other vehicle functions), such that when those other vehicle functions request access to the external resource, a default address, protected space, zero-value communication, or other selected behavior is implemented instead. Accordingly, requests for access to an external resource (such as, http: / / www.google.com ) can receive typical desired access to an external IP address corresponding to a Google website, where a second application of the vehicle requesting access to the same external resource can receive an access denial indication, a default external resource indication (e.g., a cloud-based resource in a protected space indicating that the requested resource is not permitted), or other selected response from the system. Accordingly, the local address table 2100 and / or an expanded, extended, or alternate version thereof can be used as a local DNS and / or external DNS. In some embodiments, for example, where access to an external resource is requested, where the external DNS does not have an address for the resource, and where permission to access the external resource is not denied to the requestor (e.g., an endpoint, application, flow, vehicle function, and / or vehicle controller), an external DNS outside the vehicle (e.g., on a cloud server, from an internet provider, etc.) can be accessed to provide the external address. In some embodiments, the external DNS on the vehicle can be updated based on the address retrieved from the external DNS outside the vehicle.

[0242] refer to Figure 28 , depicts an example system 2800 including 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. Figure 28An example CND 108 includes a CND 108 between network zones 1612 and 1614. The example CND 108 includes a policy manager circuit 1602 that interprets a policy 1606 including a network regulation description; and a configuration circuit 1604 that configures a first network interface circuit 1608 in response to the network regulation description, wherein the first network interface circuit 1608 regulates communications between endpoints of the first network zone 1612 and endpoints of the second network zone 1614. Additionally or alternatively, the configuration circuit 1604 configures a gatekeeper interface circuit 2802 in response to the network regulation description, wherein the gatekeeper interface circuit 2802 regulates communications between endpoints of at least one of the network zones 1612 and 1614 and an external communication portal and / or external device 1618. The example first network interface circuit 1608 includes a CEG, wherein 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 wherein the first network interface circuit 1608 is communicatively coupled to a port in 1614 of the second network to send and receive communications passed between the network zones 1612, 1614.

[0243] refer to Figure 29 , the example network regulation description 2904 includes: a data request permission description 2906, including data values ​​2910 associated with data requesters 2908 (e.g., endpoints each on one of the network zones 1612, 1614). The example first network interface circuit 1608 regulates communications between endpoints of the first network zone 1612 and the second network zone 1614 in response to the data request permission description 2906, for example, limiting the associated data requester 2908 to authorized data values ​​2910 and / or preventing the associated data requester 2908 from accessing unauthorized data values ​​2910. In certain embodiments, the first network interface circuit 1608 further regulates communications between endpoints of the first network zone 1612 (e.g., from a first endpoint to a second endpoint, both on the first network zone 1612) in response to the data request permission description 2906.

[0244] The example system 2800 further includes a configuration circuit 1604 that configures a second network interface circuit 1610 in response to the network regulation description, wherein the second network interface circuit 1610 regulates communications for endpoints of the second network zone 1614. Figure 29, example second network interface circuitry 1610 regulates communications between endpoints of second network zone 1614 and first network zone 1612 in response to data request permission description 2906, e.g., restricting associated data requester 2908 to authorized data values ​​2910 and / or preventing associated data requester 2908 from accessing unauthorized data values ​​2910. In certain embodiments, second network interface circuitry 1610 further regulates communications between endpoints of second network zone 1614 (e.g., from a first endpoint to a second endpoint, both on second network zone 1614) in response to data request permission description 2906.

[0245] Example system 2800 further includes configuration circuitry 1604 that configures gatekeeper interface circuitry 2802 in response to network regulation description 2904, wherein gatekeeper interface circuitry 2802 regulates communications between endpoints of both first network zone 1612 and second network zone 1614 and external device 1618. Example external device 1618 can be coupled to first network zone 1612, second network zone 1614, or both. Additionally or alternatively, external device 1618 can be coupled to a transceiver (not shown) of vehicle 102, which can be a cellular, WiFi, and / or Bluetooth transceiver. In some embodiments, the transceiver can be communicatively coupled to the network zones, for example, as a port on one of the network zones. In some embodiments, first network zone 1612 is a non-primary network zone, second network zone 1614 is a primary network zone, and the transceiver is communicatively coupled to second network zone 1614. In a further example embodiment, the second network region 1614 is an Ethernet network, and the transceiver is coupled to the second network region 1614 by communicating with the second network interface circuit 1610 through a port of a CES including the second network interface circuit 1610 .

[0246] Example and non-limiting external devices 1618 include one or more of the following: cloud server-based applications, web-based applications, and / or mobile device applications. Figure 29, the example data request permission description 2906 includes data access permissions 2914 associated with each of a plurality of external communicants 2912. Example external communications 2912 include identified external devices 1618, external applications, external flows, external entities (e.g., services, manufacturers, owners, operators, etc.), external addresses, etc. Example and non-limiting data access permissions 2914 include permission to communicate with specific endpoints, flows, applications, vehicle functions, network zones, vehicle controllers, etc. In some embodiments, data access permissions 2914 may be different for transmitted and received communications—for example, a given external communicator 2912 may not have permission to request data from a first endpoint on a vehicle, but the first endpoint on the vehicle may have permission to send data to a given external communicator 2912. Example data request permission description 2906 includes data access permissions associated with one or more of the following: an external device; an external communicator; a flow associated with an endpoint, an external device, and / or an external communicator; a vehicle function associated with an endpoint, an external device, and / or an external communicator; and / or an application associated with an endpoint, an external device, and / or an external communicator. Example and non-limiting data access permissions 2914 include one or more of the following: the ability to request, transmit, and / or publish data; the ability to request, transmit, and / or publish specific data values; and / or external communication bandwidth limits (e.g., data rate, aggregate data volume per unit time, and / or share of available bandwidth). Example system 2800 further includes gatekeeper interface circuitry 2802 that regulates communications between endpoints of network zones 1612, 1614 and external devices 1618 (and / or external communicators 2912) in response to data request permission description 2906 and / or data access permissions 2914.

[0247] The example gatekeeper interface circuit 2802 further regulates communications with the external device 1618 (and / or external communicator 2912) in response to one or more of: a stream associated with the regulated communications (e.g., based on a priority of the associated stream, a role of the associated stream, and / or current operating conditions, etc.); a data type associated with the regulated communications (e.g., prioritizing or de-prioritizing certain data types, limiting certain data types to certain communication conditions (such as the availability of high data rate communications), categorizing data based on criteria such as the age of the data and adjusting permissions accordingly, etc.); a data service provider associated with the regulated communications (e.g., configuring data rates, bandwidths, and / or aggregate data values ​​in response to an associated data service provider for the data); a vehicle function associated with the regulated communications (e.g., prioritizing certain vehicle functions); and / or a type of connection coupling the communications with the external device 1618 (and / or external communicator 2912) (e.g., allowing for greater communication rates when high rate and / or low cost data connections are available).

[0248] The example system 2800 includes: a configuration circuit 1604 that receives a policy update (e.g., from a policy manager circuit 1602) that includes a change to a network regulation description 2904 and updates a configuration of the first network interface circuit 1608, the second network interface circuit 1610, and / or the gatekeeper interface circuit 2802 in response to the change to the network regulation description 2904. In a further example, the policy manager circuit 1602 interprets authorization associated with the policy update, e.g., based on permission of the external device 1618 and / or the external communicator 2912 providing the policy update. The example policy manager circuit 1602 suppresses the policy update in whole or in part in response to an authorization indicating that the requesting unit (e.g., the external device 1618 and / or the external communicator 2912) is not authorized to make changes to the network regulation description of the policy update. In some embodiments, the policy manager circuit 1602 may additionally or alternatively suppress the policy update in response to suppressing or partially suppressing the policy update (e.g., with reference to Figure 16 and related descriptions) to provide one or more policy notifications 1620 to a requesting unit and / or to other external devices 1618 or external communicants 2912. Example and non-limiting requesting units include one or more of the following: an entity associated with a policy update; an application associated with a policy update; a flow associated with a policy update; a vehicle function associated with a policy update; an identifier of an external device transmitting a policy update; and / or an identifier of an external communicator associated with a policy update.

[0249] Reference again Figure 28 The example policy manager circuit 1602 interprets the network usage permission description 3004 (reference Figure 30) policy 1606. The example network usage permissions description 3004 includes an external data access description 3006, wherein the configuration circuitry 1604 further configures the gatekeeper interface circuitry 2802 in response to the external data access description 3006, and wherein the gatekeeper interface circuitry 2802 regulates communications with the external device 1618 in response to the external data access description 3006. The example external data access description 3006 includes external access permissions 3014 associated with external communicants 3012, such as an identified external device 1618, an external application, an external flow, an external entity (e.g., a service, manufacturer, owner, operator, etc.), an external address, etc. In some embodiments, the external communicants 3012 include one or more local communication devices requesting external communications, such as 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 circuitry 2802 regulates external communications based on flow associations of communication endpoints in endpoints of the first network zone and / or the second network zone (e.g., restricting external communications to permitted communications according to external access permissions 3014 and / or allowing external communications not excluded by external access permissions 3014). The example gatekeeper interface circuitry 2802 regulates external communications based on application associations of communication devices (e.g., external devices 1618 and / or endpoints), e.g., restricting external communications to permitted communications according to external access permissions 3014 and / or allowing external communications not excluded by external access permissions 3014. The example gatekeeper interface circuitry 2802 regulates external communications based on network zone associations of communication devices (e.g., the network zone associated with the endpoint requesting the external communication, or the source zone; and / or the zone to which it is the target, or destination zone, of the external communication), e.g., restricting external communications to permitted communications according to external access permissions 3014 and / or allowing external communications not excluded by external access permissions 3014. In some 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 permissions 3014 .

[0250] Example policy 1606 includes an external data quantity description (not shown), wherein configuration circuitry 1604 configures gatekeeper interface circuitry 2802 in response to the external data quantity description. The example external data quantity description includes data limits for applications, and wherein the gatekeeper interface circuitry further regulates external communications based on the association of communication devices with the applications. The applications can be vehicle operation-related applications (e.g., applications operating on the vehicle and / or operating on external devices that have communication interactions with the vehicle) or applications unrelated to vehicle operation (e.g., infotainment applications, operator applications, web browsing utilizing the vehicle's network zone, third-party applications communicating with the vehicle, etc.). The example external data quantity description includes data limits for endpoints in one of the network zones, and the gatekeeper interface circuitry regulates communications based on the source or destination endpoint of the regulated communications. The example external data quantity description includes data limits for flows, and the gatekeeper interface circuitry regulates external communications based on the association of communication devices with flows.

[0251] Example and non-limiting data limits include one or more of the following: the amount of data transmitted corresponding to a selected time period (e.g., MB per hour, GB per month, etc.); the amount of data transmitted corresponding to selected vehicle operating conditions (e.g., MB per trip; data rate during idle operation; data rate at rated operation; data rate during high transient operation; etc.); the amount of data transmitted corresponding to a data provider associated with an application, endpoint, and / or flow; the share of the transceiver's bandwidth utilized for communications; the amount of the transceiver's bandwidth utilized for communications; the share of the bandwidth of a channel of the transceiver (e.g., where the transceiver includes more than one channel, where the share of the bandwidth is limited to the channel serving external communications for applications, endpoints, and / or flows); and / or the amount of the bandwidth of a channel of the transceiver (e.g., where the transceiver includes more than one channel, where the amount of the bandwidth is limited to the channel serving external communications for applications, endpoints, and / or flows).

[0252] refer to Figure 31, the example network usage permission description 3004 includes a network utilization description 3102 corresponding to a network zone 3104 and a communication device description 3106 corresponding to a local communication device (e.g., an endpoint, a flow, a vehicle function, and / or an application). In the example, the gatekeeper interface circuit 2802 further regulates external communications based on the network utilization description 3102 and the communication device associated with the regulated communication (e.g., corresponding to the communication device description 3106). The example network utilization description 3102 includes determining priorities 3108 regarding the communication device, associated flows 3110, associated vehicle functions 3112, associated applications 3114, and / or associated conditions or events 3116 (e.g., triggering events for implementing aspects of the policy 1606, vehicle or other conditions that must exist to allow implementation of aspects of the policy 1606, and / or vehicle or other conditions that, if present, adjust or suppress aspects of the policy 1606) to regulate external communications. The network utilization description 3102 may include one or more of the following: the bandwidth of the network zone 3104 available for use in supporting external communications; the data rate on the network zone 3104 available for use in supporting external communications; the bandwidth limits of the network zone 3104 (e.g., they may be throttled or reduced in cases where external communications would normally exceed bandwidth); and / or the data rate limits of the network zone 3104 (e.g., they may be throttled, reduced, or delayed in cases where external communications would normally exceed bandwidth). In some embodiments, the priority 3108 or other information associated with the external communications may be compared with the priority of on-vehicle communications utilizing the network zone, and the external communications may be given priority over the on-vehicle communications, which may be throttled, reduced, or delayed until the external communications are serviced. In some embodiments, service requirements (e.g., QoS parameters) for on-vehicle endpoints, flows, applications, vehicle functions, etc. (e.g., local communication devices) may be considered in determining permission for external communications, and the external communications may be permitted if the service requirements can be met.

[0253] refer to Figure 32 , the example vehicle 102 includes a first network zone 3202 and a second network zone 3204 of a different type than the first network zone 3202. The example vehicle includes: a gatekeeper interface circuit 3206 that is interposed between the first network zone 3202 and the external device 3210 and between the second network zone 3204 and the external device 3210. The gatekeeper interface circuit 3206 can be physically interposed (e.g., where communications between the zones 3202, 3204 and the external device 3210 pass through the gatekeeper interface circuit 3206) or logically interposed (e.g., where communications between the zones 3202, 3204 and the external device 3210 are mediated by the gatekeeper interface circuit 3206). Figure 32In the example of , the 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 . Figure 32 The transceiver 3208 of the vehicle 102 is depicted as a single device, although a given vehicle may have multiple transceivers (not shown). The example gatekeeper interface circuit 3206 regulates communications between a selected number of zones 3202, 3204 on the vehicle 102 and the selected transceivers 3208. For example and without limitation, the operation of the gatekeeper interface circuit 3206 may limit external communications with the selected zones 3202, 3204 to ensure security of vehicle data and operations, ensure protection of private and / or proprietary information, and maintain the vehicle's functionality to perform a selected mission (e.g., limit the amount of irrelevant and / or malicious network traffic on the selected zones 3202, 3204). In another example and without limitation, the operation of the gatekeeper interface circuit 3206 may limit utilization of the selected transceiver 3208 to preserve 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 appropriate local communication devices and / or data service providers.

[0254] refer to Figure 33 , depicting certain embodiments of the present disclosure Figure 32 The example CND 108 is consistent with the example of the example CND 108. The example CND 108 includes the gatekeeper interface circuit 3206, and further includes: a policy manager circuit 3302 that interprets the policy 1606 including the network regulation description; a configuration circuit 3304 that configures the first network interface circuit 3306 and / or the second network interface circuit 3308 in response to the policy 1606, and wherein the network circuits 3306, 3308 regulate communication between endpoints of the corresponding network zones (intra-network communication) and / or communication between endpoints across the corresponding network zones (inter-network communication). Figure 33 The example depicts two network interface circuits 3306, 3308, although operations of the gatekeeper interface circuit 3206 may be performed in relation to only one network interface circuit, a subset of the available network interface circuits, or all network interface circuits. Figure 34 , the example CND 108 includes a second network interface circuit 3308, wherein the gatekeeper interface circuit 3206 regulates communication between the second network zone 3204 and the external device 3210. Figure 34In the example of FIG, external communications from the first network zone 3202 are provided to the second network zone 3204 via the first network interface circuit 3306 and are thereby mediated 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 mediated 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.

[0255] refer to Figure 35 , the example vehicle 102 includes a vehicle controller 3502, wherein a gatekeeper interface circuit 3206 is located on the vehicle controller 3502. The example gatekeeper interface circuit 3206 regulates external communications between the selected network zones 3204, 3202 and the external device 3210. The example gatekeeper interface circuit 3206 can be an endpoint of the second network zone 3204, and / or the vehicle controller 3502 can be an endpoint of the second network zone 3204. Figure 36 , the example gatekeeper interface circuitry 3206 is distributed between two vehicle controllers 3502, 3602, where each of the vehicle controllers 3502, 3602 is provided as an endpoint for a 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 circuitry 3206 is distributed, each gatekeeper interface circuitry 3206 portion may mediate a portion of external communications (such as communications with an associated network zone), and / or may be able to mediate all external communications for a selected network zone, e.g., to provide redundancy in the event that communications with one of the gatekeeper interface circuitry 3206 portions are lost or degraded. Reference Figure 37 , the example gatekeeper interface circuit 3206 is distributed between the first portion of the CND 108 and the second portion on the vehicle controller 3702. The example vehicle controller 3702 is an endpoint on the second network zone 3204. Similar to Figure 36 In an example, each gatekeeper interface circuit 3206 portion may regulate a portion of external communications (such as, communications with an associated network zone), and / or may be able to regulate all external communications for a selected network zone, for example, to provide redundancy capability in the event that communications with one of the gatekeeper interface circuit 3206 portions are lost or degraded.

[0256] refer to Figure 38, the example policy 1606 includes an external data routing description 3802, wherein the configuration circuitry 1604 configures the gatekeeper interface circuitry 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 3803.

[0257] refer to Figure 39 , the example local DNS 3804 includes a plurality of local address values ​​3904 for the endpoint 3902 of the network zone, each corresponding to at least one non-local address value 3906. The example local DNS 3804 can be stored as part of the data structure, policy 1606, and can be associated with the local address table 2100 (see Figure 21 ) or as a separate data structure. Example local DNS 3804 can be utilized in a network address translation (NAT) operation. Example non-local address value 3906 includes an address utilized by an external device (e.g., an IPv4 or IPv6 address directed to an endpoint, where the IPv4 or IPv6 address may not match the local address value 3904, but may be a value from a previous configuration, a value typically used by an entity associated with the external device, etc.). Example non-local address value 3906 includes a standardized value for an endpoint (e.g., an industry standard, a customary value, a value utilized by a standards body such as SAE, etc.). Example non-local address value 3906 includes a proprietary value for an endpoint (e.g., a value typically utilized by a manufacturer, an aftermarket entity, etc.). Example non-local address value 3906 includes a previous local address value for an endpoint (e.g., a local address value 3904 utilized when the vehicle was manufactured, utilized for a previous configuration of the vehicle, utilized for a previous configuration of a related vehicle (such as, an earlier model year), etc.). Utilization of local DNS 3804 allows external devices to address vehicle endpoints 3902 using separate non-local address values ​​3906 without requiring knowledge of the network configuration, location, or other information related to the vehicle's endpoints 3902. Utilization of local DNS 3804 further allows for changes to the vehicle configuration (such as the movement of endpoints between network zones, consolidation of endpoints, and / or any other changes to the vehicle's endpoints and / or the vehicle's network topology) while still allowing external devices, applications, and the like to function properly. Utilization of local DNS 3804 also provides for separation of vehicle-related knowledge from external applications, thereby allowing a greater number of users to access vehicle information, isolating external users from vehicle information, and reducing external application development time and / or resource requirements. Utilization of local DNS 3804 also facilitates incremental changes to the network topology of the associated vehicle, such as migration of endpoints from a first network zone to a second network zone over multiple model years or other configuration iterations.

[0258] The example policy manager circuitry 1602 determines an address change for an endpoint in a first network zone and / or a second network zone and, in response to the address change, updates the local DNS 3804. For example, the policy manager circuitry 1602 may detect movement of an endpoint between network zones (e.g., detecting a communication from the endpoint, receiving an identifier from the endpoint at the new location, and / or receiving notification of the change from the endpoint, a service tool, etc.) and, in response to the movement, update the local DNS 3804 with a local address value 3904 (e.g., network zone, address value, etc.) corresponding to the new location. In another example, the policy manager circuitry 1602 may detect a change in a non-local address value 3906 for the endpoint and, in response to the change in the non-local address value 3906, update the local DNS 3804. For example, a change to policy 1606 from an external device may indicate that a change to the non-local address value 3906 has occurred (e.g., "AmbTempSens" is now "Ambient Temperature Sensor"), and / or a published list of non-local address values ​​3906 may be updated (e.g., a list provided on a memory of a cloud server, where the policy manager circuitry 1602 periodically and / or sporadically polls the list for changes). The example policy manager circuitry 1602 determines authorization of the external device providing the change to the non-local address value 3906, e.g., allowing only authorized devices, entities, applications, etc. to adjust the non-local address value 3906. The operation of the policy manager circuitry 1602 to update the non-local address value 3906 allows for convenient compliance with industry standards, manufacturer preferences, and / or system changes for multiple vehicles without having to configure individual vehicles when a change in ownership or standards references an endpoint. It can be seen that the operation of updating the non-local address values ​​3906 can also improve memory utilization as the size of the local DNS 3804 (and / or local address table 2100) can be reduced over time as the group of related vehicles synchronizes on the accepted address values, and redundant relationships of non-local address values ​​3906 that are no longer utilized are eliminated.

[0259] refer to Figure 40, an example external data routing description includes an external DNS 3806 that includes a plurality of external address values ​​4004 for external network access locations, each corresponding to a local communication device 4002. The external DNS 3806 allows the gatekeeper interface circuitry 2802 to control access to the external network access locations for the local communication device 4002. In some embodiments, the external DNS 3806 is operated to allow only permitted external access (e.g., where the external address value 4004 is provided). In some embodiments, the external DNS 3806 is operated to prevent external access (e.g., where the listed external addresses 4004 may not be accessed). In some embodiments, both the access permission and / or the access type may be tailored to the local communication device 4002. For example, certain endpoints, flows, applications, vehicle functions, etc. may be restricted to external access where the external address value 4004 is available, while other endpoints, flows, applications, vehicle functions, etc. may be permitted external access except where a particular external address value 4004 is listed as prevented from access. In some embodiments, the external DNS 3806 includes a non-local address value 3906—e.g., an IP address corresponding to an external address value 4004 that can be a public name (such as, for example, a website address as listed in the written language). Utilization of the 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 an internal 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). Example and non-limiting external network access locations include one or more of the following: an Internet address, a wide area network address, and / or an external device and / or external application identifier (e.g., a "routing plan agent," a "service assist agent," an IPv6 address, etc.).

[0260] Example external data routing path 3808 includes a network zone track for regulated external communications corresponding to a local communication device. The example network zone track includes data configuration for the communication, such as one or more of the following: 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 track allows for selected processing of the communication, including the payload and / or frame of the communication, to be provided to the external communication, and / or the network zone track allows for providing the external communication at a selected data rate. The selected data rate can be based on a data rate request from the external device and / or based on a data rate limit associated with the external communication (e.g., to limit network utilization, transceiver utilization, data transmission associated with a data provider, etc.). The network zone track additionally or alternatively allows for selected encapsulation of the communication, such as when a message passes through an intervening network zone before being externally transmitted to the vehicle (e.g., a CAN message from a first network zone passes as an Ethernet message on a second network zone).

[0261] The example network zone track further includes an external communication portal 4102 for moderated communications (e.g., see Figure 41 , and related descriptions), wherein the gatekeeper interface circuitry 3206 further regulates communications between local communication devices (e.g., endpoints of a network zone) and an external communication portal 4102. Example and non-limiting external communication portals 4102 include transceiver selection (e.g., where more than one transceiver is available), access point name (APN) selection, hardware port selection (e.g., a hardware port of the network zone, an OBD port, a proprietary communication port, a USB port, etc.), a WiFi adapter, a Bluetooth adapter, and / or cellular communication. The example network zone trajectory allows the gatekeeper interface circuitry 3206 to utilize external communications with the lowest cost, the lowest impact on vehicle and / or network performance, to assign external communications to the appropriate service provider, to ensure QoS parameters for local communication devices, and / or to ensure the security of external communications. The example gatekeeper interface circuitry 3206 adjusts the network zone trajectory in response to the operating status of the vehicle (e.g., vehicle is stopped, in service mode, idle, operating at nominal conditions, available external communication portals 4102, etc.). The example gatekeeper interface circuit 3206 adjusts the network zone trajectory in response to the operational conditions of the network zone and / or transceiver (eg, current utilization, connectivity, fault status, etc.).

[0262] The example external data routing path includes an APN for regulated communications (e.g., specifying an associated data service provider for the communications). The example gatekeeper interface circuitry 3206 adjusts the APN in response to operating conditions of the vehicle, network zone, and / or transceiver (e.g., where communications are supporting more than one application, vehicle function, and / or flow, the operation of adjusting the APN in response to operating conditions of the vehicle allows regulated communications to be attributed to a "primary consumer" of the communications). The example gatekeeper interface circuitry 3206 aggregates regulated communications from multiple local communication devices (e.g., where communications support more than one endpoint, application, vehicle function, and / or flow) and distributes the aggregated regulated communications among more than one APN associated with the local communication devices (e.g., where communications are supporting multiple consumers, the aggregated amount of communications can be distributed across the APNs, thereby allowing a reduction in total external communications by avoiding redundancy while attributing all external communications). In certain embodiments, adjusting the APNs, aggregating regulated communications, and / or distributing aggregated regulated communications among the APNs is performed in response to the attribution description of the policy 1606 .

[0263] The example policy manager circuit 1602 determines a change to an external data routing path (e.g., provided by an external device 1618) and updates the external data routing description in response to the change to the external data routing path. The example policy manager circuit 1602 determines authorization of the external device providing the change to the external data routing path and, in response to determining that the change is not authorized or is not fully authorized, suppresses all or part of the change to the external data routing path. The example policy manager circuit 1602 changes the external data routing path in response to a change to a local communication device (e.g., changing the route in response to an endpoint moving from one network zone to another network zone). Example and non-limiting changes to the local communication device include one or more of the following: movement of 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 change in traffic flow, wherein the change includes a change in priority, subscription, or permissions; a change in application, wherein the change includes a change in priority, subscription, or permissions; and / or a change in the amount, configuration, or type of data transmitted by the local communication device.

[0264] refer to Figure 41, the example vehicle 102 includes a gatekeeper interface circuit 3206 that regulates communications between a local communication device and an external device 1618. The example vehicle 102 includes a local communication device that initiates communications and / or targets communications received from the external device 1618 ("initiating / receiving local communication device 4104"), and the gatekeeper interface circuit 3206 that provides for routing external communications 4108 in response to the initiated or received communications and further in response to the policy 1606 including an external data routing path, permissions associated with the local communication device, and / or permissions associated with the external device 1618. In certain embodiments, the gatekeeper interface circuit 3206 selects an external communication portal 4102 for routing the external communication 4108, which includes selecting a device through which the routed external communication 4108 will be transmitted to the external device 1618. The example external communication portal 4102 includes one or more of the following: a first transceiver 4110 and / or an APN selection 4122 for the first transceiver 4110 (e.g., allowing selection of a data provider associated with the communication 4108); a second transceiver 4112, an APN selection 4122 for the second transceiver 4112, and / or a channel selection 4124 (e.g., allowing selection of a data provider and / or channel for the transceiver 4112); a second network zone connection 4114 (e.g., a port for an Ethernet network zone); a WiFi adapter 4116 (e.g., utilizing a WiFi connection where available); a Bluetooth adapter 4118 (e.g., utilizing a Bluetooth connection where available); and / or a first network zone connection 4120 (e.g., a port for a CAN network zone). For ease of description, Figure 41 The example depicts a first transceiver 4110 and a second transceiver 4112 to indicate that the transceivers 4110, 4112 may or may not have a channel, although a given vehicle 102 may have any number of transceivers 4110, 4112, some, all, or none of which may operate with a channel. For ease of description, Figure 41 The example depicts a single connection to each network zone to indicate that any network zone can have a connection, although a given network zone may have no connection or more than one connection (e.g., an OBD port and a proprietary port, etc.). Without limitation to any other aspect of the present disclosure, the gatekeeper interface circuit 3206 can adjust routing operations based on available external communication portals 4102, vehicle operating conditions, network operating conditions, permissions of any entity in the communication chain, priority of any entity in the communication chain, service requirements of any entity associated with the vehicle, and / or data rate and / or quantity limitations.

[0265] refer to Figure 42, the example policy 1606 includes an external data service description 4202, wherein the configuration circuitry 1604 configures the gatekeeper interface circuitry 3206 in response to the external data service description 4202. The example external data service description 4202 includes a plurality of local communication devices 4204, each corresponding to a QoS value 4206. Example and non-limiting QoS values ​​4206 include one or more of the following: a priority value; a packet delay value (e.g., a maximum value, an average value, or other description of packet delay); a packet loss rate value (e.g., a maximum value, an average value, a longest gap time, or other description of packet loss); a data rate value; a maximum release time value; an acknowledgement value (e.g., whether an acknowledgement is required for communications associated with the associated local communication device, if applicable); a data buffer priority value (e.g., which can be utilized to determine a buffer size, a buffer priority, and / or a data expiration parameter for buffered data); a data buffer size value (e.g., a data buffer size, a buffered time, or other storage size-related parameter); and / or a data lifecycle description (e.g., indicating a storage lifespan, an expiration time, and / or a deletion priority for associated data). Without limitation to any other aspects of the present disclosure, a local communication device includes one or more of the following: an endpoint in a network zone; an application; a flow; a vehicle function; and / or a vehicle controller. In some embodiments, the gatekeeper interface circuit 3206 regulates external communications using a QoS value 4206 corresponding to the local communication device 4204 associated with the regulated communication. In some embodiments (e.g., where more than one local communication device 4204 is associated with the regulated communication (e.g., endpoints and flows)), the gatekeeper interface circuit 3206 utilizes the QoS value 4206 associated with the highest priority one of the local communication devices 4204 and / or the superset of applicable QoS values ​​4206 that satisfies the highest service value for all associated local communication devices 4204.

[0266] The example policy manager circuitry 1602 determines a change to the external data service description, such as by an update of a policy from an external device, and the configuration circuitry 1604 updates the configuration of the gatekeeper interface circuitry 3206 in response to the updated policy. The example policy manager circuitry 1602 determines authorization of the external device providing the change to the external data service description and suppresses all or part of the change to the external data service description in response to determining that the change is not authorized or is not fully authorized.

[0267] Reference again Figure 40, the example external data routing description includes an external DNS that includes a plurality of external address values ​​4004 for external network access locations, each corresponding to a local communication device 4002 (e.g., an endpoint of a network zone). The example gatekeeper interface circuit 3206 further accesses an external DNS (not shown) outside the vehicle in response to a request by an endpoint to communicate an external address value, wherein 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 external DNS outside the vehicle.

[0268] Reference again Figure 28 , the example vehicle 102 includes a first network zone 1612 and a second network zone 1614, wherein the second network zone 1614 is of a different type than the first network zone 1612. The example vehicle 102 includes: a policy manager circuit 1602 that interprets a policy 1606 including an external data routing description and an external data service description. The example vehicle 102 includes: a configuration circuit 1604 that configures a gatekeeper interface circuit 2802 in response to the external data routing description and the external data service description. In the example, the gatekeeper interface circuit 2802 is interposed between the first network zone and at least one external communication portal 4102 selectively coupleable to an external device 1618 (e.g., reference Figure 41 ), and further between the second network zone and the at least one external communication portal 4102. Gatekeeper interface circuitry 2802 regulates communications between endpoints of network zones 1612, 1614 and the external communication portal 4102. An example external data routing description includes a plurality of local communication devices, each corresponding to an external data routing path. The example external data routing path includes a network zone trace for regulated communications. The example network zone trace includes data configurations 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 example network zone trace includes at least one external communication portal 4102 for regulated communications.

[0269] An example external data service description includes a plurality of local communication devices, each corresponding to one or more QoS values. In a further example, the external communication portal 4102 includes a first transceiver and a second transceiver, wherein the gatekeeper interface circuitry is further responsive to the external data service description to distribute regulated communications between the first transceiver and the second transceiver. In another example, the external communication portal 4102 includes a first channel associated with the transceiver and a second channel associated with the transceiver, wherein the gatekeeper interface circuitry is further responsive to the external data service description to distribute regulated communications between the first channel and the second channel.

[0270] The example external communication portal 4102 includes one or more external access points such as: a transceiver; a wireless transceiver; a Bluetooth transceiver; a hardware port on a first network zone; a hardware port on a second network zone; an on-board diagnostic (OBD) port; a proprietary network port; an external network that utilizes wireless communication with the vehicle (e.g., where communications with external devices are directly to the external network and / or tunneled through the external network); an external network that utilizes cellular communication with the vehicle; an external network that utilizes Bluetooth communication with the vehicle (e.g., where communications with external devices are directly to the external network and / or tunneled through the external network); more than one channel of a transceiver; more than one transceiver; and / or multiple channels distributed across at least two transceivers.

[0271] The example gatekeeper interface circuit 2802 further distributes the regulated communications between the at least two external access points. In a further example, each QoS value includes a service description such as: a priority value; a packet delay value; a packet loss rate value; a data rate value; a maximum release time value; an acknowledgement value; a data buffer priority value; a data buffer size value; and / or a data lifecycle description.

[0272] Certain aspects of the present disclosure are described as processes for performing operations related to the present disclosure. The operations may be performed by any controller, circuit, device, component, sensor, actuator, logic circuit, or other aspects as described in the present disclosure, without limitation thereto. The processes are schematically depicted as illustrative examples, and the operations may be omitted, combined, divided, and / or reordered in whole or in part. In some embodiments, one or more operations of a first process may be combined with one or more operations of another process.

[0273] refer to Figure 43 , schematically depicts an example process 4300 for regulating communications between different types of networks on a vehicle. The example process 4300 includes: an operation 4302 of interpreting a policy including a network regulation description; and an operation 4304 of regulating communications between an endpoint of a first network and an endpoint of a second network in response to the network regulation description.

[0274] refer to Figure 44, schematically depicting an example process 4400 for regulating communications between different types of networks on a vehicle. The example process 4400 includes: operation 4302, interpreting a policy including a network regulation description; and operation 4402, receiving a policy communication from an external device. Process 4400 includes: operation 4404, determining whether the policy is verified - for example, whether the external device is authorized to update the policy, whether the system is able to execute according to the policy, whether the policy violates any security criteria, whether the performance of the policy will exceed data storage boundaries or communication boundaries, etc. In response to operation 4404 indicating "yes", process 4400 includes: operation 4406, storing and / or updating the policy; and operation 4304, regulating communications between endpoints of the first network and endpoints of the second network in response to the network regulation description. In response to operation 4404 indicating "no", process 4400 optionally includes: operation 4408, providing notification to the external device (and / or to other external devices); and operation 4304, regulating communications between the endpoints of the first network and the endpoints of the second network in response to the network regulation description (e.g., utilizing a previous policy, a default policy, etc.).

[0275] refer to Figure 45 , schematically depicts an example process 4500 for regulating communications between different types of networks on a vehicle. Example process 4500 includes: operation 4302, interpreting a policy including a network regulation description; and operation 4402, receiving a policy communication from an external device. Process 4500 includes: operation 4404, determining whether the policy is verified - for example, whether the external device is authorized to update the policy, whether the system is able to execute according to the policy, whether the policy violates any security criteria, whether the performance of the policy will exceed data storage boundaries or communication boundaries, etc. In response to operation 4404 indicating "yes", process 4500 includes: operation 4502, updating local configuration files for one or more of the following: network interface circuits, CEGs, CESs and / or gateway interface circuits. In response to operation 4404 indicating "no", process 4500 optionally includes: operation 4408, providing a notification to the external device (and / or to other external devices). Process 4500 includes an operation 4504 of using network interface circuitry, CEG, CES, and / or gateway interface circuitry (eg, whether updated or not) to mediate intra-network, inter-network, and / or external communications.

[0276] refer to Figure 46 , schematically depicts an example process 4600 for commanding an actuator in response to a diagnostic command value. The example process 4600 includes: an operation 4602 of interpreting a policy including an active diagnostic description; an operation 4604 of providing a diagnostic command value to an endpoint in response to an active diagnostic condition; and an operation 4606 of commanding an actuator in response to the diagnostic command value.

[0277] refer to Figure 47 , schematically depicts an example process 4700 for commanding an actuator in response to a diagnostic command value. Example process 4700 includes: operation 4702, interpreting a policy including an active diagnostic description and a diagnostic execution condition; and operation 4704, determining whether the vehicle operating condition is consistent with the diagnostic execution condition and / or the diagnostic command value (e.g., determined based on the active diagnostic description). In response to a "yes" determination at operation 4704, process 4700 includes: operation 4604, providing the diagnostic command value to the endpoint in response to the active diagnostic condition; and operation 4606, commanding the actuator in response to the diagnostic command value.

[0278] refer to Figure 48 , schematically depicts an example process 4800 for commanding an actuator in response to a diagnostic command value. Example process 4800 includes: operation 4602, interpreting a policy including an active diagnostic description; and operation 4803, performing a diagnostic data collection operation in response to the active diagnostic description. Example process 4800 further includes: operation 4604, providing a diagnostic command value to an endpoint in response to the active diagnostic condition; and operation 4606, commanding an actuator in response to the diagnostic command value.

[0279] refer to Figure 49 , schematically depicts an example process 4802 for performing diagnostic data collection operations. The example process 4802 includes: an operation 4902 of processing the collected data (e.g., processing the payload and / or frame information of the message of the collected data); an operation 4904 of storing the collected processed data; and an operation 4906 of transmitting at least a portion of the stored data to an external device.

[0280] refer to Figure 50 , schematically depicts an example process 5000 for storing and / or transmitting a diagnostic confirmation value. The example process 5000 includes: operation 4602, interpreting a policy including an active diagnostic description; operation 4604, providing a diagnostic command value to an endpoint in response to the active diagnostic condition; and operation 4606, commanding an actuator in response to the diagnostic command value. The example process 5000 further includes: operation 5002, determining a diagnostic confirmation value; and operation 5004, storing the diagnostic confirmation value and / or transmitting the diagnostic confirmation value to one or more external devices.

[0281] refer to Figure 51 , schematically depicts an example process 5100 for commanding an actuator in response to a diagnostic command value. Figure 46In addition to the operations described above, the example process 5100 also includes an operation 5102 of determining whether the target device description points to a network address value for a target endpoint associated with the command actuator (e.g., if the target device description does not point to a network address value or points to an incorrect network address value, then operation 5102 determines "no"). In response to a "yes" determination at operation 5102, the process 5100 continues to operation 4604. In response to a "yes" determination at operation 5102, the process 5100 includes an operation 5104 of supplying or adjusting the network address value for the target endpoint, and then proceeds to operation 4604.

[0282] refer to Figure 52 , schematically depicts an example process 5200 for regulating communications between an external device and an endpoint of a network zone for a vehicle. The example process 5200 includes: an operation 5202 of interpreting a policy including an external communication value; and an operation 5204 of regulating communications between the endpoint of the network zone and the external device in response to the external communication value.

[0283] refer to Figure 53 , schematically depicting an example process 5204 for regulating communications between an external device and an endpoint of a network zone for a vehicle. The example process 5204 includes: an operation 5302, determining a type of an external communication value. In response to operation 5302 determining the type as an active diagnostic description, the process 5204 includes: an operation 5304, performing an active diagnostic operation. In response to operation 5302 determining the type as an active test description, the process 5204 includes: an operation 5306, performing an active test operation. In response to operation 5302 determining the type as a vehicle control command, the process 5204 includes: an operation 5308, performing a vehicle control operation. In response to operation 5302 determining the type as an active auxiliary operation, the process 5204 includes: an operation 5310, performing an active auxiliary operation. Example and non-limiting operations 5310 include one or more of: a service person contacting an operator of the vehicle, a service person command specifying an active diagnostic operation 5304, a service person command specifying an active test operation 5306, and / or a service person command specifying a vehicle control operation 5308. The example process 5204 further includes an operation 5312 of determining whether the external communication value indicates further action; and in response to the operation 5312 indicating "yes," the process 5204 includes returning to the operation 5302.

[0284] refer to Figure 54, schematically depicts an example process 5400 for regulating communications between an external device and an endpoint of a network zone for a vehicle. The example process 5400 includes: an operation 5402, interpreting a policy including an external communication value and a target device description. The example process 5400 further includes: an operation 5404, determining whether the target device description points to a network address value for a target endpoint. In response to a "yes" determination at operation 5404, the example process 5400 includes: an operation 5408, regulating communications between the external device and the endpoint of the network zone in response to the external communication value. In response to a "no" determination at operation 5404, the example process 5400 includes: an operation 5406, supplying or adjusting the network address value for the target endpoint; and operation 5406.

[0285] refer to Figure 55 , schematically depicting an example process 5500 for transmitting visualization data. The example process 5500 includes: an operation 5502 of interpreting vehicle communication data; an operation 5504 of generating visualization data in response to the vehicle communication data; and an operation 5506 of transmitting the visualization data.

[0286] refer to Figure 56 , schematically depicts an example process 5600 for transmitting visualization data. The example process 5600 includes: an operation 5502, interpreting vehicle communication data; an operation 5603, interpreting a data filter value; and an operation 5604, filtering at least a portion of the vehicle communication data based at least in part on the data filter value. The example process 5600 further includes: an operation 5504, generating visualization data in response to the vehicle communication data; and an operation 5506, transmitting the visualization data.

[0287] refer to Figure 57 , schematically depicts an example process 5700 for regulating inter-network, intra-network, and / or extra-vehicle communications. Example process 5700 includes: operation 5702, interpreting a policy including a network regulation description; operation 5704, configuring network interface circuitry in response to the network regulation description; and operation 5706, using the configured network interface circuitry to regulate inter-network communications and / or intra-network communications. Example process 5700 further includes: operation 5708, configuring gatekeeper interface circuitry in response to the network regulation description; and operation 5710, using the configured gatekeeper interface circuitry to regulate extra-vehicle communications.

[0288] refer to Figure 58, schematically depicts an example process 5800 for regulating inter-network, intra-network, and / or extra-vehicle communications. In addition to the operations described with respect to process 5700, example process 5800 includes: operation 5802, receiving a policy communication from an external device; and operation 5804, determining whether the policy is validated—e.g., whether the external device is authorized to update the policy, whether the system is capable of executing according to the policy, whether the policy violates any security criteria, whether performance of the policy would exceed data storage limits or communication limits, etc. In response to a "yes" determination at operation 5804, the example process includes: operation 5806, storing and / or updating the policy; and operation 5704 (which may further include configuring gatekeeper interface circuitry); operation 5706 (and / or operation 5710). In response to a "no" determination at operation 5804, example process 5800 optionally includes: operation 5807, providing a notification to one or more external devices, and example process 5800 continues to operation 5704.

[0289] refer to Figure 59 , schematically depicts an example process 5900 for regulating off-vehicle communications. Example process 5900 includes: operation 5902, interpreting a policy including a network usage permission description and / or an external data access description; operation 5904, configuring network interface circuitry in response to the network usage permission description; and operation 5906, using the network interface circuitry to regulate intra-network and / or inter-network communications. Example process 5900 includes: operation 5908, configuring gatekeeper interface circuitry in response to the external data access description; and operation 5910, using the gatekeeper interface circuitry to regulate off-vehicle communications.

[0290] refer to Figure 60 , schematically depicts an example process 6000 for regulating inter-network, intra-network, and / or extra-vehicle communications. The example process 6000 includes: an operation 6002 of determining authorization for a local communication device for regulated communications; 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 regulating intra-network, inter-network, and / or extra-vehicle communications using the network interface circuit and / or the gatekeeper interface circuit.

[0291] refer to Figure 61 , schematically depicts an example process 6100 for regulating off-vehicle communications. The example process 6100 includes: an operation 6102 of interpreting a policy including an external data quantity description; an operation 6104 of configuring a gatekeeper interface circuit in response to the external data quantity description; and an operation 6106 of regulating off-vehicle communications using the gatekeeper interface circuit.

[0292] refer to Figure 62, schematically depicts an example process 6200 for regulating off-vehicle communications. The example process 6200 includes: an operation 6202 of interpreting a policy including 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 regulating off-vehicle communications using the gatekeeper interface circuit.

[0293] refer to Figure 63 , schematically depicting an example process 6300 for regulating off-vehicle communications. The example process 6300 includes: an operation 6302 of interpreting a policy including an external data routing path corresponding to each of a plurality of local communication devices; an operation 6304 of configuring a gatekeeper interface circuit in response to the external data routing path; and an operation 6306 of regulating off-vehicle communications using the gatekeeper interface circuit.

[0294] refer to Figure 64 , schematically depicts an example process 6400 for regulating off-vehicle communications. The example process 6400 includes: an operation 6402 of interpreting a policy including an external data service description; an operation 6404 of configuring a gatekeeper interface circuit in response to the external data service description; and an operation 6406 of regulating off-vehicle communications using the gatekeeper interface circuit.

[0295] refer to Figure 65 , schematically depicts an example process 6500 for servicing a data request that includes access to an external device. The example process 6500 includes: an operation 6502, interpreting a data request that includes access to an external device; and an operation 6504, determining whether the external DNS includes an external device. In response to a "yes" determination at operation 6504, the example process 6500 includes: an operation 6506, servicing the data request using an external address value from the external DNS. In response to a "no" determination at operation 6504, the example process 6500 includes: an operation 6508, accessing an external DNS outside the vehicle to determine an external address value for the external device; and an operation 6510, servicing the data request using the external address value from the external DNS outside the vehicle.

[0296] refer to Figure 66 , schematically depicts an example process 6600 for providing off-vehicle communications using a selected network zone trajectory. The example process includes: operation 6602, providing off-vehicle communications using the selected network zone trajectory; and operation 6604, performing data configuration operations on the off-vehicle communications based on the network zone trajectory. The example operation 6604 includes one or more of: upsampling, downsampling, data processing, payload processing, frame processing, encapsulation operations, and / or data rate management operations.

[0297] refer to Figure 67, schematically depicting an example process 6700 for providing out-of-vehicle communications using a selected QoS value. The example process 6700 includes an operation 6702 of providing out-of-vehicle communications using a selected QoS value, and an operation 6704 of performing distribution of communications between out-of-vehicle portals and / or APNs based on the QoS value.

[0298] refer to Figure 68 , schematically depicting several illustrative examples of message conversion and / or message encapsulation embodiments. Figure 16 The examples are illustrative to illustrate certain aspects of the present disclosure, but are not limited to the present disclosure. In certain embodiments, Figure 68 The operations depicted in FIG may be performed in whole or in part by a CEG, a CES, a conversion circuit, and / or a CND, and in some embodiments, Figure 68 The operations depicted in the example can be regulated by CND. A first example message conversion 6802 includes a message from a first network having a payload 6810 and other frame information 6808. The other frame information may include a header, trailer aspects, and / or end bits, and may further be determined by the relevant protocol, network type, source endpoint, destination endpoint, or other aspects as known in the art. In some embodiments, the payload 6810 may be message data, a data value expressed by the message, or other information that is considered the content of the message. However, in some embodiments, for certain operations, during certain operating conditions, and / or for certain endpoints, the payload 6810 may be some other aspect of the message. For example, a network monitoring operation may utilize a timestamp, acknowledgment information, source and / or destination information, or other portions of a message as a payload. The example message conversion 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 may include an identifier (e.g., source or destination), a timestamp, or other information that allows endpoints on disparate networks to be abstracted from knowledge of each other. In some embodiments, the payload 6810 may be processed, for example, to change the units utilized, the bit depth (e.g., 2 bytes versus 4 bytes), the precision expressed, floating point or fixed point conversion, etc.

[0299] A second example message transformation 6804 includes the original messages 6808, 6810, and is completely encapsulated within a new frame 6812, e.g., to provide the target endpoint with the original message as provided by the original source (e.g., to allow previously developed algorithms to operate as is without having to transform into a new message; to allow certain network monitoring operations to utilize the entirely original message, etc.). In some embodiments, the original payload 6810 or message frame 6808 can be processed, e.g., as previously described, with the source identifier, timestamp, etc. updated to a new transformation that is transformed to abstract the endpoint from each other, but provide otherwise equivalent or systematically aligned information.

[0300] The third example message transformation 6806 includes the original message 6808, 6810 with an adjusted payload 6814. The adjustment of the payload 6814 can include transforming the payload 6814 in some manner (e.g., a corrected value, a value based on virtual sensing or modeling of the original payload 6810, upsampling or downsampling the payload 6810, etc.), and can additionally or alternatively include processing of the payload. The third example message transformation 6806 describes the adjusted payload 6814, although adjustments can additionally or alternatively be performed on other portions of the message frame 6808. In the third example message, a new frame 6812 is applied for transmission to another network.

[0301] refer to Figure 69 , schematically depicts a schematic depiction of the operation of downsampling a sequence of messages 6902. Figure 69 In the example of , a message sequence 6902 (e.g., in the example, a series of five communications) is received, for example, at a network interface circuit of one of the network gateway devices. Figure 69 In the example of , the downsampling operation is responsive to any downsampling operation described herein, such as to match a receiving endpoint data rate, provide data represented by message 6902 at a scheduled rate, manage bandwidth on the vehicle's network and / or for off-vehicle communications, maintain buffer memory, or for any other purpose, including any downsampling operation of the present disclosure. Figure 69 In the example of , the downsampling device 6904 generates a transformed sequence of messages 6908 (e.g., as Figure 16 and related disclosures and / or processed in accordance with any other message conversion and / or message processing operations set forth herein), the downsampling device 6904 can be a conversion circuit, a network interface circuit, a CND, a circuit associated with a CND, a circuit regulated by a CND, and the like. For clarity of description, Figure 69The example depicts a transformed sequence of messages 6908. However, the transformed sequence of messages 6908 may not all exist simultaneously, for example, as messages are transformed and sent, they may be removed from a cache, deleted, expire, etc. The sequence of messages 6908 is depicted to illustrate aspects of the present disclosure. Additionally or alternatively, the transformation of messages 6908 may be performed after a downsampling operation is performed, for example, to reduce utilization of processing resources. For example, some of the messages may be eliminated as part of the downsampling prior to performing the transformation operation (e.g., replacement of frame portions or metadata, encapsulation, processing of payload and / or frame portions, etc.). In Figure 69 In the example of FIG. 6 , a downsampled sequence of messages 6906 is provided and transmitted, for example, to a different network gateway device, to a different network of the vehicle from which the first sequence of messages 6902 was received, to an external device (e.g., a service tool, a cloud server, an operator's mobile device, etc.), and / or stored on a memory storage device on the vehicle (e.g., for later data collection operations, as part of stored vehicle data, etc.). In the example, the five messages of the original sequence 6902 are downsampled into three messages of the downsampled sequence 6906. The downsampling operation can include converting selected messages from the original sequence 6902, for example, by converting the original 10 ms data stream 6902 into a downsampled 20 ms data stream 6906 using every other data message. Additionally or alternatively, the downsampling operation can include interpolation of data messages between the original values. For example, where 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 include taking the message closest in time, or performing an interpolation operation (e.g., applying a linear fit, a spline fit, a polynomial fit, or other interpolation operation across data points) to use as the downsampled message 6906.

[0302] As utilized herein, a spanning data point or value indicates a data value in a downsampled message 6906 that is not aligned in time with the corresponding original data message 6902. As utilized herein, a non-spanning data point or value indicates a data value in a downsampled message 6906 that is aligned in time with or synchronized with the corresponding original data message 6902. It should be understood that the original data message 6902 and the downsampled message 6906 may additionally or alternatively have a phase difference, and accordingly, in certain embodiments, any or all of the original data messages 6902 may be non-spanning messages. In some embodiments, certain messages of the original data messages 6902 may be treated as non-spanning or synchronization data messages even in the presence of a phase difference between the original data messages 6902 and the downsampled messages 6906, for example, to provide a baseline downsampled message 6906 stream that follows (e.g., in the time domain) a progress character of the original data message 6902 stream, and / or where any phase difference can be ignored for the purposes of a device or operation that utilizes the downsampled messages 6906 (e.g., where such device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference).

[0303] In a further example, synchronized data values ​​(e.g., every fifth data value when converting from 40 ms to 100 ms) may be utilized directly, or a fitting function may be utilized (e.g., to provide a smoothed, filtered, or otherwise processed stream of data values). In some embodiments, it may be desirable to utilize actual data values ​​provided from the first data stream 6902 as downsampled data values ​​6906, where minor transient behavior from different time steps is not relevant to how the downsampled data values ​​6906 are utilized, or where timestamp data is also transmitted with the message and the differential time steps between messages can be accounted for in the process of utilizing the downsampled data 6906. In some embodiments, it may be desirable to utilize smoothed data values ​​that simulate the temporal response behavior of the underlying data, which may be managed using interpolated data for spanning data values ​​(e.g., a process responsive to the rate of change in the downsampled data 6906, such as a threshold test on the rate of change). In certain embodiments, such as where a downstream process 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 process, and interpolation operations (or smoothing, filtering, or moving averages) may be performed to generate both spanned and non-spanned data values ​​6906. In certain embodiments, the downsampled data message 6906 may further include metadata or other embedded information indicating whether the message corresponds directly to the original data message 6902 or is a processed message (e.g., to allow for more than one use for the downsampled data message 6906, for diagnostic operations on the device that provided the original data message 6902, and / or for any other purpose).

[0304] It can be seen that Figure 69 The downsampling operation allows communication between devices and / or processes with different data rate capabilities, expectations and / or usage of downsampled data. In addition, Figure 69 The downsampling operation allows for a reduction in network utilization while providing sufficient data for devices and / or processes to perform their intended functions, as well as having a desired time domain response (e.g., derivative behavior, integral behavior, step change response, etc.) for proper functioning of devices and processes that may depend on the time dynamics of the transmitted data values. As can be seen, Figure 69The downsampling operation allows for progressive updates of communication aspects (e.g., components, devices, processes, and / or operations that communicatively interact with a network and / or other components, devices, processes, and / or operations) of mobile applications having a mix of network configurations and / or legacy communication aspects (e.g., having lower data rate capabilities and / or data rate expectations, and / or different network protocols, features, message types, etc.) and updated communication aspects (e.g., having higher data rate capabilities and / or data rate expectations, and / or different network protocols, features, message types, etc.).

[0305] refer to Figure 70 , depicts a schematic depiction of the operation of upsampling a sequence of messages 7002. Figure 70 In the example of , a message sequence 7006 (eg, in the example, a series of three communications) is received, for example, at a network interface circuit of one of the network gateway devices. Figure 70 In the example of , the upsampling operation is responsive to any upsampling operation described herein, such as to match a receiving endpoint data rate, provide data represented by message 7006 at a scheduled rate, manage bandwidth on the vehicle's network and / or for off-vehicle communications, maintain buffer memory, or for any other purpose, including any upsampling operation of the present disclosure. Figure 70 In the example of , the upsampling device 7004 generates a transformed sequence of messages 7008 (e.g., as Figure 16 and related disclosures and / or processed in accordance with any other message conversion and / or message processing operations described herein, and), the upsampling device 7004 can be a conversion circuit, a network interface circuit, a CND, a circuit associated with a CND, a circuit regulated by a CND, and the like. For clarity of description, Figure 70 The example depicts a transformed sequence of messages 7008. However, the transformed sequence of messages 7008 may not all exist simultaneously. For example, as messages are transformed and sent, they may be removed from the cache, deleted, expired, etc. The sequence of messages 7008 is depicted to illustrate aspects of the present disclosure. Additionally or alternatively, the transformation of messages 7008 may be performed after performing an upsampling operation, for example, to reduce utilization of processing resources.

[0306] For example, some of the messages may be eliminated or adjusted as part of upsampling before performing conversion operations (e.g., replacement of frame portions or metadata, encapsulation, processing of payload and / or frame portions, etc.). Figure 70In the example of FIG. 7 , an upsampled sequence of messages 7002 is provided and transmitted, for example, to a different network gateway device, to a different network of the vehicle from which the first sequence of messages 7006 was received, to an external device (e.g., a service tool, a cloud server, an operator's mobile device, etc.), and / or stored on a memory storage device on the vehicle (e.g., for later data collection operations, as part of stored vehicle data, etc.). In the example, the three messages of the original sequence 7006 are upsampled into the five messages of the upsampled sequence 7002. The upsampling operation can include converting selected messages from the original sequence 7006, for example, changing the original 50 ms data stream 7006 into the upsampled 20 ms data stream 7002 by inserting one or more generated messages 7010. Additionally or alternatively, the upsampling operation can include interpolation and / or extrapolation of data messages between the original values. For example, where the original data stream 7006 is a 50 ms data stream and the upsampled data stream 7002 is a 20 ms data stream, upsampling may include obtaining the message closest in time, or performing interpolation and / or extrapolation operations (e.g., applying linear fitting, spline fitting, polynomial fitting, moving average, and / or low-pass filtering progress between available data points and / or between available data points and a predicted next data point) to serve as the upsampled message 7002.

[0307] As utilized herein, a spanning data point or value indicates a data value in the upsampled message 7002 that is not aligned in time with the corresponding original data message 7006. As utilized herein, a non-spanning data point or value indicates a data value in the upsampled message 7002 that is aligned in time with or synchronized with the corresponding original data message 7006. It should be understood that the original data message 7006 and the upsampled message 7002 may additionally or alternatively have a phase difference, and accordingly, in certain embodiments, any or all of the original data messages 7006 may be non-spanning messages. In some embodiments, certain messages of the original data messages 7006 may be treated as non-spanning or synchronization data messages even in the presence of a phase difference between the original data messages 7006 and the upsampled messages 7002, for example to provide a baseline upsampled message 7002 stream following (e.g., in the time domain) a progress character of the original data message 7006 stream, and / or where any phase difference can be ignored for purposes of a device or operation utilizing the upsampled messages 7002 (e.g., where such device or operation has a response time, required reaction time, etc. that is significantly greater than the magnitude of any such phase difference).

[0308] In a further example, synchronized data values ​​(e.g., every other data value when converting from 50 ms to 20 ms, such as a 0 ms phase value and a 100 ms phase value) can be utilized directly, or a fitting function can also be utilized (e.g., to provide a smoothed, filtered, or otherwise processed stream of data values). In some embodiments, it may be desirable to utilize actual data values ​​provided from the first data stream 7006 as upsampled data values ​​7002, for example, where minor transient behavior from different time steps is not relevant to how the upsampled data values ​​7002 are utilized, or where timestamp data is also transmitted with the messages and accordingly, the differential time steps between messages can be accounted for in the process of utilizing the upsampled data 7002. Accordingly, in some embodiments, each message of the upsampled data value 7002 can directly correspond to one or more of the first data stream 7006 values ​​(e.g., selecting a synchronized one, a closest one, and / or a most recent one of the first data stream 7006 values ​​(e.g., retaining the transmitted value until the next value is available)).

[0309] In some embodiments, it may be desirable to utilize smoothed data values ​​that emulate the temporal response behavior of the underlying data (e.g., the original message 7006), which may be managed using interpolated / extrapolated data for spanning data values ​​(e.g., responsive to the rate of change in the upsampled data 7002, such as a threshold test on the rate of change) and / or also for non-spanning data values. In some embodiments, such as where a downstream process is particularly sensitive to temporal variations 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 process, and interpolation / extrapolation operations (and / or smoothing, filtering, and / or moving averages) may be performed to generate both spanning and non-spanning upsampled data values ​​7002. In some embodiments, the non-spanning upsampled data values ​​7002 are utilized directly (e.g., to provide an upsampled data 7002 stream with the actual content of the data message 7006 as much as possible), and the spanning upsampled data values ​​are processed as described herein. In some embodiments, all original messages 7006 are provided in the upsampled data 7002 stream, with additional non-spanned messages added to achieve the data rate of the upsampled data 7002 stream (e.g., to provide all original messages 7006 and otherwise support the upsampled rate). In some embodiments, the upsampled data message 7002 may further include metadata or other embedded information indicating whether the message corresponds directly to the original data message 7006 or a processed message (e.g., to allow for more than one use of the upsampled data message 7002, for diagnostic operations on the device providing the original data message 7006, and / or for any other purpose).

[0310] In some embodiments, the spanning upsampled data value 7002 can be determined based on a predicted value between the non-spanning data values, which can be performed based on a virtual sensor (e.g., a model of the value utilizing other information available in the system) and / or an extrapolation fit operation. In some embodiments, the determination of the spanning upsampled data value 7002 can additionally or alternatively include providing a predicted and / or interpolated / extrapolated value that provides an expressed rate of change of the upsampled data value 7002 determined based on the original data value 7006 and / or adjusted based on characteristics of the device, component, operation, and / or process utilizing the upsampled data value 7002. For example, the upsampling operation can include performing a predictive operation and / or interpolation / extrapolation to determine a rate of change for the value; and providing a final spanning upsampled data value 7002 that provides a predicted rate of change for the upsampled data value 7002. In some embodiments, the operation of providing the upsampled data value 7002 includes the operations of determining a rate of change (or derivative) determination operation in a device utilizing the upsampled data value 7002, and adjusting the rate of change of the upsampled data value 7002 in response to parameters of the rate of change determination in the device—e.g., accounting for data related to a time step (e.g., ΔT / 5 ms or a change in temperature every 5 milliseconds) and / or a time constant (e.g., a time constant of a low-pass filter, a time constant implicit in a moving average calculation, etc.) utilized for the derivative operation, wherein the upsampled data value 7002 is adjusted to provide a desired response in a rate of change calculation to be performed on the upsampled data value 7002. For example, in the case where the upsampled operation has a significant difference in time step between the original data value 7006 and the upsampled data value 7002 (e.g., 50 ms to 5 ms), operations such as linear interpolation / extrapolation of the data value may provide significant distortion to, for example, the output of a low-pass filter operated by a device utilizing the upsampled data value 7002, which may be configured to process true 5-ms data. Accordingly, in an example, the operation of upsampling the raw data values ​​7006 may include adjusting the raw data values ​​7006 based on a predicted response of a 5-ms device of a determined value, which may provide a significant difference in the trajectory of the upsampled data values ​​7002 between non-spanning data points relative to a simple linear extrapolation, a moving average, etc. The operation of adjusting the expressed rate of change may be performed for the upsampled data 7002 and / or for the downsampled data 6906, or may be omitted.

[0311] In certain embodiments, configuration information for upsampling and / or downsampling operations, such as whether to utilize non-spanned raw data values ​​6902, 7006 directly, metadata to be stored with the upsampled and / or downsampled data 7002, 6906, processing operations to be performed on spanned and / or non-spanned data values, whether to transmit all raw data values ​​6902, 7006, operations to provide for rates of change expressed in the upsampled and / or downsampled data 7002, 6906, and / or parameters (e.g., filter constants, derivative operations, etc.) determined by rates of change in devices utilizing the upsampled and / or downsampled data 7002, 6906, may be provided in whole or in part at design time (e.g., when configuring the mobile application and various network communications devices with which the mobile application is to be used), and / or may be provided or updated during runtime operation. In some embodiments, one or more aspects of the configuration information for upsampling and / or downsampling operations may be provided as part of a policy, configuration directive, and / or configuration table that may be accessible to CND 108 regulating communications between devices on a separate network for mobile applications. In some embodiments, one or more aspects of the configuration information for upsampling and / or downsampling operations may include default values ​​that may be adjusted and / or updated, including as part of a policy, configuration directive, and / or configuration table.

[0312] refer to Figure 71 , schematically depicts an example system for controlling inter-network communications, intra-network communications, and / or extra-vehicle communications using a scheduled policy scheme. The example system includes a vehicle 102 having at least one network ( Figure 71 In the example of FIG. 7 , a first network zone 7102 and a second network zone 7104 are configured; a policy manager circuit 7106 that interprets a policy 7108 including external data communication parameters (such as an external data routing description and / or an external data service description). The example system includes: a configuration circuit 7110 that configures a gatekeeper interface circuit 7120 in response to the policy 7108 and regulates communications between endpoints of the network zones 7102 and 7104 and an external communication portal 7116. The external communication portal 7116 is selectively coupled to an external device 7118. The external communication portal 7116 includes: the external communication portal 7116 as set forth herein, including at least information about Figure 41 Any one or more of the examples depicted and related descriptions. Figure 71In the example of , the gatekeeper interface circuit 7120 is depicted as being coupled to the external communication portal 7116. However, the gatekeeper interface circuit 7120 may regulate communications in any manner, such as by further configuring the network interface circuits 7112, 7114 to allow selected communications and / or communications with selected processing, encapsulation, data file formats, communication protocols, authorizations, and / or any other regulating descriptions as described throughout this disclosure. Figure 71 In the example of FIG, the policy manager circuit 7106, the configuration circuit 7110, and the network interface circuits 7112, 7114 are depicted as being located on the CND 108. As described elsewhere herein, the CND 108 may provide instructions or otherwise regulate components, and the depicted components (and / or the CND 108) may be distributed elsewhere on the vehicle 102, separate in whole or in part from the CND 108.

[0313] refer to Figure 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 circuitry 7110 configures the gatekeeper interface circuitry 7120 in response to the default policy value 7202 if the primary policy value 7204 and / or the secondary policy value 7206 are not present (and / or if the primary policy value 7204 and / or the secondary policy value 7206 are not valid), in response to the primary policy value 7204 if the secondary policy value 7206 is not present (and / or valid), and in response to the secondary policy value 7206 if present (and valid). In the event that a policy is present (and / or if a policy is determined to be valid), the example configuration circuitry 7110 applies the policy in the order described (e.g., using the secondary policy value 7206 if present and ignoring any remaining policy values ​​7204, 7202). If the policy values ​​are compatible and / or consistent, the example configuration circuitry 7110 applies more than one policy value (e.g., applies the secondary policy value 7206, and applies portions of the primary policy value 7204 that do not conflict with the secondary policy value 7206). Figure 72 In the example of , the default policy value 7202 can be a permanently stored policy (e.g., a policy stored with primary executable instructions stored on a computer-readable medium, the primary executable instructions thus including instructions for at least a portion of the operation of the CND 108 and / or associated circuitry). In some embodiments, the primary policy value 7204 and / or the secondary policy value 7206 comprise policy values ​​that are easily updated in real time, for example, stored as a data file (e.g., provided at a selected memory location, a selected OS logical location according to certain naming conventions, 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), stored as part of a calibration set, a pruning set, etc.

[0314] An example master policy 7204 is a policy provided by a tool, such as a manufacturer tool, OEM tool, service tool, or the like. In certain embodiments, a secondary policy value 7206 is a downloaded policy value, such as a policy value received from an external device via an external communication portal, as well as a policy value received from a web-based tool, cloud application, or the like. The recited examples are non-limiting, and any of the policy values ​​may be received from any external communication portal. An example implementation includes a default policy value 7202 that is provided upon initialization of the CND 108 or related control components (e.g., a first image file applied to the controller housing executable portion of the CND 108, the policy manager circuit 7106, etc.) and is generally not updated except, for example, as part of an overall instruction set update (e.g., updating executable instructions provided for the CND 108 and / or portions thereof). An example implementation includes a master policy value 7204 that is provided upon manufacturing, assembly, or other initial pre-mission service or assembly operation on a vehicle. Example implementations include secondary policy values ​​7206 provided as downloaded operations and / or provided during service operations, trim and / or application configuration operations (e.g., by an OEM, body builder, etc.). Utilization of scheduled policy values ​​7202, 7204, 7206 allows for implementation of a minimum capability (and / or minimum risk) policy, thereby providing sufficient capability for devices of a vehicle to communicate externally, e.g., to download and / or act on replacement policies, such as primary policy values ​​7204 and / or secondary policy values ​​7206. Utilization of scheduled policy values ​​allows various stakeholders in manufacturing, remanufacturing, reconfiguration, service, sale or transfer, mission change, or other vehicle-related operations to ensure that policy requirements (e.g., permissions for local communication devices to communicate within a network, across a network, store data, and / or communicate with external devices) are met, while facilitating policy updates, implementations, and interfaces for third parties, owners / operators, fleet owners, etc. to adjust policy values ​​and resulting communication regulation operations. Utilization of scheduled policy values ​​7202, 7204, 7206 allows for easy policy updates, validation, and implementation. Utilization of scheduled policy values ​​7202, 7204, 7206 allows for real-time adjustment of communication policy and / or reconfiguration of regulatory responses with low impact on the vehicle's mission (e.g., without controller reset operations, adjustments to the main executable instruction file, etc.), for example, to adjust policy in response to regulatory characteristics such as geography (e.g., location of the vehicle), jurisdiction (e.g., jurisdictional location of the vehicle), and / or operations where direct control of the vehicle may not be available (e.g., after an accident, towing event, sale or other transfer, etc.).In some embodiments, the scheduled policy values ​​7202, 7204, 7206 can be applied by one of the multiple devices at different times, e.g., a default policy value 7202 applied by a first device, a primary policy value 7204 applied by a second device, and a secondary policy value 7206 applied by a third device. In some embodiments, a given external device can 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 relative to the application of an earlier version. In some embodiments, more than one version of a given policy value can exist (e.g., secondary policy value 7206), with a selected one of the versions being utilized in response to operating conditions (e.g., vehicle operating conditions, geography, jurisdiction, non-nominal conditions, and / or fault code conditions, etc.). In some embodiments, a given policy value 7206 may include more than one version of aspects of the policy, such as providing different data collection operations for a given local communication device, controller, flow, application, endpoint, etc., and selecting versions of aspects of the policy in response to operating conditions.

[0315] refer to Figure 73, example 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, etc.). Example policy 7108 further includes an authorization description 7304, which may include any type of authorization as referenced throughout this disclosure, including network utilization, authorization of data access descriptions, subscription authorization, external access authorization, policy change and / or update authorization, etc. Authorization description 7304 may reference a flow, a local communication device, an external device, an endpoint, a network zone, an application, a service group, a vehicle controller, a source address, a destination address, any other regulated component, and / or entities associated with any of these, users, and / or user roles. Example policy 7108 includes a firewall configuration description 7306, which may include, for example, a description utilized by a firewall implementation device (e.g., a gateway interface circuit, a CND, and / or an external communication portal) to determine how to operate the firewall. In some embodiments, the firewall configuration description 7306 includes a default behavior description (e.g., handling for unknown or unspecified communications, such as blocking communications from unknown external devices or addresses), a data access description (e.g., components of the system with permission to contact certain addresses, certain types of communicati...

Claims

1. A system for off-vehicle communication control, comprising: A vehicle having at least one network zone, wherein the at least one network zone includes a first network zone and a second network zone of a different type than the first network zone; a policy manager circuit structured to interpret policies including a local domain name server DNS, an authorization description, and a firewall configuration description; configuration circuitry structured to configure the gatekeeper interface circuitry in response to the policy; as well as The guard interface circuit is between: between the at least one network zone and an external communication portal selectively coupleable to an external device, between the first network region and a transceiver selectively couplable to an external device, and between the second network area and the transceiver; The gatekeeper interface circuit is structured as follows: regulating communications between endpoints of the at least one network zone and an external communications portal; regulating communications between endpoints and the transceiver in the first network zone; and Communications between endpoints and the transceiver in the second network zone are regulated. 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. The system of claim 3 , wherein the policy further comprises an external data quantity description. The system of claim 4 , wherein the policy further comprises an external data service description. The system of claim 5 , wherein the authorization description further comprises an external data access description.

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

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 system of claim 4, wherein the external data quantity description comprises at least one data limit selected from a plurality of data limits consisting of: the amount of data transferred corresponding to the selected time period; the amount of data transmitted corresponding to the selected vehicle operating condition; the amount of data transferred corresponding to the data provider associated with the application; Bandwidth share for external communication portals; The amount of bandwidth for external communication portals; Bandwidth share of the channel for external communication portals; or The amount of bandwidth for the external communication portal's channel.

11. The system of claim 1 , further comprising: first network interface circuitry structured to mediate communications between endpoints of the first network zone and endpoints of the second network zone; wherein the policy further includes a network regulation description; and The configuration circuit is further structured to: configure the first network interface circuit in response to the network regulation description; and further configure the gatekeeper interface circuit in response to the network regulation description.

12. The system of claim 11, wherein the network regulation description comprises a data request permission description, the data request permission description comprising a data value associated with a data requester, wherein at least a portion of the data requester comprises an endpoint of at least one of the first network zone or the second network zone, and wherein the first network interface circuit is further structured to regulate communications in response to the data request permission description.

13. The system of claim 1, wherein the policy further comprises an external data access description.

14. The system of claim 1, further comprising: The strategies further include: External data routing description; and default policy value; and Wherein the configuration circuitry is further structured to determine whether the policy includes a primary policy value, and in response to determining that the policy includes the primary policy value, utilize the primary policy value instead of the default policy value.

Images