System, method and apparatus to support mixed network communications on vehicle

Abstract

To provide a system, method and apparatus to support mixed network communications on a vehicle.SOLUTION: An example system includes a vehicle having a first network zone and a second network zone that are of different types, a converged network device (CND) interposed between the zones. The CND includes a policy management circuit that interprets a policy including a network regulation description, a configuration circuit that configures network interface circuits in response to the policy, and the interface circuits that regulate communications between end points of the network zones.SELECTED DRAWING: Figure 20

Description

[Technical Field]

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0015] Without being limited to any other aspect of the present disclosure, embodiments herein provide for operation of a system having multiple networks and where end points are distributed across the networks, and for operation utilizing data, communications, and / or commands for end points without requiring specific knowledge of the location, functionality, and / or data configuration of at least some of the applications, circuits, and / or other operators within the system. Embodiments herein provide for network management configuration, enabling changes in location of end points within the system, adaptation to system failures or abnormal operation, and / or updates to the system, which may occur during processes such as manufacturing, bodywork, overhaul, upfit or upgrade, part replacement, maintenance, campaigns, part changes, and / or changes in industry standards. Embodiments herein provide for network status and / or performance monitoring of on-vehicle networks, including monitoring when the vehicle is intermittently connected to an outside device. Embodiments herein provide for configuration changes to monitor operations, including changes to monitored networks, monitored parameters, and monitor event execution. Embodiments herein provide for monitoring operations of end points, network communications, communications between specific end points (on the same or distinct networks), and these configurations. Embodiments herein provide for the control, coordination, and / or support of network traffic both on a particular network and between networks. Embodiments herein provide for the selective distribution of network management, monitoring, and control functions, including incorporating functionality into existing controllers, providing distribution of functionality between controllers, providing redundancy and abnormal operation support, variability of redundancy and abnormal operation support between similar systems while supporting full functionality, and combinations thereof. Embodiments herein provide for the monitoring of endpoint devices, network communications, and communications between particular endpoints, where a monitoring application or device communicates with a first network and monitors a second network.Embodiments herein provide for monitoring any network, network zone, flow, device group, virtual group, etc. that may exist within the system.

[0016] Embodiments herein include operation of a mixed network system that provides application mission support, including control, monitoring, data collection, configuration, and / or updating. Embodiments herein include enabling active control from a device, application, or controller that can communicate with any network of the system for devices, endpoints, controllers, flows, device groups, vehicle functions, or vehicle applications, etc., that may reside on any network of the vehicle and / or be distributed across more than one network of the vehicle. Additionally or alternatively, embodiments herein can support active control of devices after changes to controlled devices, endpoints, controllers, flows, device groups, vehicle functions, and / or vehicle applications with selective levels of knowledge, including no knowledge of the changes by the controlling device, application, or controller. Embodiments herein include enabling active monitoring, service event execution, and / or test execution from a device, application, or controller that can communicate with any network of the system for devices, endpoints, controllers, flows, device groups, vehicle functions, or vehicle applications, etc., that may reside on any network of the vehicle and / or be distributed across more than one network of the vehicle. Additionally or alternatively, embodiments herein may support active monitoring of devices, service event execution, and / or test execution following changes to controlled devices, endpoints, controllers, flows, device groups, vehicle functions, and / or vehicle applications with selective levels of knowledge, including levels of having no knowledge of the changes by the controlling device, application, or controller.

[0017] Embodiments herein support mixed networks and / or scalable network topologies including mixed networks and / or multiple instances of a given network type (e.g., disjointed and / or partially disjointed networks). The number and placement of networks can be provided to support at least any aspect of vehicle design, operation, and life cycle management, including allowing for a mix of legacy and new devices, separating the physical location and functionality of networks, modifications to vehicles during service, maintenance, upgrades, and / or facelifts, and / or reducing design and / or integration effort and / or compartmentalization. Embodiments herein support, but are not limited to, dual-zone and / or n-zone network architectures.

[0018] Embodiments herein support the aggregation of control that may otherwise be distributed around a system, for example, to reduce the number of controllers and / or processing devices that must be installed, integrated, and / or interfaced between, to reduce physical risk to the networked system, to reduce the cost of the networked system, and / or to reduce the footprint of the networked system (e.g., to reduce the overall footprint of the vehicle and / or enable a full or partial shift of the footprint to another system in the vehicle).Embodiments herein support data management and access in a mixed network vehicle, including abstracting data providers from data consumers, enforcing data authorization, security, and compartmentalization, reducing network traffic, and managing functionality disparities between endpoints, devices, controllers, flows, device groups, networks, etc.

[0019] Embodiments herein provide for the configuration of a mixed network control device including interfaces for enabling configuration of network management applications, network control applications, and network monitor applications. Accordingly, embodiments herein provide for the configuration of mixed network control subcomponents including interfaces to devices, such as those that interface between networks and facilitate collection, encapsulation, and / or processing of communications from a first network for communication onto a second network. Embodiments herein provide for the configuration of a mixed network control device and / or subcomponents that selectively utilize external tools (e.g., service tools, manufacturing tools, diagnostic tools, consumer devices, etc.) that can be directly connected to the mixed network control device or coupled via a wireless, cellular, or other communicative connection. In certain embodiments, the configuration tools herein can be external tools, web applications, mobile applications, dedicated or proprietary applications, or combinations thereof.

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

[0021] [Figure 1] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 2] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 3]FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 4] 1 is a schematic diagram of a centralized network device (CND). [Figure 5] 1 is a schematic diagram of a centralized network device (CND). [Figure 6] 1 is a schematic diagram of a centralized network device (CND). [Figure 7] 1 is a schematic diagram of a centralized network device (CND). [Figure 8] 1 is a schematic diagram of a centralized network device (CND). [Figure 9] 1 is a schematic diagram of a centralized network device (CND). [Figure 10] FIG. 1 is a schematic diagram of a configurable Ethernet switch. [Figure 11] FIG. 1 is a schematic diagram of a configurable edge gateway. [Figure 12] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 13] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 14] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 15] FIG. 1 is a schematic diagram of an exemplary system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 16] FIG. 10 depicts an example operation for processing a message. [Figure 17] FIG. 10 depicts an example operation for downsampling a message. [Figure 18] FIG. 10 depicts an example operation for upsampling a message. [Figure 19]1 is a schematic diagram of a system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 20] FIG. 1 is a schematic diagram depicting network zones within a distributed risk profile. [Figure 21] 1 is a schematic diagram of a system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 22] FIG. 1 is a schematic diagram depicting a distributed CND with network redundancy circuits. [Figure 23] 1 is a schematic diagram of a system for coordinating an on-vehicle network in accordance with certain embodiments of the present disclosure. [Figure 24] 1 is a schematic flow diagram illustrating an exemplary procedure for adjusting inter-network communication coordination. [Figure 25] 1 is a schematic flow diagram illustrating an exemplary procedure for encapsulating communications. [Figure 26] 1 is a schematic flow diagram illustrating an exemplary procedure for processing a communication. [Figure 27] 1 is a schematic diagram of a system for providing data services; [Figure 28] 1 is a schematic diagram of a system for coordinating an on-vehicle network. [Figure 29] 1 is a schematic diagram of a system for coordinating an on-vehicle network. [Figure 30] 1 is a schematic diagram of a system for coordinating an on-vehicle network. [Figure 31] 1 is a schematic diagram of a system for coordinating an on-vehicle network. [Figure 32] FIG. 1 is a schematic diagram illustrating an exemplary network coordination component. [Figure 33] FIG. 1 is a schematic diagram illustrating an exemplary network coordination component. [Figure 34] FIG. 1 is a schematic diagram illustrating an exemplary network coordination component. [Figure 35] 1 is a schematic flow diagram of a procedure for publishing a data service. [Figure 36]1 is a schematic flow diagram of a procedure for encoding a first network data set into a second network data set. [Figure 37] 1 is a schematic flow diagram of a procedure for providing network status data. [Figure 38] 1 is a schematic flow diagram of a procedure for mirroring a port. [Figure 39] 1 is a schematic flow diagram of a procedure for encoding a first network data set. [Figure 40] 1 is a schematic flow diagram of a procedure for performing an active test procedure. [Figure 41] 1 is a schematic flow diagram of a procedure for coordinating a network of vehicles. [Figure 42] 1 is a schematic flow diagram of a procedure for coordinating vehicle inter-network communications. [Figure 43] 1 is a schematic flow diagram of a procedure for encoding an Ethernet-based data set. [Figure 44] 1 is a schematic flow diagram of a procedure for providing network status data. [Figure 45] 1 is a schematic flow diagram of a procedure for performing control operations. [Figure 46] 1 is a schematic flow diagram of a procedure for providing an external message value. [Figure 47] FIG. 1 is a schematic diagram of a CND. [Figure 48] FIG. 1 is a schematic diagram of an end point of a network responsive to actuator command values. [Figure 49] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 50] 1 is a schematic flow diagram of a procedure for commanding an actuator. [Figure 51] 1 is a schematic flow diagram of a procedure for commanding an actuator. [Figure 52] 1 is a schematic flow diagram of a procedure for commanding an actuator. [Figure 53] 1 is a schematic flow diagram of a procedure for transmitting collected data to an external device. [Figure 54] 1 is a schematic flow diagram for performing active diagnostics. [Figure 55] 1 is a schematic flow diagram of a procedure for commanding an actuator. [Figure 56] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 57] 1 is a schematic flow diagram of a procedure for coordinating network communications for a vehicle. [Figure 58] 1 is a schematic flow diagram of a procedure for coordinating network communications for a vehicle. [Figure 59] 1 is a schematic flow diagram of a procedure for coordinating network communications for a vehicle. [Figure 60] 1 is a schematic diagram of a system for coordinating vehicle network communications using planned policies. [Figure 61] 1 is a schematic diagram of a system for providing visualization data of a network of vehicles. [Figure 62] FIG. 2 is a schematic diagram of an example of a local DNS table. [Figure 63] FIG. 2 is a schematic diagram of an example of vehicle communication data. [Figure 64] FIG. 1 is a schematic diagram of an example of visualization data. [Figure 65] FIG. 1 is a schematic diagram of an example of visualization data. [Figure 66] FIG. 1 is a schematic diagram of an example of visualization data. [Figure 67] FIG. 1 is a schematic diagram of an example of visualization data. [Figure 68] FIG. 1 is a schematic diagram of an example of visualization data. [Figure 69] FIG. 2 is a schematic diagram of a visualization management controller. [Figure 70] 1 is a schematic flow diagram of a procedure for providing visualization data. [Figure 71] 1 is a schematic flow diagram of a procedure for providing visualization data. [Figure 72] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 73]FIG. 2 is a schematic diagram of an example policy. [Figure 74] FIG. 2 is a schematic diagram of an example policy. [Figure 75] FIG. 2 is a schematic diagram of an example policy. [Figure 76] 1 is a schematic flow diagram of a procedure for coordinating network communications for a vehicle. [Figure 77] 1 is a schematic flow diagram of a procedure for providing visualization data. [Figure 78] 1 is a schematic flow diagram of a procedure for updating a policy. [Figure 79] 1 is a schematic diagram of a system for coordinating network communications of a vehicle; [Figure 80] FIG. 2 is a schematic diagram of an example policy. [Figure 81] 1 is a schematic flow diagram of a procedure for coordinating network communications for a vehicle. DETAILED DESCRIPTION OF THE INVENTION

[0022] Referring to Figure 1, an exemplary system generally illustrates aspects of an embodiment of the present disclosure. The exemplary system includes an application 102 (e.g., a vehicle) having a first network 104 and a second network 106. As used herein, a network should be understood broadly and can include one or more aspects such as hardware implementation (e.g., wire and wiring configuration, applicable standards, e.g., connectors, insulation, shielding, wire requirements, e.g., standard dimensions, stranding arrangement, coaxial arrangement, etc.), implementation of any layers (e.g., from the ISO 7 layer model, e.g., application layer, presentation layer, session layer, transport layer, network layer, data link layer, and / or physical layer, although a given network can have fewer layers and / or layers organized in a distinctly different manner), and / or can be all or partially wired or wireless. Without being limited to any aspect of the present disclosure, exemplary, non-limiting networks include a Controller Area Network (CAN), a Media Oriented Systems Transport (MOST) network, a Local Interconnect Network (LIN), a FlexRay network, a Time Triggered Protocol (TTP) network, a Low Voltage Differential Signaling (LVDS) network, and / or an Ethernet implementation network. In certain embodiments, one or more networks can be an electrical signal zone (e.g., a device that provides data and / or receives commands as electrical signals such as voltage values, frequency values, and indicated resistance values) such as a sensor or actuator electrically coupled to an interpreting device, which has the capability to receive information from and / or pass information or commands to one or more electrical devices on the electrical signal zone.

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

[0024] The exemplary system further includes a converged network device (CND) 108 interposed between the first network 104 and the second network 106 and structured to facilitate communication between the first network 104 and the second network 106. The CND 108 interposed between the networks 104, 106 passes communications between the networks 104, 106, including embodiments that receive communications from the first network 104 and translate the communications destined for the second network 106 (e.g., encapsulate all or a portion of the communication into a message for the second network 106, and / or transform aspects of the communication such as device addresses, bit depth for the data, and / or unit values ​​for the data, and / or add or remove aspects of the communication such as priority information, message delivery requests or requirements, industry standard information such as message identifiers, etc.). In certain embodiments, the CND 108 may not physically pass communications or may pass only portions of communications, but may otherwise control other devices (e.g., switches, routers, gateways, or repeaters) that regulate, manage, grant permissions, throttle messages, or otherwise perform operations to pass communications between networks. Thus, a CND 108 inserted between networks 104, 106 may, in certain embodiments, be physically located between networks 104, 106, and communications to and from networks 104, 106 may be physically received by components of the CND 108. In certain embodiments, a CND 108 inserted between networks 104, 106 may have visibility into communications on networks 104, 106 and a control device to regulate message passing between these networks. In certain embodiments, a CND 108 inserted between networks 104, 106 may have visibility of endpoints on networks 104, 106 and a control device for coordinating the passing of messages between the endpoints of each network 104, 106.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0040] In certain embodiments, the CND 108 determines which parameters to expose and provide, and the conditions for providing them, based on stored data that defines the permissions and / or capabilities of devices, endpoints, applications, flows, etc. In certain embodiments, the CND 108 also accesses stored data that defines processing or conditioning operations on the data, such as encapsulation operations (e.g., for passing CAN messages to an Ethernet network), unit conversions, and timestamp definitions. In certain embodiments, the CND 108 determines authorization for applications and / or flows that are on-vehicle, off-vehicle (e.g., operating on external devices such as 110, 114, 204), or a combination of on-vehicle and off-vehicle. In certain embodiments, the CND 108 can support prioritization of data flows, including the rate at which devices provide or receive information, based on the prioritization or other parameters of the associated devices, endpoints, applications, flows. In certain embodiments, the CND 108 can support differential prioritization based on vehicle status or operating conditions, for example, using a first priority scheme during startup operations, a second priority scheme during runtime operations, a third priority scheme when the vehicle is moving, etc. In certain embodiments, the CND 108 can respond to any defined vehicle condition, such as charging operations, regeneration operations, aftertreatment operations, control strategies (e.g., cruise vs. driver control), emergency events, fault conditions, or service conditions, etc.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

[0062] 10, there is shown an exemplary first network gateway device 404. In the example depicted in FIG. 10, the first network gateway device 404 is a configurable Ethernet switch that includes an Ethernet network interface 416 (or Ethernet network interface circuitry) having several ports 414 for communication with an Ethernet network. The ports 414 may be physical ports, logical ports, or a combination thereof.

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

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

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

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

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

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

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

[0070] A second exemplary message transformation 1604 includes an original message 1608, 1610, fully encapsulated within a new frame 1612 to provide, for example, the original message provided by the original source to the target endpoint (e.g., allowing previously developed algorithms to operate as is without the need to transform into a new message, providing certain network monitoring operations that utilize the complete original message, and the like). In certain embodiments, either the original payload 1610 or the message frame 1608 can be processed, e.g., updating the source identifier or timestamp, etc., to a new convention that processes and transforms the aforementioned payloads to extract endpoints from each other, but otherwise providing equivalent or systematically adjusted information.

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

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

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

[0074] In yet another example, synchronized data values ​​(e.g., every fifth data value when going from 40 ms to 100 ms) can be used directly, or a fitting function can be used (e.g., to provide a smoothed, filtered, or otherwise processed stream of data values). In certain embodiments, it may be desirable to use actual data values ​​provided from the first data stream 1702 as the downsampled data values ​​1706 when either minor transient behavior from various time steps is not relevant to how the downsampled data values ​​1706 are used, or when timestamp data is further communicated with the messages so that processing utilizing the downsampled data 1706 can satisfy discriminatory time steps between messages. In certain embodiments, it may be desirable to use smoothed data values ​​that simulate the time response behavior of the underlying data, and these data values ​​can be controlled using interpolated data with respect to the interpolated data values ​​(e.g., processing dependent on the rate of change of the downsampled data 1706, e.g., threshold testing on the rate of change). In certain embodiments, for example, when downstream processing is particularly sensitive to time variations in the data message 1702 (e.g., the derivative portion of a PID controller), it may be desirable to ensure that all downsampled data messages 1706 are generated from the same processing and may perform interpolation operations (or smoothing, filtering, or moving averages) to generate both interpolated and non-interpolated data values ​​1706. In certain embodiments, the downsampled data message 1706 may further include metadata or other embedded information indicating whether it directly corresponds to the original data message 1702 or is a processed message (e.g., to allow for more than one use of the downsampled data message 1706, diagnostic operations for the device providing the original data message 1702, and / or any other purpose).

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

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

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

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

[0079] In yet another example, the synchronized data values ​​(e.g., every other data value when going from 50 ms to 20 ms, e.g., a 0 ms phase value and a 100 ms phase value) can be used directly, or a fitting function can be used (e.g., to provide a smooth, filtered, or otherwise processed stream of data values). In certain embodiments, it may be desirable to use actual data values ​​provided from the first data stream 1806 as the upsampled data values ​​1802, for example, if minor transient behavior from various time steps is not relevant to how the upsampled data values ​​1802 are used, or if timestamp data is further communicated with the messages, so that differential time steps between messages can be satisfied in the processing that utilizes the downsampled data 1802. Thus, in certain embodiments, each message of the upsampled data values ​​1802 can directly correspond to one or more of the values ​​of the first data stream 1806 (e.g., selecting the closest synchronized and / or most recent of the values ​​of the first data stream 1806 (e.g., holding the communicated value until the next value is available)).

[0080] In certain embodiments, it may be desirable to utilize smoothed data values ​​that simulate the time response behavior of the underlying data (e.g., original message 1806), and these data values ​​may be controlled using interpolated / extrapolated data with respect to interpolated data values ​​(e.g., processing that depends on the rate of change of the upsampled data 1802, e.g., threshold testing on the rate of change) and / or with respect to non-interpolated data values. In certain embodiments, for example, when downstream processing is particularly sensitive to time changes in the data messages 1806 (e.g., the derivative portion of a PID controller), it may be desirable to ensure that all upsampled data messages 1802 are generated from the same processing, and that interpolation / extrapolation operations (and / or smoothing, filtering, and / or moving averages) can be performed to generate both interpolated and non-interpolated upsampled data values ​​1802. In certain embodiments, the non-interpolated upsampled data values ​​1802 are utilized directly (e.g., to provide a stream of upsampled data 1802 that has, to the greatest extent possible, the actual content of the data messages 1806), and the interpolated upsampled data values ​​are processed as described herein. In certain embodiments, all of the original messages 1806 are provided in the stream of upsampled data 1802, and additional non-interpolated messages are added to provide the data rate of the stream of upsampled data 1802 (e.g., to provide all of the original messages 1806 and also support the upsampling rate). In certain embodiments, the upsampled data messages 1802 may further include metadata or other embedded information indicating whether they correspond directly to the original data messages 1806 or are processed messages (e.g., to allow for more than one use of the upsampled data messages 1802, diagnostic operations for the device providing the original data messages 1806, and / or any other purpose).

[0081] In certain embodiments, the interpolated upsampled data value 1802 can be determined based on a predicted value between non-interpolated data values, which can be performed based on a virtual sensor (e.g., a value model utilizing other information available in the system) and / or an extrapolation fitting operation. In certain embodiments, determining the interpolated upsampled data value 1802 additionally or alternatively includes providing a predicted value and / or an interpolated / extrapolated value that provides a representation of a rate of change for the upsampled data value 1806 determined according to the original data value 1806 and / or adjusted according to characteristics of the device, component, operation, and / or procedure utilizing the upsampled data value 1802. For example, the upsampling operation can include performing a prediction operation and / or interpolation / extrapolation to determine a rate of change for the value and providing a final interpolated upsampled data value 1802 that provides a predicted rate of change for the upsampled data value 1802. In certain embodiments, the operations providing the upsampled data values ​​1802 include determining a rate-of-change (or derivative) determination operation within the device that utilizes the upsampled data values ​​1802, and adjusting the rate of change of the upsampled data values ​​1802 in response to the rate-of-change parameter determination within the device, for example, interpreting the data with respect to the time step utilized in the derivative operation (e.g., ΔT / 5 ms or 5 ms per temperature change) and / or time constant (e.g., a low-pass filter time constant, a time constant inherent in a moving average calculation, etc.), where the upsampled data values ​​1802 are adjusted to provide a desired response to the rate-of-change calculation to be performed thereon. For example, if the upsampling operation has a significant time step difference between the original data values ​​1806 and the upsampled data values ​​1802 (e.g., 50 ms vs. 5 ms), operations such as linear interpolation / extrapolation of data values ​​performed by a device that utilizes the upsampled data values ​​1802 and can be configured to process true 5 ms data may significantly distort the output of a low-pass filter.Thus, in this example, the act of upsampling the original data values ​​1806 may include adjusting the original data values ​​1806 according to the expected response of a 5ms device determining the values, thereby providing a significant difference in the trajectory of the upsampled data values ​​1802 between non-interpolated data points compared to simple linear extrapolation or moving averages, etc. The act of adjusting the rate of change representation may be performed with respect to the upsampled data 1802 and / or the downsampled data 1706, or may be omitted.

[0082] Configuration information regarding the upsampling and / or downsampling operations, such as whether the non-interpolated original data values ​​1702, 1806 are used directly, metadata stored with the upsampled and / or downsampled data 1802, 1706, processing operations performed on the interpolated and / or non-interpolated data values, whether all original data values ​​1702, 1806 are communicated, operations that provide rate-of-change representations of the upsampled and / or downsampled data 1802, 1706, and / or rate-of-change determining parameters (e.g., filter constants, differentiation operations, etc.) within devices that utilize the upsampled and / or downsampled data 1802, 1706, can be provided in memory storage accessible to the controller and / or circuitry that performs the upsampling and / or downsampling operations. Any such configuration information can be provided in whole or in part at design time, e.g., when including the mobile application and its devices in communication with various networks, and / or can be provided or updated during runtime operation. In certain embodiments, one or more aspects of the configuration information regarding upsampling and / or downsampling operations may be provided as configuration instructions as part of a policy and / or as a configuration table that may be accessible to CND 108, which coordinates communications between devices on separate networks of mobile applications. In certain embodiments, one or more aspects of the configuration information regarding upsampling and / or downsampling operations that are included as part of a policy, configuration instructions, and / or configuration tables may include default values ​​that may be adjusted and / or updated.

[0083] 19 , an exemplary system that may form part of a mobile application 1902 or a vehicle includes a first network zone 1904 of a vehicle having a first interconnected number of endpoints 1906 and a second network zone 1908 having a second interconnected number of endpoints 1910. The exemplary system includes a CND 1912 interposed between the network zones 1904, 1908 to coordinate communication between the endpoints 1906 and 1910. In the example depicted in FIG. 19 , the first network zone 1904 is a first network, the second network zone 1908 is a second network, and the networks 1904, 1908 are networks having different network types. In the example depicted in FIG. 19 , the first network zone 1904 includes a common data bus 1905, such as a CAN bus, and the second network zone 1908 utilizes a distributed topology in which multiple devices 1910 are in communication with a switch 1914, which may be, for example, a configurable Ethernet switch (CES). 19 , a configurable edge gateway 1916 (CEG) communicates with a first network zone 1904 and can read and / or provide messages to a common data bus 1905. In the example depicted in FIG. 19 , the CEG 1916 communicates with a CES 1914 on a second network zone 1908 and can appear to the CES 1914 as an end device in the second network zone 1908 and / or can connect to physical and / or logical ports in the second network zone 1908.

[0084] In the example depicted in FIG. 19 , the CND 1912 performs operations to coordinate communications between the endpoints 1906, 1910 by configuring the operation of the CEG 1916 and / or the CES 1914. The arrangement depicted in FIG. 19 is a schematic diagram for clarity of this description and depicts distinct components for the CND 1912, the CEG 1916, and the CES 1914. However, the CND 1912, the CEG 1916, and the CES 1914 may all or partly be combined and provided in the same housing and / or on the same circuit board, and / or all or partly subdivided. Additionally or alternatively, one or more or all of the CND 1912, the CEG 1916, and / or the CES 1914 may be co-located with another controller within the mobile application 1902, for example, a vehicle controller and / or a controller connected to the endpoint 1910. Although network zones 1904, 1908 are shown having separated physical components, network zones 1904, 1908 may be logically separated (e.g., as separate virtual networks on a single physical backbone) and / or may be separated in whole or in part by a combination of physical and / or logical structures. The exemplary embodiment includes physically separated network zones 1904, 1908 as illustrated. The exemplary embodiment includes a first network zone 1904 as a CAN bus network and a second network zone 1908 as an Ethernet-based network. The exemplary embodiment includes the first network zone 1904 as a legacy network with endpoints 1906 that are legacy and / or legacy-compatible devices, and the second network zone 1908 with endpoints 1910 that are newer, modern, upgraded, and / or migrated devices.

[0085] Exemplary operations for coordinating communications between endpoints 1906, 1910 include, but are not limited to, operations described below. Coordinating operations can be performed on endpoints, connection endpoints, and / or network zones. Connection endpoints can be connected according to flows, applications, services, controllers, vehicle functions, source addresses for communications, and / or destination addresses for communications. In certain embodiments, applications, services, and / or flows can be given identifiers as an implementation for associating related components, such as endpoints. Coordinating operations can be performed by, but are not limited to, a CND, a network gateway, a network interface circuit, and / or a gateway interface circuit. Although coordination operations are described in the context of certain exemplary coordinating devices throughout this disclosure, embodiments can be configured with other devices that perform coordination. Exemplary communication and / or coordination operations include: Providing communication (bidirectional) between a first endpoint 1906 and a second endpoint 1910, including including the communication (e.g., protocols, message information, metadata, parameter units, etc.) tailored to a receiving network zone and / or endpoint device; encapsulating a message from a first network zone 1904 and providing the encapsulated message to a second network zone 1908; determining whether a requesting device (and / or associated flow) on one of the network zones (1904, 1908) has permission to request communication from a device on another of the network zones, and providing the communication in response to the permission determination; adjusting at least one of the data rate, the required resolution, and / or the required response time of communications between devices of these network zones based on the authorization decision for the requesting device, the communication capabilities of the requesting device and / or the provider device, and / or the network performance parameters of one or both network zones (e.g., current available bandwidth, absolute or current network capabilities, network utilization, etc.), and / or a priority value for communications associated with the requesting device (and / or the associated flow); performing upsampling and / or downsampling operations on the data communicated between the network zones; mirroring communications from a first endpoint 1906 to a port in a second network zone 1908, including encapsulating, structuring, processing, and / or upsampling or downsampling the mirroring target communications; providing the communications from the first endpoint 1906 to devices coupled to the second network zone 1908, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices, and / or where providing the communications includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communications and / or may unicast, multicast, and / or provide the provided communications as a subscription service; providing the communication from the second end device 1910 to a device coupled to either the first network zone 1904 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 monitor device, and / or where providing the communication includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communication and / or may unicast, multicast, and / or provide the provided communication as a subscription service; providing communications from devices coupled to the second network zone 1908, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices, to the first endpoint 1906, and / or where providing the communications includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communications, and / or the provided communications may be unicast, multicast, and / or provided as a subscription service; ○ Further, providing the communication as a command value (e.g., setting a setpoint, target value, or threshold value responsive to the command value), for example, when the first endpoint 1906 performs an operation related to a mission of the mobile application responsive to the command value; providing communications from devices coupled to the second network zone 1908, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices, to the first endpoint 1906, and / or where providing the communications includes encapsulating, structuring, processing, and / or upsampling or downsampling the provided communications, and / or the provided communications may be unicast, multicast, and / or provided as a subscription service; ○ Further, providing the communication as a test execution value, for example, when the first endpoint 1906 executes an operation related to an active text execution operation of the mobile application in response to the command value (e.g., performing a certain operation for a service test or an active diagnostic operation, etc.); providing communications from the first endpoint 1906 to several second endpoint 1910 devices, where the provided communications are configured to satisfy a superset of the requirements of the second endpoint 1910 devices (e.g., data rate, resolution, units, etc.) and the provided communications can be unicast, multicast, and / or provided as a subscription service; parsing communication values ​​from a first device (e.g., the first endpoint 1906, the second endpoint 1910, and / or a device coupled to the network zones 1904, 1908, e.g., a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device), determining a target device (e.g., a communication recipient and / or a communication provider responsive to the communication value) responsive to the parsed communication value, and including a communication of the target communication recipient and / or communication provider responsive to the parsed communication value; For example, the communication values ​​may include generic and / or standard component identifiers (e.g., turbine temperature, front passenger door actuator, etc.), and the CND 1912 may determine respective endpoints 1906, 1910 corresponding to the component identifiers according to the current configuration of the mobile application, and may further determine the routing, encapsulation, and processing of communications to translate between the first device and the target device, etc. For example, such operations may enable devices, service personnel, or other requestors to change the configuration and placement of devices on a network zone without having to track the specific configuration and placement of the devices; Additionally or alternatively, such operations may include CND 1912 storing configuration information responsive to configuration changes (e.g., replacement or movement of a device from one network zone to another, changes to the device's communication parameters or capabilities, etc.) and / or performing runtime decisions to establish device location, identity, configuration, communication parameters, and / or communication capabilities that can be utilized during runtime operations, stored for subsequent use, and / or stored as a default configuration subject to further updates; performing any one or more of the above operations with respect to a group or subgroup of devices, for example, where multiple devices are aggregated with respect to a single endpoint 1906, 1910, but other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) in communication with the network zones 1904, 1908 can be treated as separate devices; For example, such operation allows for multiple configurations, updates, and / or upgrades of a mobile application where a first configuration has two (or more) devices using separate endpoints 1906, 1910 and a second configuration has two (or more) devices (and / or two devices aggregated into a single device) utilizing a single endpoint 1906, 1910. Exemplary and non-limiting embodiments include aggregation of multiple sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) communicating through a single interface to a network zone 1904, 1908, and / or replacing interfaces of multiple components behind a single network interface (e.g., a single communication device such as an edge gateway or configurable edge gateway that interfaces to a single network zone 1904, 1908 as a single endpoint 1906, 1910 and manages communications for the associated devices). In yet another example, such operation enables devices to communicate across multiple network zones despite configuration changes, supports upgrades and updates regarding device relationships with endpoints 1906, 1910, and supports backward compatibility (e.g., subsequent configuration and subsequent inter-device control distribution when operation of CND 1912 enables a predecessor system with a distinctly different configuration to support the latest configuration and / or inter-device control distribution); Additionally or alternatively, such operations may include the CND 1912 storing configuration information responsive to configuration changes (e.g., involvement of a single endpoint between more than one device and a network zone, aggregation of devices, etc.) and / or performing runtime decisions to establish device locations, identities, configurations, communication parameters, and / or communication capabilities, and / or aggregation status of devices, which may be utilized during runtime operations, stored for subsequent use, and / or stored as a default configuration subject to further updates; performing any one or more of the above operations with respect to groups or subgroups of devices, for example, where the devices are distributed among more than one endpoint 1906, 1910, but other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and / or network monitor devices) in communication with the network zones 1904, 1908 are able to treat the devices as a single device; For example, such operation allows for multiple configurations, updates, and / or upgrades of a mobile application where a first configuration includes devices using a single endpoint 1906, 1910 and a second configuration has devices (or portions thereof) utilizing more than one endpoint 1906, 1910 (and / or previously aggregated devices including two or more separate devices in the second configuration). An exemplary and non-limiting embodiment includes separating a group of sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) communicating to the network zones 1904, 1908 through a single endpoint 1906, 1910 into one or more sensors (and / or subgroups of multiple sensors each having a separate endpoint) 1906, 1910. In yet another example, such operation provides for devices to communicate across multiple network zones despite configuration changes, support upgrades and updates to device associations with endpoints 1906, 1910, and support backward compatibility (e.g., subsequent configurations and inter-device control distribution where operation of CND 1912 enables an earlier system with a distinctly different configuration to support a later configuration); Additionally or alternatively, such operations may include the CND 1912 storing configuration information responsive to a configuration change (e.g., splitting multiple devices behind a single endpoint on a single network zone into more than one endpoint and / or splitting across more than one network zone), and / or performing runtime decisions to establish device locations, identities, configurations, communication parameters, and / or communication capabilities, and / or aggregation status of devices, which may be utilized during runtime operations, stored for subsequent use, and / or stored as a default configuration subject to further updates; Implementing a service specification architecture in which the CND 1912 determines available services (e.g., data parameters available for communication, command values ​​available for execution, and / or configurations thereof, such as speed information, units, resolution, precision, accuracy, availability descriptions, dependent data, and / or operating conditions), publishes available services, and / or determines subscribed clients (e.g., devices, flows, and / or endpoints) for available services; Additionally or alternatively, such operation may include the CND 1912 determining permissions and / or authorizations to publish available services, to view available services (and / or portions of available services), and / or to subscribe to available services; Additionally or alternatively, such operation may include the CND 1912 determining the subscribed entity as an endpoint, device, flow, and / or external device, e.g., a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and / or a network monitor device; Additionally or alternatively, such operations may include the CND 1912 determining a priority for service-specific communications, which may depend on the publishing device, endpoint, or associated flow, and / or on the subscribing device, endpoint, or associated flow; Additionally or alternatively, such operation may include the CND 1912 adjusting service specification architecture operation in response to operating conditions (e.g., mobile application operating conditions, network status of one or more affected network zones, communication status of one or more external devices, etc.); Additionally or alternatively, such operation may include the CND 1912 accessing stored information indicating available services, public parameters (such as permissions, priorities, associated operating conditions, etc.), and / or subscription entity information; Additionally or alternatively, such operations may include the CND 1912 updating the stored information in response to one or more of received updates, such as policy descriptions, service configuration descriptions, runtime updates from endpoints, devices, and / or flows, such as, but not limited to, updates performed during operations such as starting or stopping a mobile application; Additionally or alternatively, such operations include the CND 1912 implementing a service specification architecture based on run-time operations with or without storing information and / or updating stored information; and / or Additionally or alternatively, enabling updates to stored information, runtime updates to stored information, and / or runtime operations implementing a service specification architecture in response to priorities and / or permissions for devices, endpoints, and / or flows requesting the updates and / or runtime implementation; Additionally or alternatively, operation of the example CND 1912 may include adjusting any one or more of the above-described operations in response to operating conditions of the mobile application (e.g., adjusting high power operation, high transient operation, stop operation, start operation, selective operating modes, communication operation during certain operations such as professional operation, power take off (PTO) operation, charging operation, cruise control operation, autonomous vehicle operation). The adjustments to communications may 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 ​​during certain operating conditions as data capture events), quantitative (e.g., controlling communication speed, network zone utilization, external device communication speed, etc.), or a combination thereof (e.g., controlling communication speed for certain communication types, etc.), and may include increasing or decreasing communication capabilities according to operating conditions and / or communication types (e.g., allowing reduced communication capabilities of a device during shutdown operation, but increasing communication capabilities of an external device during the shutdown operation, increasing communication capabilities of a device for certain devices or flows, but reducing communication capabilities of the device for other devices or flows during startup operation); Additionally or alternatively, the exemplary CND 1912 may perform any one or more of the operations described above in response to a degradation of the network zone (e.g., loss of throughput, loss of communication with one or more endpoints in the network zone, injection of noise onto or presence of noise on the network zone, physical failure of at least a portion of the network zone, etc.), a failure condition of one or more devices (e.g., the CND 1912 may adjust a data source for a failed device, adjust a data rate for a failed device, implement a backup data source for a failed device, or implement a backup for data provided to a failed device). and / or adjusting in response to abnormal operating conditions related to the mobile application, including conditions such as a loss of control function of the vehicle controller (e.g., when the vehicle controller is unable to perform its task, when the vehicle controller is unable to perform its task, or a portion thereof), rerouting data to an updater destination, or implementing an event-driven data collection scheme when a device failure is the event), or a loss of control function of the vehicle controller (e.g., when the loss of control function indicates that the vehicle controller lacks a data value to perform its task, when the vehicle controller has lost communication with the network zone to which it is connected, and / or when the loss of control function is an indication by the vehicle controller or another controller in the system that the vehicle controller is unable to perform its task or a portion thereof). Further example operations of the CND 1912 in response to an abnormal condition include one or more of the following: providing data values ​​to the vehicle controller from an alternative source (e.g., the data values ​​are from a different endpoint, network zone, etc., and this providing may include encapsulating, structuring, processing, and / or upsampling or downsampling the communications of the alternative source, thereby resulting in a communication equivalent to the original data value that was lost, or a replacement communication that may suffice as a back-up data value for the vehicle controller); providing data values ​​to the second vehicle controller to replace all or a portion of the lost control functionality of the vehicle controller with alternative source communications (e.g., having a distinctly different data rate, resolution, units, precision, etc.) or other data values ​​(e.g., where the second vehicle controller utilizes a distinctly different data set to perform full-functionality or alternative functionality), for example, where the second vehicle controller is configured to act as a backup to the vehicle controller and may be fully capable of performing the lost control functionality and / or may be capable of performing alternative operations in place of the lost control functionality (e.g., with more limited functionality), and the data values ​​provided to the second vehicle controller may be the same as the data values ​​provided to the vehicle controller; Additionally or alternatively, the CND 1912 may provide data from any network zone 1904, 1908 to the vehicle controller and / or second vehicle controller, which may be on any network zone 1904, 1908; suppressing communication of one or more data values ​​in response to an abnormal condition, for example, when a fault condition, loss of a device or endpoint, etc. indicates that one or more data values ​​are unavailable, when one or more data values ​​are of low priority in light of the abnormal condition, and / or when one or more data values ​​are indicated as corrupt in light of the abnormal condition (e.g., sensor values ​​from a sensor have a fault condition or a failure condition); shifting communications from a first network zone (e.g., a degraded network zone) to a second network zone when endpoints and / or devices are reachable through more than one network zone (e.g., when the zones are logically separated but physically coupled, when more than one physical path is available between the associated endpoints (see FIG. 15), and / or when a second vehicle controller and / or a second endpoint coupled to the second network zone has the capability to perform the operations (or a portion thereof and / or an alternative operation thereof) of a first vehicle controller and / or a first endpoint coupled to the first network zone); Repeating communication from a first network zone (e.g., a degraded network zone) onto a second network zone; o shifting an endpoint from a first network zone (e.g., a degraded network zone) to a second network zone, where, for example, the endpoint is physically coupled or coupleable to both a first network zone and a second network zone (e.g., where the separation between these network zones is logical, and / or where the endpoint is reachable through more than one network zone, as illustrated in FIG. 15 ), and the operations of CND 1912 include adjusting addressing operations, protocol operations, encapsulation operations, and / or any other operations that cause the shift of the endpoint, which may further include updating the location of the shifted endpoint to other devices / endpoints in the system or translating communications with other devices / endpoints in the system; combinations of these steps, such as shifting the endpoint from a first network zone to a second network zone, shifting the associated communication to the second network zone, and / or repeating the associated communication on the second network zone; Coordinating communications between endpoints in the first network zone (and / or one or more additional network zones) and external devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, network monitoring devices, driver devices, cloud computing devices, and / or third party applications), including any one or more of the operations described above, and / or restricting communications according to abnormal conditions of components of the system (e.g., endpoints, devices, flows, network zones, etc.), restricting communications according to operating conditions of the mobile application, permissions and / or priorities of the endpoints, associated flows, and / or external devices. limiting communications according to aggregate data values ​​(e.g., corresponding to the associated data service provider, endpoints, associated flows, and / or entities associated with any one or more of the foregoing) which may be aggregated according to time (e.g., daily, weekly, monthly, etc.), operating conditions (e.g., trips, events, etc.), and / or where the data values ​​include one or more of total data transmission / reception values, data rate values, and / or combinations thereof; and / or limiting communications according to external data access type (e.g., cellular, WiFi, Bluetooth, hardware / port connection, etc.); and / or Any one or a combination of two or more of the above.

[0086] The described operations of the CND 1912, in whole or in part, may be included in the embodiments recited throughout this disclosure. It will be understood that the permissions and / or priorities for any aspect, including endpoints, associated entities (e.g., owners, manufacturers, operators, service technicians, OEMs, third parties, etc.), flows, and devices (e.g., controllers, actuators, sensors, tools, and / or external devices, switches, gateways, etc.), may vary according to the operating conditions of the mobile application and / or the status of one or more devices (the same or different devices for which the permissions and priorities are considered). Furthermore, the permissions and / or priorities may vary according to the operations and / or communications being performed. For example, a given flow may have a high priority and / or permission level for viewing published available services, but only a low priority and / or permission level for publishing and / or subscribing to available services. In another example, a given endpoint may have a high priority for communicating data values ​​to another endpoint (e.g., on a distinctly different network zone) during one operating condition (e.g., high-power acceleration), but only a low priority for communicating data values ​​to other endpoints during another operating condition (e.g., steady-state cruise control operation). Priority, as used herein, generally relates to a comparison between competing rights over resources (e.g., network bandwidth, response time, data storage, access to limited data resources, etc.), whereas permission, as used herein, generally relates to the ability to perform a requested operation, e.g., the ability to request certain data, metadata, data rates, data storage, access to devices and / or external devices, etc. Thus, an aspect may have separate priorities and permissions, such as a high priority and a low permission level (e.g., the aspect has a high priority for accessing a limited number of data values, functions, etc.), or any other combination.

[0087] Resolution of conflicting priority rights can be accomplished using any of a number of techniques, such as always giving priority to the highest priority requester, providing weighted responses based on priority (e.g., providing information more often to higher priority requests than to lower priority requests), and / or utilizing a credit-based scheme that allows information to be provided to lower priority requests after a certain period and / or number of requests.

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

[0089] 20 , an exemplary system includes a first risk first network zone 1904 having a first risk exposure profile 2002 and a second network zone 1908 having a second risk exposure profile 2004. In the example depicted in FIG. 20 , the first risk exposure profile 2002 is distinct from the second risk exposure profile 2004.As utilized herein, a risk exposure profile, in at least one aspect, refers to a risk profile to which a potential associated component (e.g., first network zone 1904 and / or second network zone 1908 in the example depicted in FIG. 20 ) is subjected, such as geometric risk (e.g., risk due to location within the mobile application relative to the installed component), environmental risk (e.g., risk from environmental factors relative to the installed component, such as temperature, contaminants, NVH, EMI, heat transfer environment (e.g., exposure to radiant energy, conductive heat transfer, and / or convection or lack thereof), and / or exposure to environmental disturbances such as a service technician being hit or a tool being dropped, etc.), failure mode risk (e.g., exposure to a short circuit event, an open wire event, and / or exposure to a component of the mobile application (e.g., exhaust component, engine component, aftertreatment component, and / or any other component with failure-inducing energy such as high temperature, electrical potential, rotational energy, or mechanical energy, etc.) (e.g., a given risk may affect multiple areas or systems of a vehicle, and components located in or coupled to these areas may share the risk type, whereas components that are disconnected from these areas or systems may not share the risk type regardless of their proximity or other considerations); and / or prevailing disturbance risk (e.g., a given disturbance, such as a particular service event, operating condition, weather event, or abnormal charging voltage, may affect multiple areas or systems of a vehicle, and components located in or coupled to these areas may share the disturbance risk, whereas components that are disconnected from these areas or systems may not share the disturbance risk regardless of their proximity or other considerations).

[0090] In certain embodiments, the first risk exposure profile 2002 is distinct from the second risk exposure profile 2004 in at least one aspect of the risk exposure profile, such as being located in distinctly different locations on the vehicle (e.g., one on the left side and one on the right side), being designed so that a given environmental risk is unlikely to affect both network zones, being designed so that a given failure mode is unlikely to affect both network zones, being designed so that a possible risk (e.g., collision, accident, operational failure, abnormal component operation, etc.) is unlikely to affect both network zones, and / or being designed so that a possible disturbance is unlikely to affect both network zones. In certain embodiments, a difference in one risk aspect is sufficient for the risk exposure profiles to be distinctly different; for example, one or more failures (e.g., complete loss of power) may be likely to affect both network zones, while these network zones may still have distinctly different risk exposure profiles with respect to other potential failures. Furthermore, although such network zones may have exposure to the same type of risk, these network zones, such as a first network zone exposed to a frontal collision and a second network zone exposed to a rearward collision, can nevertheless be considered to have distinctly different risk profiles.

[0091] In the example depicted in FIG. 20 , the CND 1912 is inserted between a first network zone 1904 and a second network zone 1908 and is configured to coordinate communications between the network zones 1904, 1908. In the example depicted in FIG. 20 , the CND 1912 has the capability to communicate with the remaining one of the network zones 1904, 1908 if one of the network zones 1904, 1908 experiences a failure or degradation event. Accordingly, the CND 1912 has the capability to reroute communications away from the failed network zone 1904, 1908, for example, to a backup controller (not shown), another network zone (not shown), etc. The example depicted in FIG. 20 provides risk partitioning for the network zones 1904, 1908 and enables the design of redundancy and continued operation of a mobile application (whether in compliance with the mobile application's mission or in a reduced functionality operating state) if one of the network zones 1904, 1908 experiences a failure or degradation.

[0092] 21 , an example system includes a mobile application 1902 having a first network zone 1904, a second network zone 1908, and a third network zone 2108. The network zones 1904, 1908, 2108 can have distinctly different risk exposure profiles, and / or any two of the network zones 1904, 1908, 2108 can have distinctly different risk exposure profiles. The example system includes a CEG 2102 communicatively coupled to the first network zone 1904, a CES 2104 communicatively coupled to the second network zone 1908, and a second CES 2106 communicatively coupled to the third network zone 2108. In the example depicted in FIG. 21 , a CND 1912 is distributed, and a portion of the CND 1912 is configured to coordinate communications for each network zone 1904, 1908, 2108. The example set forth in FIG. 21 , showing components as a CEG 2102, a CES 2104, and a second CES 2106, is a non-limiting example, and network zones 1904, 1908, 2108 can be of any type, with communications being initiated by any component. In certain embodiments, corresponding operating components (CEG 2102, CES 2104, and CES 2106 in the example set forth in FIG. 21 ) can share the risk exposure profile associated with the associated network zones 1904, 1908, 2108, or can have distinctly different risk exposure profiles associated with the associated network zones 1904, 1908, 2108. Additionally or alternatively, corresponding portions of CND 1912 can share the risk exposure profile associated with the associated network zones 1904, 1908, 2108. The embodiment set forth in FIG. 21 illustrates risk partitioning into network zones and components, and the planned addition of redundancy between these network zones and components, which can be provided in any manner.For example, multiple networks of the same type (e.g., network zones 1908, 2108) may have distinctly different risk exposure profiles, whereas multiple networks of a single instance (e.g., network zone 1904) may have yet another risk exposure profile or a shared risk exposure profile with one of the other networks (e.g., network zones 1908, 2108), e.g., because it does not have an available backup network and is already a single point of failure mode in the system. In certain embodiments, one or more of the networks (e.g., network zone 2108) may be installed to have a very low risk exposure profile (e.g., in a central location insulated from environmental risks, disturbance risks, and / or failure mode risks, etc.) and may be configured to function as a backup for one or more other networks (e.g., network zone 1908). In certain embodiments, the configuration for performing backup operations includes one or more of: redundant connectivity to endpoints for other networks; provision of backup controllers and / or stored executable instructions for performing backup control operations; provision at associated operating components (e.g., CES2106) for performing data communication operations for other networks; and / or provision at associated CND portions 1912 for performing operations of any or all of the other CND portions 1912. In certain embodiments, any or all of the networks may be configured to perform backup operations for one or more or all of the other networks. In certain embodiments, one or more portions of CND 1912 may be co-located with associated ones of the operating components, located in a housing with associated ones of the operating components, and / or located on the same substrate as associated ones of the operating components.In certain embodiments, one or more portions of the CND 1912 can be co-located with a distributed controller throughout the vehicle, located in a housing with the distributed controller throughout the vehicle, or located on the same board as the distributed controller throughout the vehicle. In certain embodiments, one or more portions of the CND 1912 can be provided as executable instructions stored on another device (e.g., an operating component, a vehicle controller, and / or another controller), whereby a processor executing the instructions causes the device to perform one or more operations of the CND portion 1912. In the example depicted in FIG. 21 , the CES 2104 coordinates communications between the second network zone 1908 and the third network zone 2108, which communicate, for example, at a port of the CES 2106. In the example depicted in FIG. 21 , the CEG 2102 coordinates communications between the first network zone 1904 and the third network zone 2108, which communicate, for example, at a separate port of the CES 2106.

[0093] Exemplary, non-limiting network types for each network zone include one or more of 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, an Audio Video Bridging (AVB) compliant network, customized versions of any one or more of these, and / or proprietary versions of any one or more of these.

[0094] Referring to Figure 22, an exemplary apparatus for performing network redundancy operations is shown. The example set forth in Figure 22 is consistent with the embodiment set forth in Figure 21, but may be applied to any of the systems and / or mobile applications listed throughout this disclosure. The exemplary apparatus includes a network redundancy circuit 2202 that selectively provides regulation control commands 2204, where one or more CND portions 1912 implement inter-network communications 2206, 2208, 2210 between multiple network zones (e.g., 1904, 1908, 2108) of the mobile application in response to the regulation control commands 2204. Exemplary, non-limiting inter-network communications 2206, 2208, 2210 include rerouting data between network zones, shifting endpoints between network zones, a first CND portion assuming coordination of a different network zone connected to a second CND portion, utilizing alternative data sources and / or backup control operations, and / or operations shifting, mirroring, and / or suppressing one or more data values ​​between and / or on one or more network zones.

[0095] Exemplary, non-limiting coordination control directives 2204 include indications that one or more endpoints in a network zone are unavailable, that one or more endpoints in a network zone are in a failure condition, and / or that one or more endpoints in a network zone are unable to perform their respective endpoint mission operations and / or are providing unauthorized communications. In certain embodiments, coordination control directives 2204 include one or more of the following: directives to utilize alternate data sources and / or backup control operations, directives to shift endpoints between available network zones, and / or directives to shift, mirror, and / or suppress one or more data values ​​between and / or on one or more network zones. In certain embodiments, the coordination control command 2204 may include a list of status conditions such as "one of the network zones has failed" or other values ​​indicating the status of one or more endpoints or endpoints and / or network zones, in which case one or more CND portions 1912 implement communications in response to the coordination control command 2204 and / or control redundancy operation according to stored configuration information.

[0096] 23 , an exemplary mobile application 1902 includes a first network zone 1904, a second network zone 1908, a third network zone 2322, and a fourth network zone 2324. These network zones can be of any type. In the example depicted in FIG. 23 , the first network zone 1904 is a CAN network type, the second network zone 1908 is an Ethernet network type, the third network zone 2322 is an Ethernet network type, and the fourth network zone 2324 is an electrical signal zone. The exemplary network zones 1904, 1908, 2322, and 2324 have been selected to illustrate certain aspects of the present disclosure and are not limiting.

[0097] In the example illustrated in FIG. 23 , the CND 1912 communicates with a first CEG 1916 and provides communication between an end point in the first network zone 1904 and an end point in the second network zone 1908 by providing communication to a port of the first CES 1914; communicates with a second CEG 2308 and provides communication between an end point in the fourth network zone 2324 and an end point in the second network zone 1908 by providing communication to a port of the first CES 1914; communicates with the first CES 1914 that is communicatively coupleable to the second CES 2320; and coordinates communications between endpoints of network zones by communicating with the second CES 2320 to provide communications between endpoints in the third network zone 2322 and endpoints in the other network zones 1904, 1908, 2324 (through the second network zone 1908 in the example depicted in FIG. 23 ). The CND 1912 further coordinates communications between endpoints in the network zones 1904, 1908, 2322, 2324 and external communication devices 2326 by, for example, communicating permission information, priority information, etc. to the first CES 1914 and / or second CES 1916, which can selectively communicate with the external communication device 2326 (e.g., head unit). 23 is shown as being inserted between the CES 1914, 1916 devices and the external communication device 2326, the CES 1914, 1916 devices can be directly coupled to the external communication device 2326 and / or the external communication device 2326 can be coupled to a port on one of the network zones 1908, 2322. The example shown in FIG. 23 depicts a transmitter / receiver 2328 that performs communication operations with an external device (e.g., a cloud server, a service tool, a manufacturing tool, an operator device, etc.). In certain embodiments, the transmitter / receiver 2328 can be integrated with the external communication device 2326 and / or there can be more than one transmitter / receiver 2328.Additionally or alternatively, multiple external communication access paths may be available, such as, but not limited to, physical port access, WiFi transmitters / receivers, Bluetooth transmitters / receivers, etc., on one or more of the network zones 1904, 1908, 2322.

[0098] Although the CND 1912 is shown as a separate device, the CND 1912 may be co-located with a vehicle controller (not shown) and / or distributed across several devices, along with one or more of the network commissioning components 1916, 1914, 2308, 2320. The example depicted in Figure 23 further includes a network redundancy circuit 2202, shown separately for convenience of this description, that selectively provides coordination control commands and provides redundancy and data rerouting commands to the network commissioning components 1916, 1914, 2308, 2320 in response to degradation or loss of a network zone and / or its endpoints. An example operation of the network redundancy circuit 2202 includes routing communications from a first termination point 2302 on a first network zone 1904 to a second termination point 2304 on a second network zone 1908 (during normal operation) and changing the routing from the first termination point 2302 on the first network zone 1904 to a third termination point 2312 on a third network zone 2322 (e.g., in response to a failure or abnormal operation of the second termination point 2304).

[0099] An example operation of the CND 1912 includes providing differential priority and / or permission access to the second endpoint 2304 on the second network zone 1908 compared to the third endpoint 2306 on the second network zone 1908, where the differential priority and / or permission access relates to communication with the external communication device 2326, storage of data (e.g., in buffers and / or memory storage on either device of the mobile application 1902), and / or data communication throughput, collection speed, etc.

[0100] Exemplary operations of the CEG 2308 include performing analog-to-digital (A / D) processing of communications on the fourth network zone 2324. For example, the endpoint 2310 can be a sensor that provides an electrical signal representing a sensed value and / or an actuator that responds to an electrical signal from the CEG 2308. In certain embodiments, the endpoint 2310 can include more than one electrical signal, such as a diagnostic signal, a heart rate signal, or a status signal. In certain embodiments, the CEG 2308 performs signal processing of communications from the endpoint 2310, such as debouncing, filtering, saturation (e.g., setting aside high or low values ​​for diagnostic information), rescaling, linearization, or other operations. In certain embodiments, the CEG 2308 generates a processed electrical signal payload that may include one or more of: converting the electrical signal to a sensed value (e.g., pressure, temperature, speed, etc.); changing the units of the sensed value (e.g., from °F to K or °C); adjusting the bit depth of the sensed value (e.g., providing a 32-bit equivalent of a standard 16-bit value provided by the endpoint 2310, or a lookup table for the endpoint 2310); normalizing the sensed value (e.g., providing a value between 0 and 1 with a weight that matches the sensed parameter and / or providing a voltage equivalent for the sensed voltage, such as when an algorithm running on a receiving endpoint such as 2314 on the third network zone 2322 utilizes a different sensor with a different scale, etc.); applying a time shift to the sensed value (e.g., to compensate for sensor response time, network communication time, etc.); and / or converting the sensed value between floating point and fixed point and / or rescaling the sensor's fixed point value. Those skilled in the art, having the benefit of this disclosure and the information normally available when considering an electrical signal-based endpoint 2310 and a data destination endpoint (or any other endpoint), can readily determine the payload processing operations to be performed that will provide a payload tailored to the destination endpoint from the electrical signals provided by the considered endpoint 2310.It will be appreciated that payload processing can also be performed in reverse, e.g., taking an incoming payload from a communication and configuring electrical signals from the incoming payload (e.g., commands to adjust actuators, electrical signals that may not be configured for a particular endpoint 2310, etc.) for the endpoint 2310. The example CEG 2308 further generates a communication that is provided to a port of the CES 1914, e.g., by providing a communication frame, encapsulating the processed payload, and having a protocol configured for the second network zone 1908 (in this example). In certain embodiments, the CEG 2308 processes at least a portion of the communication frame by, for example, adjusting a timestamp (e.g., if the endpoint 2310 provides a timestamp that is not properly configured for the mobile application 1902), providing a timestamp (e.g., if a timestamp is desired but the endpoint 2310 does not provide one), preparing or adjusting a source indicator for the communication (e.g., if the endpoint 2310 does not have the capability to provide a source indicator and / or utilizes a source indicator that is not properly configured for the mobile application 1902), and / or preparing or adjusting a destination indicator for the communication.

[0101] Exemplary operations of the CEG 1916 include processing the payload of a communication from the terminating device 1906, 2302 and / or performing any other payload processing operations set forth in this disclosure. Exemplary operations of the CEG 1916 include encapsulating the payload of a communication from the terminating device 1906, 2302 and / or encapsulating all or a portion of the frames of the communication from the terminating device 1906, 2302 into a communication having a protocol configured for the second network zone 1908 (in this example). In certain embodiments, the encapsulated portions of the frames of the communication from the terminating device 1906, 2302 can be further processed, for example, to add or adjust a timestamp, to add or adjust a source indicator, and / or to add or adjust a destination indicator. In certain embodiments, the encapsulation of a frame or portion thereof, with or without processing, enables communication between CAN devices when, for example, they are on separate network zones, including when one or more CAN devices are not directly coupled to a CAN network but interface through another endpoint (e.g., endpoint 2316 on third network zone 2322, which is an Ethernet network in the example depicted in FIG. 23).

[0102] In certain embodiments, the CEG 1916, 2308 can share a port of the CES 1914 and / or can couple to the second network zone 1908 using a separate port. The network zones of a mobile application can have any optional topology, including, but not limited to, a bus topology, a serial topology, a mesh topology, a hub topology, a ring topology, and / or a star topology. An example mobile application includes a first network zone established as a first virtual local area network and a second network zone established as a second virtual local area network. In this example, the first network zone and the second network zone can share physical network hardware and / or portions thereof.

[0103] 23 , an example system includes a first vehicle controller (e.g., endpoint 2302) on a first network zone 1904, a second vehicle controller (e.g., endpoint 2304) on a second network zone 1908, and a network redundancy circuit 2202 that selectively provides coordination control commands, where a CND 1912 adjusts coordination of communications between the first network zone 1904 and the second network zone 1908 in response to the coordination control commands. Exemplary and non-limiting coordination control commands include one or more of an off-nominal condition corresponding to the first vehicle controller 2302, a loss of a data element related to the first vehicle controller 2302, and / or a lost control function of the first vehicle controller 2302. Exemplary, non-limiting adjustments to the step of coordinating communications include one or more operations such as providing an alternative data element to the first vehicle controller 2302 (e.g., from a different endpoint providing the same data, similar data, and / or backup data), providing a data element corresponding to the lost control function to the second vehicle controller 2304 (e.g., if the second vehicle controller 2304 is configured to perform backup operations for all or a portion of the lost control function), and / or providing a data value normally available on the first network zone 1904 to the second network zone 1908 (e.g., to provide the second vehicle controller 2304 with data used to perform backup operations for all or a portion of the lost control function). An exemplary adjustment to the step of adjusting communications includes suppressing communication of a data value normally available on the first network zone 1904 in response to a loss control function of the first vehicle controller 2302 (e.g., when the suppression target data value is no longer needed on the first network zone 1904 and / or when the suppression target data value is no longer indicated as valid data).The example system includes a CND 1912 that provides data values ​​normally available on the first network zone 1904 to the second network zone 1908 as processed (e.g., to include the data values ​​for use by the second vehicle controller 2304) data values ​​to the second vehicle controller 2304 (e.g., to provide the second vehicle controller 2304 with data to implement backup operation for all or a portion of a lost control function). A lost control function includes one or more of: a total or partial loss of a control function normally implemented by the first vehicle controller 2302; a loss of communication with the first network zone endpoint 1906 (e.g., the endpoint 1906 provides the data values ​​utilized to implement the lost control function); a loss of functionality of the first vehicle controller 2302 (e.g., due to a fault code, a fault condition, and / or incorrect communication provided by the first vehicle controller 2302); and / or a loss of communication with the first vehicle controller 2302.

[0104] The exemplary system includes a first vehicle controller 2302 positioned at a first risk exposure profile and a second vehicle controller 2304 positioned at a second risk exposure profile, where the first risk exposure profile is distinct from the second risk exposure profile. Exemplary, non-limiting differences between these risk exposure profiles include one or more of a geometric distinction, an environmental distinction, a failure mode distinction, a prevailing risk type distinction, and / or a prevailing disturbance distinction.

[0105] Certain alternative and / or additional adjustment control commands provided by the network redundancy circuit 2202 include one or more of an abnormal condition corresponding to the first network zone 1904, a loss of communication between at least one endpoint 1906 of the first network zone and the first network zone 1904, a physical failure of at least a portion of the first network zone 1904, and / or a bandwidth limitation of the first network zone 1904. Exemplary, non-limiting adjustments to the adjusting of communications include one or more of: routing at least one communication from the first network zone 1904 to the second network zone 1908; repeating at least one communication from the first network zone 1904 to the second network zone 1908; shifting at least one endpoint (e.g., 1906) from the first network zone 1904 to the second network zone 1908; shifting and / or repeating communications associated with at least one endpoint (e.g., 1906) from the first network zone 1904 to the second network zone 1908; and / or shifting and / or repeating communications associated with at least one endpoint (e.g., 1910) from the second network zone 1908 to the first network zone 1904 (e.g., utilizing endpoint 1910 as an alternate data source for lost endpoint 1906 in the first network zone 1904). Although operation between a first network zone 1904 and a second network zone 1908 is described for illustrative purposes, operation can be implemented using first network zone-second network zone, first network zone-third network zone, and / or second network zone-third network zone.Additionally or alternatively, certain operations (e.g., shifting an endpoint from one network zone to another) may suggest that the associated endpoint may be movable between network zones that may be available in the circumstances to be understood, including at least those in which the endpoint is coupled or coupleable to more than one network zone, the endpoint is reconfigurable to provide legitimate communications for more than one network zone (e.g., the endpoint is capable of detecting network protocols, framing, etc., and / or the endpoint adjusts network protocols, framing, etc. in response to instructions from network redundancy circuit 2202 and / or CND 1912), the network zones are compatible (e.g., have matching protocols, framing, etc., and / or have the ability to communicate using somewhat variable protocols, framing, etc.), and / or the network zones are separate virtual local area networks (e.g., the separation between respective network zones is at least partially logical rather than physical).

[0106] In certain embodiments, the CND 1912 can be co-located with one or more vehicle controllers (not shown) of the system and / or have co-located portions. See, for example, FIG. 15 and related discussion. An example system includes a vehicle controller 2302 on a first network zone 1904 and a first portion of the CND 1912 co-located with the vehicle controller 2302, the first portion including non-transitory computer-readable instructions configured, when executed by processing in the vehicle controller 2302, to perform at least a portion of the operations for coordinating communications.

[0107] In certain embodiments, the CND 1912 includes a portion that is co-located with a vehicle controller (not shown) and includes an Ethernet switch (e.g., 1914), where the network zone 1908 includes an Ethernet network, communications between an end point of the network zone 1908 and another network zone 1904 are routed through the Ethernet switch 1914 (e.g., the CEG 1916 provides communications from the network zone 1904 through a port of the CES 1914), and the Ethernet switch 1914 is located in a housing with the vehicle controller and / or on the same board as the vehicle controller.

[0108] In certain embodiments, the CND 1912 includes a portion that is co-located with a vehicle controller (not shown) and includes a CEG (e.g., 1916), where the network zone 1904 includes an Ethernet network, communications between an end point of the network zone 1904 and another network zone 1908 are routed through the CEG 1916 (e.g., the CEG 1916 provides communications from the network zone 1904 to the network zone 1908 through a port of the CES 1914), and the CEG 1916 is located in a housing with the vehicle controller and / or on the same board as the vehicle controller.

[0109] An example system includes a second vehicle controller 2304 on a second network zone 1908, where the CND 1912 includes a first portion co-located with the vehicle controller (not shown) and a second portion co-located with the second vehicle controller 2304. Each of the first or second portions of the CND 1912 can include one or more non-transitory computer-readable instructions configured, when executed by processing in the CES, CEG, and / or respective vehicle controller (e.g., the vehicle controller and / or the second vehicle controller 2304), to perform at least a portion of the operations of coordinating communications between the network zones 1904, 1908 (and / or 2322, 2324). Each of the first or second portions of the CND 1912 can be located within the housing of the respective vehicle controller and / or on the same substrate as the respective vehicle controller.

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

[0111] Referring to FIG. 24 , a schematic flow diagram of a procedure 2400 for coordinating inter-network communications (e.g., between distinct network zones of a mobile application) is shown. The example procedure 2400 includes an operation 2402 of coordinating inter-network communications (e.g., as referenced throughout this disclosure, including at least FIG. 19 and related descriptions) between a first network (and / or network zone) and a second network (and / or network zone) of a mobile application. Further, the example procedure 2400 includes an operation 2404 of determining whether an abnormal condition exists, including, but not limited to, the status of any network, endpoint, controller, and / or control function. In response to operation 2404 determining “true,” the procedure 2400 includes an operation 2406 of adjusting the coordination of the inter-network communications. Without being limited to any other aspect of the present disclosure, operation 2406 adjusting inter-network communication coordination may include any one or more of: routing communications from a first network to a second network; repeating, sharing, or mirroring communications normally on the first network onto the second network; shifting endpoints from the first network to the second network; throttling communications on one of the networks; adjusting a data sampling rate and / or communication rate of communications and / or endpoints on one of the networks; at least partially adjusting a control operation from a first controller on the mobile application to a second controller on the mobile application, and / or providing data normally provided to the first controller and / or alternative data determined in response to the adjustment of the control operation to the second controller; and / or providing communications from an alternative data source to a controller on the mobile application.

[0112] 25, a procedure 2500 is shown for encapsulating and / or processing a communication from a first network for communication on a second network for a mobile application (e.g., communication between endpoints on separate network zones). The example procedure 2500 includes an operation 2502 of receiving a first network communication (e.g., a communication provided by any endpoint on any network zone for the mobile application), an operation 2504 of processing, removing, or including non-payload frame information of the communication (e.g., metadata, identifiers, timestamps, and / or any other communication information for the communication other than payload or base data). Additionally, the example procedure 2500 includes an operation 2506 of processing, removing, or including payload frame information from the communication (e.g., removing payload and / or changing payload units, resolution, bit depth, data type, etc., if the communication is to be utilized for reasons other than payload, such as for network monitoring operations), and an operation 2508 of encapsulating the communication for communication on the second network for the mobile application. Further, example procedure 2500 includes an operation 2510 of providing the encapsulated communication as a second network communication of the mobile application. In certain embodiments, procedure 2500 provides an operation of providing a message between endpoints on separate networks having incompatibilities (e.g., network protocols, message characteristics, network addressing, etc.) and / or between endpoints having otherwise incompatible data specifications (e.g., payload units, data types, bit depth, etc.). In certain embodiments, the operations of procedure 2500 provide encapsulation of a message from a first network (e.g., a CAN network) to a second network (e.g., an Ethernet network) and / or enable tunneling of a message from a first network having a first network type to another network having the first network type by passing through an intermediate network having a second network type.

[0113] 26, a procedure 2600 is shown for providing upsampling and / or downsampling of communications from a network endpoint of a mobile application. The example procedure 2600 includes an operation 2602 of determining an upsampling scheme and / or downsampling scheme for the communication (e.g., from a first network). Without being limited to any other aspects of the present disclosure, the example operation 2602 includes determining the upsampling scheme and / or downsampling scheme in response to a required data rate for the communication, a data efficiency for the communication relative to the network and / or source endpoint, data storage values ​​for devices in the system (e.g., communication buffer storage and / or long-term data storage locations), and / or a priority for the communication (e.g., compared to competing communications, according to operating conditions for the mobile application, and / or according to associated priorities for the flow, endpoint, vehicle function, etc.).

[0114] Exemplary procedure 2600 further includes an operation 2500 of providing a second network communication, which may include, for example, processing payload and / or non-payload information of the communication and encapsulating the (processed or unprocessed) payload and / or non-payload information into a communication provided to the second network (see, e.g., FIG. 25 and procedure 2500).

[0115] Exemplary procedure 2600 further includes operation 2604 of upsampling and / or downsampling the second network communication. Without being limited to the general concept that all operations for the procedures described herein can be reordered, divided, omitted, and / or combined, it will be understood that operations 2500 and 2604 of procedure 2600 can be performed in any order, including iteratively, simultaneously, and / or sequentially with respect to one another, because for certain communications, the upsampling operation and / or downsampling operation 2604 can make operation 2500 unnecessary (e.g., excluding downsampled communications and / or excluding interpolated or non-interpolated communications) and / or operation 2604 can generate payload and / or non-payload information related to communications that would otherwise be provided in operation 2500 (e.g., adding upsampled communications and / or adding interpolated or non-interpolated communications). Without being limited to any aspect of the present disclosure, operation 2604 can include any of the operations described with respect to FIGS. 17 and 18 and the related description. Example procedure 2600 further includes an operation 2606 of providing the upsampled and / or downsampled communication to a second network. For purposes of clarity of this description, the operations for procedure 2600 are recited with respect to providing a communication from an endpoint on a first network to an endpoint on a second network, but it will be understood that procedure 2600 is applicable to any communication on a mobile application, including public communications for data services (e.g., see FIG. 27 and related description), communications passed to external devices, and / or same-network communications (e.g., from a first endpoint on a first network to a second endpoint on a second network).

[0116] 27, an example apparatus 2700 for providing a service specification architecture for mobile applications with a mixed network environment is shown. The example apparatus 2700 includes a vehicle data service definition circuit 2702 that interprets a service availability description 2704 that includes available data values ​​from endpoints 1906, 1910 on a vehicle's networks 1904, 1908. For example, the vehicle data service definition circuit 2702 can receive a communication from the endpoints 1906, 1910 that provides an indicator that one or more data values ​​are available for communication and / or read an indicator of the data values ​​available for communication from a configuration file 2718 (shown as storage in the example depicted in FIG. 27). The service availability description 2704 may include any type of data value available on the vehicle, including sensed values, actuator feedback values ​​(e.g., position, status, fault values, etc.), parameters from any controllers in the system, virtual sensor values, control parameters (e.g., set points, reference points, determined status values, reference error values, etc.), and / or stored values ​​(e.g., accumulated parameters, snapshot information, calibrations, etc.). The service availability description 2704 may be associated with a single endpoint, a group of endpoints, a flow, or any other data provider or group of data providers in the system. The data associated with the service availability description 2704 may be raw data values ​​and / or processed versions of the data values ​​(e.g., filtered, low sampling rate, time delayed data, etc.).

[0117] Example apparatus 2700 further includes a vehicle data service management circuit 2706 that publishes a data service availability value 2708 in response to service availability description 2704. In certain embodiments, data service availability value 2708 may include the same data or a formatted version thereof as provided by service availability description 2704. In certain embodiments, data service availability value 2708 may include a corrected or adjusted version of service availability description 2704 (e.g., fewer parameters, lower data rate, lower resolution, etc. than those provided in service availability description 2704), for example, when the device providing service availability description 2704 does not have full permissions (e.g., as determined from configuration file 2718) to publish all of the listed parameters, to publish at the planned data rate, and / or to publish at the indicated sampling rate. In certain embodiments, the vehicle data service management circuit 2706 determines that a publishing device (and / or endpoint, flow, etc.) does not have authorization to provide a service published in the service availability description 2704, and accordingly does not provide the corresponding data service availability value 2708 for that service availability description 2704. In certain embodiments, the vehicle data service management circuit 2706 determines that certain data service availability values ​​2708 are restricted to only certain subscribing devices, and accordingly includes the data service availability value 2708 (e.g., provides tags, encryption schemes, metadata, etc.) so that unauthorized devices cannot view and / or subscribe to the corresponding data service availability value 2708. The example vehicle data service management circuit 2706 generates a data service value description 2709 in response to a request 2710 to subscribe to the data service availability value 2708 and the data value from the endpoint 1906, 1910. For example, data service value description 2709 may describe parameters to be collected, grouped, and / or processed, and may further include endpoint descriptions, and the like.The data service value description 2709 provides collection parameters available to the CND 1912 to support services with active valid periodic reception, and also allows management of collection operations such as filtering authorized data access and / or aggregating redundant parameters (e.g., when more than one service may provide the same data element as part of its service, when multiple data rates for a parameter can be provided in a single high-speed collection operation, etc.).

[0118] The example device 2700 includes a CND 1912 that performs operations to coordinate communications between the vehicle's networks 1904, 1908. In the example device 2700, the circuits 2702, 2706 are shown as being collocated with the CND 1912 for purposes of clarity of illustration, but it will be understood that one or more of the components, circuits, communication flows, data elements, and / or other aspects shown in FIG. 27 may be distributed across multiple devices in a system. The example CND 1912 includes a coordination circuit 2710 (which may include and / or be in communication with a network operation component such as a CES, CEG, or other operation component, for example) that coordinates communications between the first network 1904 and the second network 1908, generates a data service value 2712 responsive to a data service value description 2709 and a data value from an endpoint, and publishes the data service value 2712 responsive to the data service value description 2709.

[0119] The example coordination circuit 2710 collects data directly from endpoints and publishes broadcast (e.g., visible to all endpoints) and / or multicast (e.g., provided to subscribing endpoints) parameters according to, for example, permissions, network capacity, parameter importance, and / or breadth of use. In certain embodiments, the example coordination circuit 2710 provides data service values ​​2712 to a service broker 2714, which manages communication of the data service values ​​2712 to subscribing endpoints or devices. Example embodiments having a service broker 2714 additionally or alternatively utilize the service broker 2714 to communicate data service availability values ​​2708 to endpoints or devices and / or to receive subscription requests 2710 from devices. In certain embodiments, the vehicle data service management circuit 2706 communicates with the service broker 2714 to determine the subscription requests 2710. In certain embodiments, the vehicle data service management circuit 2706 receives subscription requests from endpoint devices on the networks 1904, 1908.

[0120] The example apparatus 2700 includes a vehicle data service management circuit 2706 and / or a service broker 2714 that receives a subscription request 2710 from an external device, such as a service device 2716. In this example, the vehicle data service management circuit 2706 determines a data service value description 2709 in response to the subscription request 2710 from the external device (e.g., determining permissions, etc.), and the external device receives parameters according to the subscription service, as well as endpoints, devices, flows, etc. within the vehicle to subscribe to.

[0121] In certain embodiments, the service availability description 2704 further includes an authorization description (e.g., when the endpoint and / or device publishing the service availability applies a permission level), and the vehicle data service management circuit 2706 further limits the publication of the data service availability value 2708 and / or the acceptance of the corresponding subscription request 2710 in response to the authorization description. Additionally or alternatively, the vehicle data service management circuit 2706 can determine the authorization description from a configuration file 2718. The example vehicle data service management circuit 2706 limits the disclosure of data service availability values ​​(and / or limits the acceptance of the corresponding subscription request 2710) in response to one or more of the following: an endpoint identifier of the subscription requestor; an application identifier of the subscription requestor (e.g., motive power management, entertainment management, climate control, stability control, etc.); a flow identifier of the subscription requestor; a user identifier of the subscription requestor (e.g., service technician ID, person role with respect to the requesting device, application, flow, etc.); and / or an entity identifier of the subscription requestor (e.g., entity name, entity role, manufacturer, OEM, service entity, owner entity, third party entity, etc.).

[0122] The example vehicle data service definition circuit 2702 further interprets the service availability value 2720 and updates the service availability description 2704 in response to the service availability value 2720. For example, the service availability value 2720 can provide an indication that the published target service is unavailable due to a failure or malfunction of the endpoint or device providing data for the service, due to a change in system permissions (and / or conditional permission if the permission criteria are not currently satisfied), during certain operating conditions due to the service being listed in the configuration information 2718 but the associated endpoint, device, application, flow, etc. not being present on the vehicle, permission expiring, etc. In yet another example, the service availability value 2720 further includes an authorization description, in which case the vehicle data service definition circuit 2702 restricts updates to the service availability description 2704 in response to the authorization description. The example vehicle data service management circuit 2706 limits updates to service availability descriptions in response to one or more of a service availability value provider endpoint identifier, a service availability value provider application identifier, a service availability value provider flow identifier, a service availability value provider user identifier, and / or a service availability value provider entity identifier. The example vehicle data service definition circuit 2702 receives service availability values ​​2720 from a data collection and management device external to the vehicle (e.g., but not limited to, a service device 2716). Thus, the apparatus 2700 enables the provision and updating of services, including, for example, updating configuration information, in-vehicle permissions, etc., by external devices utilized by a driver, owner, service and repair entity, manufacturing entity, third-party application, fleet owner, etc.

[0123] 28 , an apparatus 2800 for encapsulating network communications to support mobile communications between mixed networks on a mobile application is illustrated. The example apparatus 2800 includes a first network interface circuit 2802 that interprets a first network data set 2804 (e.g., a message from an endpoint on a first network 2805) having a first network format 2806 (e.g., a protocol, message parameters, start and / or end bits or information, payload formatting, message type, message verification protocol, and / or network layer), and a conversion circuit 2808 that determines message values ​​2810 from the first network data set 2804 and encodes the message values ​​2810 into a second network data set 2812 having a second network format 2814. As used herein, a message data set should be understood broadly and may include a single message, a group of related messages, a group of messages present on related networks over a period of time, an operating condition, or the like. As used herein, a message value includes any selected aspect of a message, including a payload, a frame, a portion of a frame, metadata, and the like.

[0124] The example apparatus 2800 further includes a second network interface circuit 2816 that transmits the second network data set 2812 (e.g., as a message to a second network 2817). The apparatus 2800 includes the first network interface circuit 2802, the conversion circuit 2808, and the second network interface circuit 2816 defined by either a single device or two devices, and the first device and / or the two devices can be incorporated into a vehicle. For example, a CND can include all of the first network interface circuit 2802, the conversion circuit 2808, and the second network interface circuit 2816. In another example, a CEG can include the first network interface circuit 2802 and the conversion circuit 2808, and a CES can include the second network interface circuit 2816. In another example, a CEG can include the first network interface circuit 2802, and a CES can include the conversion circuit 2808 and the second network interface circuit 2816. In another example, a CEG may include all of the first network interface circuit 2802, the conversion circuit 2808, and the second network interface circuit 2816.

[0125] 28 , first network format 2806 is distinct in at least one aspect from second network format 2814. Example device 2800 includes one of first network format 2806 or second network format 2814 as a CAN network. Example device 2800 includes first network format 2806 as a CAN network and second network format 2814 as an Ethernet network.

[0126] Exemplary apparatus 2800 further includes a configuration circuit 2818 that modifies first network interface circuit 2802, conversion circuit 2808, and / or second network interface 2816 in response to configuration command values ​​2820. Exemplary and non-limiting configuration command values ​​2820 include one or more of: which messages of first network data set 2804 are to be communicated to the second network; upsampling and / or downsampling operations to perform on messages of first network data set 2804; conversion parameters for determining message values ​​2810 (e.g., which aspects of a message, such as payload, frame portion, metadata, etc., are considered message values ​​2810) and / or encoding message values ​​into second network data set 2812 (e.g., encapsulation operations, source and / or destination identification, unit conversion, etc.); and / or network adjustment operations (see, e.g., FIG. 19 and related discussion). The exemplary configuration circuit 2818 is defined by a first device, such as a CND, a CEG, and / or a CES, or by a second device (optionally, if present). In certain embodiments, the configuration circuit 2818 further selectively configures which of one or more portions of the first network interface circuit 2802, the translation circuit 2808, and / or the second network interface circuit 2816 are defined by the first device and / or the second device (e.g., enabling the configuration circuit 2818 to coordinate operation between devices to repurpose a device, such as a CEG or CES, and / or to shift network operation and / or regulation functions in response to system changes, topology changes, and / or abnormal operating conditions). In certain embodiments, the configuration circuit 2818 receives configuration command values ​​2820 from a CND, from an external device, and / or by accessing a configuration file.

[0127] 29, an apparatus 2900 for port mirroring on a mobile application and providing communications from a first network to a second network is shown. The example apparatus 2900 includes a first network interface circuit 2802 having several ports 2902 and interpreting first communication data 2904 of a first network 2805 onboard a vehicle. The ports 2902 can be physical ports, logical ports, and / or combinations thereof. The example apparatus 2900 includes a second network interface circuit 2816 that interprets second communication data 2906 from a second network 2817 onboard the vehicle. The second network 2817 is of a different type than the first network 2805 (e.g., a CAN network versus an Ethernet network, a network having distinct network formats 2806, 2814, and / or any other type of difference described herein and / or understood in the art). Apparatus 2900 further includes a conversion circuit 2808 that forwards second communication data 2906 through at least one of ports 2902 to first network interface circuit 2802 for transmission over first network 2805 (e.g., this forwarding may include processing, encapsulating, and / or otherwise configuring second communication data 2906 for communication over first network 2805). The example first network interface circuit 2802 mirrors a first one of ports 2902 to a second one of ports 2902, for example, allowing external device 2908, a data collection operation (not shown), and / or other devices within the vehicle to observe and / or acquire data from the second port, thereby receiving the same data communicated on the first port. Without being limited to any other aspect of the present disclosure, port mirroring operations enable network monitor operations, data collection of any parameter from any endpoint of the network within the vehicle (e.g., without requiring the requesting device to have knowledge of the network configuration, communication protocols, and / or locations of endpoints distributed throughout the vehicle).

[0128] The example apparatus 2900 further includes a configuration circuit 2818 that interprets the port selection command value 2820 and assigns which ports 2902 are the first port and the mirror port. Thus, the configuration circuit 2818 can provide communication values ​​that can include any selected endpoint on the first network 2805 and / or that can include all of the second communication data 2906 (e.g., if the conversion circuit 2808 forwards the second communication data 2906 to one of the ports 2902) to a selected mirror port from any of the ports 2902. In certain embodiments, the configuration circuit 2818 receives the port selection command value 2820 from the CND, from a configuration file, from a requesting external device 2908 (e.g., a service tool, an OBD device, a vehicle, and / or a network monitor device, etc.), and / or from any controller on the vehicle that has sufficient permission to provide the port selection command value 2820.

[0129] The example configuration circuit 2818 interprets the port assignment command value 2820, which identifies an assigned port and a device (e.g., an endpoint, controller, flow, application, etc.) on the second network 2817, identifies a portion of the second communication data 2906 that corresponds to the identified device, and transmits (and / or instructs the first network interface circuit 2802 to transmit) the identified portion of the second communication data 2906 to the assigned port. In certain further embodiments, the device on the second network 2817 may additionally or alternatively include communication data corresponding to an identified device on another network (e.g., the first network 2805) (e.g., when an application, flow, or other device on the second network 2817 includes aspects operating on the other network), and operation of the configuration circuit 2818 and the first network interface circuit 2802 further supports providing the associated communication data from all associated networks to the assigned port.

[0130] 30, an apparatus for controlling inter-network traffic on a mobile application is shown. The example apparatus 3000 includes a first network interface circuit 2802 that interprets first communication data 2904 of a first network 2805 onboard a vehicle and a second network interface circuit 2816 that interprets second communication data 2906 of a second network 2817 onboard the vehicle. The second network 2817 is of a different type than the first network 2805 (e.g., a CAN network versus an Ethernet network, a network having distinctly different network formats 2806, 2814, and / or any other type of difference described herein and / or understood in the art). The example device 3000 further includes a conversion circuit 2808 that selectively forwards first communication data 2904 to the second network interface circuit 2816 for transmission over the second network 2817 and / or second communication data 2906 to the first network interface circuit 2802 for transmission over the first network 2805. The example conversion circuit 2808 further configures messages from each network for the other network, e.g., processes, encapsulates, and / or otherwise configures the messages before forwarding them. The example device 3000 further includes a conditioning circuit 3002 that conditions the second network interface circuit 2816, the first network interface circuit 2802, and / or the conversion circuit 2808, where the conditioning can include, but is not limited to, performing any one or more operations such as the conditioning operations described in FIG. 19 and the related description. The example adjustment circuit 3002 constrains the amount of first communication data 2904 transferred to the second network interface circuit 2816 and / or the amount of second communication data 2906 transferred to the first network interface circuit 2802.The exemplary regulating circuit 3002 constrains the amount of communication data by limiting the data rate (e.g., the amount of data per unit time and / or the amount of data over a period of time), limiting the amount of data based on a saturation rate (e.g., the utilization of available bandwidth, the utilization of a portion of the bandwidth allowed for the associated communication, etc.), limiting the amount of data based on storage capacity, the capabilities of the receiving device (e.g., the endpoint on one of the networks), and / or the required data rate of the receiving device.

[0131] The example conditioning circuit 3002 constrains the transmission of one or more portions of the first communication data 2904 and / or the second communication data 2906, for example, constraining the transmission of data corresponding to selected destinations, flows, applications, and / or according to vehicle operating conditions, network and / or destination abnormal conditions, etc. In certain embodiments, a combination of these constraints may exist, for example, when specified vehicle operating conditions indicate that transmission to or from certain destinations is constrained and / or transmission for certain data flows is constrained. Constraint operations include, without being limited to any other aspect of the present disclosure, operations such as limiting communications, limiting a communication rate, throttling communications (at least over a period of time and / or during certain operating conditions), downsampling certain messages (e.g., to reduce message communication traffic), and / or upsampling certain messages (e.g., which may shift operational load between components, including reducing load on some components such as by utilizing upsampling to reduce the actual data sampling rate, generating messages configured to reduce encapsulation load, and the like). In certain embodiments, the constraining operations of the adjustment circuit 3002 include considering priority information associated with messages, endpoints, flows, networks, etc., and / or prioritizing portions of the first communication data 2904 and / or second communication data 2906 to be transferred.

[0132] 31 , an apparatus supporting a configurable network status monitor for mobile applications with mixed networks is shown. The example apparatus 3100 includes a first network interface circuit 2802 that interprets first communication data 2904 of a first network 2805 onboard the vehicle and a second network interface circuit 2816 that interprets second communication data 2906 of a second network 2817 onboard the vehicle. The second network 2817 is of a different type than the first network 2805 (e.g., a CAN network versus an Ethernet network, a network having distinctly different network formats 2806, 2814, and / or any other type of difference described herein and / or understood in the art). The example apparatus 3100 further includes a network status circuit 3102 that generates network status data 3106 by monitoring a portion of the first communication data 2904 and / or the second communication data 2906. While the example depicted in FIG. 31 shows the network status circuit 3102 in communication with the port 2902 of the first network interface circuit 2802 to collect network status data 3106, it will be understood that the network status circuit 3102 may be located elsewhere in the system and may collect the network status data 3106 from the conversion circuit 2808, the second network interface circuit 2816, and / or may access the network status data 3106 as data stored on the memory storage of the device 3100.

[0133] The example device 3100 further includes a configuration circuit 2818 configured to mirror at least one of the ports 2902 with at least another of the ports 2902, e.g., to provide network status data 3106 to a selected port 3902 of the first network interface circuit 2802. The example configuration circuit 2818 identifies the selected port (e.g., to provide the network status data 3106) and further identifies a portion of the first communication data 2904 and / or second communication data 2906 (e.g., based on a monitored device, network, endpoint, flow, etc.), and interprets a port assignment command value 3104 to send (and / or instruct the first network interface circuit 2802) for communication to the selected port. The example device 3100 includes a configuration circuit 2818 that modifies the network status data 3106 in response to, e.g., a selected device, endpoint, flow, application, controller, network, system, etc. of the vehicle. The example device 3100 includes a configuration circuit 2818 that modifies the network status data 3106 in response to a data selection command value 3108 (e.g., provided by the network status circuit 3102, a CND, an external device, a configuration file, and / or other controllers or components of the system) and adjusts the data provided to selected ports (or otherwise to the network status circuit 3102) in response to the data selection command value 3108. In certain embodiments, the data selection command value 3108 additionally or alternatively identifies one or more protocols (e.g., data collection rate, time values ​​and / or time ranges, selected operations, selected portions of message frames, metadata, protocol type (e.g., TCP, UDP, AVB, etc.)). The example device 3100 depicts, in a non-limiting example, the circuits 2802, 2808, 2816, 2818 located within the same housing 3110 and the network status circuit 3102 (e.g., an external device) separate from the housing 3110. The example device 3100 can include circuits 2802, 2808, 2816, 2818 and / or subgroups of these circuits located on the same circuit board.

[0134] 31 , exemplary first network 2805 is an Ethernet network and exemplary second network 2817 is a CAN network. In this example, conversion circuit 2808 is interposed between first network interface circuit 2802 and second network interface circuit 2816 and converts Ethernet communication data to CAN communication data and / or converts CAN communication data to Ethernet communication data. Network status circuit 3102 generates network status data 3106 by monitoring Ethernet communication data 2904 and / or CAN communication data 2906. In certain embodiments, network status data 3106 is based at least in part on one or more of the bandwidth through conversion circuit 2808, the number of messages in the Ethernet communication data and / or CAN communication data having addresses corresponding to the same device, the same application, and / or the same flow, and / or the number of communication errors (e.g., packet loss, delay events, bad checksums, corrupted data, failed handshakes or acknowledgments, etc.).

[0135] 32-34, for illustrative purposes, there are shown exemplary arrangements of devices for coordinating communications between networks on a mobile application.

[0136] 32, an exemplary arrangement includes a CEG 3206 (e.g., a configurable edge gateway and / or a CAN gateway) having a first network interface circuit 2802 in communication with a CAN network 3202 and a conversion circuit 2808 that passes selected messages between ports of the CAN network 3202 and a second network interface circuit 2816. The exemplary arrangement includes a CES 3208 that includes a second network interface circuit 2816 in communication with an Ethernet network 3204, and further includes a configuration circuit 2818 that performs operations to coordinate communications between the networks 3202, 3204. The arrangement described in FIG. 32 may form all or a portion of a CND listed throughout this disclosure and / or perform operations to coordinate communications between the networks 3202, 3204 in response to CND commands, where the CND is distributed elsewhere in the system.

[0137] 33, an exemplary arrangement is shown that may form all or part of the CNDs listed throughout this disclosure and / or perform operations to coordinate communications between networks 3202, 3204 in response to CND commands, where the CNDs are distributed elsewhere in the system. The example set forth in FIG. 33 differs from the example set forth in FIG. 32 in that in this case, conversion circuit 2808 is collocated with CES 3208 and receives CAN messages directly from first network interface circuit 2802.

[0138] Referring to FIG. 34, an exemplary arrangement is shown that may form all or part of the CNDs listed throughout this disclosure and / or perform operations to coordinate communications between networks 3202, 3204 in response to CND commands, where the CNDs are distributed elsewhere in the system. The example depicted in FIG. 34 differs significantly from the example depicted in FIG. 33, in that the configuration circuits 2818 are distributed between the CES 3208 and the CEG 3206. In the example depicted in FIG. 34, one of the configuration circuits 2818 may be primary and pass configuration information to the other configuration circuits 2818. In certain embodiments, each configuration circuit 2818 may operate independently, receiving configuration information from a configuration file, for example, through communication with a CND. The examples depicted in FIGS. 32-34 are non-limiting diagrams intended to illustrate certain aspects and arrangements of the present disclosure.

[0139] 35 , an example procedure 3500 for providing a service specification architecture for a vehicle having a mixed network is shown. The example procedure 3500 includes an operation 3502 of interpreting a service availability description including an availability data value from a first termination device on one of the vehicle's first network or a second network, an operation 3504 of publishing a data service availability value in response to the service availability description, an operation 3506 of generating a data service value description in response to a subscription request for the data service availability value, an operation 3508 of generating a data service value in response to the data service value description and the data value from the first termination device, and an operation 3510 of publishing the data service value in response to the data service value description. The example operation 3510 of publishing the data service value includes providing the data service value to a second termination device, e.g., an termination device on a different network than the first termination device. The exemplary operation 3510 further includes publishing the data service value by providing a network communication including the generated data service value to a plurality of subscribed endpoint devices on one of the first network or the second network, each of the plurality of subscribed endpoint devices. The exemplary data service availability value includes a name for the service, a list of data parameters provided by the service, a list of availability commands provided by the service, etc. (e.g., from providing the device to the CND), and the data service value description includes a name for the service, a list of data parameters provided by the service, a list of availability commands provided by the service, etc. (e.g., from the CND to the potential subscribed device), where the data service value description can match the data service availability value or can be configured differently (e.g., simplified, expanded, standardized, etc.) from the data service availability value. The exemplary data service value includes a data value corresponding to the data service availability value.

[0140] In certain embodiments, procedure 3500 further includes operation 3512 of receiving a subscription request from an endpoint device on both the first network and the second network. Example operation 3512 includes receiving a subscription request from a device external to the vehicle, e.g., a service device, a web application, a cloud-based application, and / or a third-party application, in which case operations 3508 and / or 3510 are performed in response to operation 3512 (e.g., generating a data service value and / or publishing the data service value only if the subscribing device is available for the service). Example procedure 3500 includes the service availability description further including an authorization description, in which case operation 3504 includes restricting publication of the data service availability value in response to the authorization description (e.g., in which case unauthorized devices cannot see the data service). Example operation 3504 includes limiting the disclosure of data service availability values ​​in response to an identifier of a subscription requestor (e.g., an endpoint, a flow, a vehicle function, an application, a group of services, and / or an entity associated with any of these).

[0141] The example procedure 3500 includes a service availability description that further includes an authorization description, where operation 3510 includes restricting the disclosure of the data service value in response to the authorization description (e.g., not enabling subscription to the exposed service). The example operation 3510 includes restricting the disclosure of the data service value in response to an identifier of a source of the subscription request (e.g., an endpoint, a flow, a vehicle function, an application, a set of services, and / or an entity associated with any of these).

[0142] Example operations 3502 include interpreting the service availability value and updating the service availability description in response to the service availability value. For example, the service availability value may be updated by a provider device (e.g., an endpoint, a flow, a vehicle function, an application, a set of services, an external device, etc.) and / or may be updated by a policy change that adds and / or removes a service from the available services. Example operations 3502 further include restricting the update of the service availability description in response to an authorization description (e.g., verifying authorization of the updating device before updating the service availability description) and / or in response to an identifier of the updating device.

[0143] 36, an example methodology 3600 for providing messages between networks for vehicles having mixed networks is shown. The example methodology 3600 includes an operation 3602 of interpreting a first network data set having a first network format, an operation 3604 of determining message values ​​from the first network data set in response to operation 3602, an operation 3606 of encoding the message values ​​in a second network data set having a second network format, and an operation 3608 of transmitting the second network data set (on the second network). The example methodology 3600 includes networks having vehicle data formats that are in various formats (e.g., CAN, MOST, LIN, FlexRay, TTP, LVDS, AVB, and / or electrical signal formats). The example first network format is a CAN-based format, and the example second network format is an Ethernet-based format. Example procedure 3600 further includes operation 3610 of interpreting a configuration command value from a device external to a vehicle including a first network interface circuit that interprets a first network data set, a conversion circuit that determines a message value from the first network data set and encodes the message value into a second data set, and a second network interface circuit that transmits the second network data set (e.g., via a policy update provided by the external device), and operation 3612 of configuring the first network interface circuit, the second network interface circuit, and / or the conversion circuit based at least in part on the configuration command value, e.g., such that operations 3602, 3604, 3606, 3608 are performed in accordance with the configuration command value.

[0144] Example operations 3606 include encapsulating a message value (e.g., a payload), encapsulating an entire message (e.g., a portion or all of a message frame), processing the message value, and / or processing a portion or all of the message frame. Example operations 3606 include one or more of including an encapsulation scheme for the message, including address descriptions for the message (e.g., translating addresses according to target devices receiving data on separate networks), and / or including a sampling rate (e.g., performing upsampling and / or downsampling on the first network data set).

[0145] 37, an example procedure 3700 for configuring a CND for monitoring networks of a vehicle having a mixed network is shown. The example procedure 3700 includes an operation 3702 of interpreting first communication data of a first network installed in the vehicle, an operation 3704 of interpreting second communication data of a second network installed in the vehicle that is of a different type than the first network, an operation 3706 of generating network status data by monitoring the first and second communication data, and an operation 3708 of transmitting the network status data (e.g., storing the data, communicating the data to an external device, a service tool, a cloud server, etc.). Example procedure 3700 further includes operation 3710 of configuring a first port (e.g., a port on the vehicle's network) to mirror a second port (e.g., another port on the vehicle's network), where the first port provides the first communication data, e.g., provides the first communication data as messages available on the second network, and / or provides the second port as a monitor port for the first communication data. Example operation 3710 includes interpreting a port assignment value (e.g., from a policy, a configuration file, and / or determined according to the request data and its corresponding provider endpoint, and / or determined according to a port corresponding to a service tool, monitor device, etc.) to identify a selected port, where operation 3704 includes identifying a portion of the second communication data that corresponds to the identified device (e.g., a monitored endpoint, port, flow, etc.), and operation 3708 includes transmitting the identified portion of the second communication data through the selected port.

[0146] An example operation 3706 further includes modifying the network status data. An example operation of modifying the network status data includes modifying the network status data in response to the selection command value and including in the network status data data corresponding to at least one device, application, vehicle function, flow, service group, network, protocol, and / or system identified by the data selection command value. Example, non-limiting protocols include a CAN network protocol and / or an OBD protocol.

[0147] 38 , a procedure 3800 for mirroring ports using a CND for a vehicle having a mixed network is shown. The example procedure 3800 includes an operation 3802 of interpreting first communication data of a first network at several ports of the CND, an operation 3804 of interpreting second communication data of a second network (of a different type), an operation 3806 of forwarding the second communication data to the first network (e.g., from a CEG to a CES) using at least one of the several ports, and an operation 3808 of mirroring a first of the ports to a second of the ports. Furthermore, the example procedure 3800 includes an operation 3810 of interpreting a port selection command value (e.g., a receiving port and / or a transmitting port for mirrored target communication data) and an operation 3812 of assigning the first and / or second of the ports in response to the port selection command value. Example operation 3810 includes a port allocation command value that identifies an assigned port and identifies a device on the second network, in which case operations 3806 and / or 3808 include transmitting the identified portion of the second communication data through the assigned port (e.g., to the second network and / or mirror port).

[0148] 39, an example procedure 3900 involving a CND for a vehicle having a mixed network is shown. The example procedure 3900 includes an operation 3902 of interpreting a first network data set by a first interface circuit of a centralized network device (CND) having a first network format, an operation 3904 of determining, by a conversion circuit of the CND, a message value from the first network data set in response to interpreting the first network data set, an operation 3906 of encoding, by the conversion circuit, the message value into a second network data set having a second network format different from the first network format, and an operation 3908 of transmitting the second network data set by a second interface circuit of the CND. Further, the example procedure 3900 includes an operation 3910 of interpreting a configuration command value and an operation 3912 of modifying the CND in response to the configuration command value.

[0149] Example operations 3912 include interpreting the configuration command value and modifying the CND in response to the configuration command value. Example operations of modifying the CND include selectively configuring which of one or more portions of the first interface circuit, the translation circuit, and / or the second interface circuit are at least partially defined by the first device and / or the second device (e.g., shifting translation and / or interface burdens between various network interface circuits and / or between the CEG and / or CES). Example operations 3912 include generating a configuration command value external to the vehicle (e.g., from an external device and / or via a policy update) and transmitting the configuration command value to the vehicle (and / or the CND).

[0150] 40 , an example procedure 4000 is shown that includes operations for performing test operations, diagnostic operations, and / or vehicle control operations and including a CND to perform these operations. Example procedure 4000 may be performed in addition to and / or in whole or in part separately from the operations for procedure 3900. Example procedure 4000 includes an operation 4002 for generating a test command value external to the vehicle, an operation 4004 for transmitting the test command value to a CND, and an operation 4006 for performing a test procedure involving a device (e.g., one of the first or second devices of procedure 3900 and / or a third device on the first or second network). Additionally or alternatively, example procedure 4000 may be performed utilizing diagnostic command values, active assistance command values, and / or vehicle control values ​​(e.g., commanding actuators, vehicle functions, etc.). In certain embodiments, procedure 4000 provides for remote configuration of the CND and / or remote operation of test, diagnostic, vehicle control functions, etc., without requiring knowledge from an external device of the network topology, endpoint locations, and / or endpoint local addresses of devices on the vehicle.

[0151] 41 , an example procedure 4100 for coordinating networks in a vehicle having a mixed network is shown. The example procedure 4100 includes an operation 4102 of interpreting first communication data of a first network in the vehicle, an operation 4104 of interpreting second communication data of a second network in the vehicle, an operation 4106 of forwarding the first communication data to the second network (and / or the second communication data to the first network), and an operation 4108 of coordinating the second network. The example operation 4108 includes restricting the forwarding of the first communication data (e.g., limiting speed, disabling and / or suspending communications, restricting devices that can send and / or receive the forwarded data, etc.). Exemplary operations 4108 are performed in response to the amount of data per unit time, per operating event (e.g., per trip, during certain operating conditions, etc.), based on the saturation rate of the first network and / or the second network, and / or the maximum bandwidth of the first network and / or the second network (e.g., adhering to a total bandwidth limit, limiting forwarded communications to a selected portion of the available bandwidth, etc.). Exemplary operations 4108 include prioritizing a portion of the first communication data and / or the second communication data for forwarding according to any of the prioritization operations and / or groupings (e.g., by endpoint, flow, application, vehicle function, service group, etc.) listed throughout this disclosure. Exemplary operations 4108 include upsampling, downsampling, encapsulating, and / or processing forwarded messages and / or portions thereof (e.g., payload, selected messages, frame portions, metadata, etc.).

[0152] 42, an example methodology 4200 for coordinating inter-network communications in a vehicle having mixed networks is shown. The example methodology 4200 includes an operation 4202 of interpreting first communication data of a first network onboard the vehicle, an operation 4204 of interpreting second communication data of a second network onboard the vehicle, an operation 4206 of forwarding the first communication data to the second network (and / or the second communication data to the first network), and an operation 4208 of coordinating the forwarding of the first communication data and / or the second communication data. Operation 4208 may coordinate operations described throughout this disclosure and may be performed in response to the first network, the second network, a forwarding device (e.g., a CEG, a CES, and / or a network interface circuit), memory storage (e.g., a buffer memory and / or short-term memory storage for network communications), including their characteristics, operating conditions of the vehicle, and / or abnormal conditions existing with respect to the vehicle.

[0153] 43, an example procedure 4300 for supporting CAN status determination using an Ethernet-based monitor is shown. The example procedure 4300 includes an operation 4302 of interpreting an Ethernet-based data set through one or more physical ports of a first interface circuit of an Ethernet switch (e.g., forming a CES) located on the vehicle, an operation 4304 of determining message values ​​from the Ethernet data set using a conversion circuit (e.g., on the Ethernet switch, CAN gateway, and / or CEG), and an operation 4306 of encoding a message from the Ethernet-based data set into a message for a CAN-based data set. While operations 4304, 4306 have been described as proceeding from an Ethernet-based data set to a CAN-based data set, operations can additionally or alternatively proceed from a CAN-based data set to an Ethernet-based data set. The example procedure 4300 further includes an operation 4308 of transmitting the CAN data set using a second interface circuit (e.g., thereby transmitting an Ethernet message to a CAN-based device and / or transmitting a CAN message to an Ethernet device). Further, example procedure 4300 includes an operation 4310 of interpreting a configuration command value and an operation 4312 of modifying a conversion circuit in response to the configuration command value (e.g., changing message processing, addressing, encapsulation characteristics, upsampling values, downsampling values, maximum data rate, etc.). Example operation 4310 includes receiving a configuration command value from an external device (e.g., as a request, message, policy update, etc.). Example operation 4312 includes providing the configuration command value to an Ethernet switch, CEG, configurable CAN gateway, etc. Example procedure 4300 may be utilized to perform testing, active diagnostics, active assistance, and / or vehicle control, where multiple devices on a mixed network are utilized to perform the operations. Example operations may utilize any endpoint in a vehicle, vehicle function, application, flow, service group, etc.Exemplary operations may utilize systems and / or associated components such as a vehicle prime mover, a vehicle engine, a vehicle driveline, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and / or a vehicle electrical system.

[0154] 44, an example methodology 4400 for providing an Ethernet monitor on a vehicle having a mixed network is shown. The example methodology 4400 includes an operation 4402 of converting Ethernet communication data to CAN communication data, an operation 4404 of converting the CAN communication data to Ethernet communication data, and an operation 4406 of generating network status data by monitoring the converted CAN communication data and the Ethernet communication data. Additionally, the methodology 4400 includes an operation 4408 of transmitting the network status data, for example, by storing the data, communicating the data to an external device, and / or sending the data to a service tool, a web application, a cloud server, a third party application, etc.

[0155] Example procedure 4400 further includes operation 4410 of configuring a first Ethernet port to interpret the first Ethernet data and operation 4412 of mirroring communications of the first Ethernet port to a second Ethernet port. In certain embodiments, the first Ethernet port may be a port that provides CAN communication data (e.g., from operation 4404) to an Ethernet network. In certain embodiments, operation 4408 of transmitting network status data includes operation 4412 of mirroring communications of the first Ethernet port to a second Ethernet port. Additionally or alternatively, operation 4406 of generating network status data may be performed on at least a portion of the data provided in operation 4412, and operation 4406 of generating network status data may be performed in-vehicle, off-vehicle, and / or a combination thereof.

[0156] 45, an example methodology 4500 for operating a mixed network system on a vehicle is shown. The example methodology 4500 includes an operation 4502 of generating a message value by a first vehicle control device on a first network located within the vehicle, an operation 4504 of transmitting the message value to a second vehicle control device on a second network located within the vehicle, and an operation 4506 of performing a control operation on the vehicle (e.g., moving a sensor and / or actuator and / or collecting specified data) in response to receiving the message value at the second vehicle control device. Example and non-limiting vehicle control devices include any sensors, actuators, and / or controllers onboard the vehicle. Example and non-limiting vehicle control devices include systems and / or associated components such as a vehicle prime mover, a vehicle engine, a vehicle driveline, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and / or a vehicle electrical system. In certain embodiments, the first vehicle control device and / or the second vehicle control device may have the capability to fully or partially perform one or more operations of the other of the vehicle control devices. In certain embodiments, operation 4502 includes generating a message instructing one of the vehicle control devices to take over, in whole or in part, one or more operations of the other of the vehicle control devices. In certain embodiments, the vehicle control devices are disposed on multiple networks of different types. In certain embodiments, procedure 4500 includes operation 4508 of providing data previously communicated to one of the vehicle control devices to the other of the vehicle control devices. Operation 4508 may be performed in addition to the previous communication (e.g., both vehicle control devices receive this data) and / or as a replacement for the previous communication (e.g., in response to a failure of the previous communication and / or ceasing the previous communication when operation 4508 is initiated).In certain embodiments, operations 4508 include providing substitute data (e.g., data for a different executable operation of the replacement control device, but data that nonetheless serves the replacement control device in whole or in part as a substitute for the original control device), data from a different source (e.g., from a different endpoint than the source of the previous communication), and / or data that is processed distinctly differently from the previous communication (e.g., having a different resolution, communication rate, units, etc.). In certain embodiments, operations 4508 including vehicle controller substitution and / or communication changes are performed in response to a request from the control device (e.g., a separate data request is sent from the control device in response to the operation change) and / or in accordance with a configuration file and / or policy.

[0157] The example procedure 4500 includes an operation 4504 of transmitting a message value over one or more intermediate networks (e.g., from a CAN network on a first network zone, tunneled through an Ethernet network on a second network zone, to a CAN network on a third network zone). In certain embodiments, the intermediate network can be a distinctly different type of network as compared to the first network and / or the second network. Example and non-limiting operations 4506 include one or more of obtaining data from a vehicle component, operating a vehicle component, and / or controlling another vehicle control device. The example operations 4506 can utilize any endpoint of the vehicle, a vehicle function, an application, a flow, a set of services, etc. The example operations 4506 can utilize systems and / or associated components such as a vehicle prime mover, a vehicle engine, a vehicle driveline, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and / or a vehicle electrical system. The example operations 4506 may utilize systems and / or related components such as a vehicle infotainment system, a vehicle environmental system, a vehicle safety system, and / or a vehicle security system.

[0158] 46, an example procedure 4600 for operating a mixed network system on a vehicle is shown. The example procedure 4600 includes an operation 4602 of generating a message value by a first vehicle control device on a first network of the vehicle, an operation 4604 of transmitting the message value (and / or a processed and / or encapsulated version of the message value) on a second network to an external device at least selectively communicatively coupled to the vehicle, and an operation 4606 of interpreting the message value by the external device. The example procedure 4600 includes an operation 4608 of testing the first vehicle control device by the external device and / or configuring the first vehicle control device by the external device (e.g., providing a direct command or request, updating a policy, and / or updating a configuration file). The example procedure 4600 includes an operation 4609 of configuring a second vehicle control device on the second network by the external device, which may be responsive to operations 4604, 4606, and / or 4608.

[0159] Example operation 4604 includes converting (e.g., with the CND, CEG, CES, and / or network interface circuitry) the message value from a first format (e.g., for the first network) to a second format (e.g., for the second network). Example operation 4608 includes converting (e.g., with the CND, CEG, CES, and / or network interface circuitry) the message value from a first format (e.g., for the first network) to a second format (e.g., for the second network) by an external device. Example procedure 4600 may additionally or alternatively include transmitting one or more message values ​​over an intermediate network interposed between the first network and the second network (see, e.g., FIGS. 4, 23, 45, and related discussion).

[0160] Example procedure 4600 includes operation 4610 of generating an external message value by an external device and operation 4612 of transmitting the external message value toward a first network. Operation 4612 may further include interpreting the external message by a vehicle control device (e.g., the first vehicle control device and / or another vehicle control device, for example, to determine the external message content and thereby perform a control operation, a data collection operation, an active diagnostic operation, an active assistance operation, a test operation, an update operation to a configuration file and / or policy, etc.). Example operation 4612 may utilize any endpoint of the vehicle, a vehicle function, a vehicle controller, an application, a flow, a set of services, etc. Example operation 4612 may utilize systems and / or associated components such as a vehicle prime mover, a vehicle engine, a vehicle driveline, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and / or a vehicle electrical system. The example operations 4612 may utilize systems and / or associated components such as a vehicle infotainment system, a vehicle environmental system, a vehicle safety system, and / or a vehicle security system.

[0161] 47, an example system 4700 for providing off-vehicle vehicle communication control consistent with embodiments of the present disclosure is shown. The example system includes a vehicle 102 having a first network zone 5612 and a second network zone 5614 that is of a different type than the first network zone 5612. The example system 4700 includes a CND 108 interposed between the first network zone 5612 and the second network zone 5614. A CND 108 inserted between network zones 5612, 5614 involves physical intervention (e.g., communication between network zones 5612, 5614 passes through devices such as the CND 108 and / or CEG, CES, or other network interface circuitry controlled by it), and / or logical intervention (e.g., when communication between network zones 5612, 5614 passes through devices controlled by the CND 108, and / or when the CND 108 adjusts communication between network zones 5612, 5614, e.g., passing data values, configuration of data values, data rate, data upsampling and / or downsampling, encapsulation operations, frame inclusion, and / or processing of passing communications, etc.).

[0162] The example system 4700 further includes a policy manager circuit 5602 that interprets a policy 5606 that includes an active diagnostic description 4705, and a diagnostic execution circuit 4702 that provides a diagnostic command value 4712 to endpoints in the network zones 5612, 5614 in response to the active diagnostic description 4705. The example system 4700 includes an endpoint (endpoint 4708) in the first network zone 5612 and an endpoint (endpoint 4710) in the second network zone 5614. In the example system 4700, the endpoints 4708, 4710 include devices that respond to the diagnostic command value 4712. Exemplary, non-limiting diagnostic command values ​​4712 include commands to collect one or more data values, commands to operate an actuator, and / or commands to operate a vehicle function (e.g., provide engine speed, power level, or perform higher level functions, e.g., regeneration mode, scheduled test operation, etc.). The example system 4700 enables successful execution of active diagnostic test runs requested by an external device despite the distribution of endpoints 4708, 4710 across multiple networks of vehicles, including when endpoints are moved between networks and / or when a given diagnostic command value 4712 is utilized to perform active diagnostic tests across different vehicles having different network configurations and different distributions of endpoints 4708, 4710.

[0163] 48 , an example endpoint 4708 includes a device control circuit 4802 that interprets a diagnostic command value 4712 and provides an actuator command value 4804 in response to the diagnostic command value 4712. The example endpoint 4708 includes or is connected to an actuator 4806 that responds to the actuator command value 4804. For example, the diagnostic command value 4712 may include commands such as “lock driver door,” “close exhaust gas recirculation valve,” or “raise motor temperature to 80° C.”, allowing abstraction between the diagnostic command value 4712 and the response of the actuator 4806 to obtain the diagnostic command value 4712. Additionally or alternatively, the diagnostic command value 4712 may be associated with a complex or continuous operation, such as an entire test sequence, and thus may be associated with many endpoints 4708, 4710, and / or multiple actuators 4806 across the system 4700 may be implied by a single diagnostic command value 4712.

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

[0165] The example system 4700 includes a diagnostic execution circuit 4702 that further performs diagnostic data collection operations in response to the active diagnostic description 4705 and stores a diagnostic data set 4714 in response to the diagnostic data collection operations. For example, the active diagnostic description 4705 may include certain data parameters to be collected, vehicle state conditions to be monitored, and / or parameter thresholds to be determined (e.g., a temperature greater than a threshold). The stored target diagnostic data set 4714 may include the collected data, the vehicle state conditions determined therefrom, or a combination thereof. The collected data may be from endpoints 4708, 4710 responsive to the diagnostic command value 4712 (e.g., confirmation that an actuator has responded to the command, diagnostic data or fault codes related to the responsive actuator, etc.) or from endpoints 4708, 4710 other than those responsive to the command (e.g., observation of temperature, pressure, speed values, status confirmation, etc. not directly related to the operation endpoint 4708, 4710).

[0166] The example diagnostic execution circuit 4702 performs processing operations on the collected data during diagnostic data collection operations and stores a diagnostic data set 4714 in response to the processing operations. For example, the stored target diagnostic data set 4714 can include status information, virtual sensor information, adverse information (e.g., storing only data related to operation where a threshold is not met), upsampled and / or downsampled values ​​for the collected data, and / or any other processing operations listed throughout this disclosure. Exemplary, non-limiting processing operations on the collected data or portions thereof include compressing the collected data, summarizing the collected data, operating a virtual sensor using the collected data, determining vehicle operating conditions in response to the collected data, determining a diagnostic data set in response to the determination of vehicle operating parameters, performing an upsampling operation on the collected data, and / or performing a downsampling operation on the collected data.

[0167] The example diagnostic execution circuit 4702 further communicates a diagnostic data set 4714 responsive to the diagnostic data collection operation to an external device (e.g., 5618). The external device receiving the diagnostic data set 4714 can be the same or a different external device as the external device providing the active diagnostic description 4705. The example diagnostic execution circuit 4702 further processes the collected data before communicating it to the external device, which processing can include initial processing to determine a stored target diagnostic data set 4714 and / or further processing operations on the stored target diagnostic data set 4714 before communicating it to the external device. For example, the diagnostic execution circuit 4702 can store the diagnostic data set 4714 and transmit a portion of the diagnostic data set 4714 (e.g., selected parameters, active diagnostic results, etc.) to the external device. The example diagnostic execution circuit 4702 then performs selected operations, such as further processing the diagnostic dataset 4714 before communicating it to the external device (e.g., to reduce external data communication in response to data selected for transmission by the external device), and / or communicates the diagnostic dataset 4714 to the external device (e.g., in response to the availability of external communication such as a WiFi connection, a connected external device, etc., and / or as needed from the external device for all of the diagnostic dataset 4714), and / or communicates further selected portions of the diagnostic dataset 4714 (e.g., data requested by the external device), and / or retains the diagnostic dataset 4714 and / or a further processed form of the diagnostic dataset 4714 stored for a selected period of time, and / or deletes the diagnostic dataset 4714 after the diagnostic execution operation (e.g., in accordance with the results of an active diagnostic test and / or in accordance with a request from the external device).Operation of system 4700 can be seen to provide for the performance of active diagnostic operations by external devices (e.g., service tools, service applications, cloud-based applications, fleet service computing devices, and / or third-party applications) involved in endpoints on vehicles over a mixed network, provide diagnostic operations that do not require knowledge of the location and / or makeup of endpoints on the vehicles, can support multiple configurations of the vehicles, and / or can support configuration changes of the vehicles. Additionally or alternatively, operation of system 4700 can provide planned data transmission including reduced transmitted data while achieving powerful active diagnostic capabilities, and further enable planned consumption of on-vehicle processing, memory, and inter-network communication resources while achieving this powerful active diagnostic capabilities.

[0168] The example system 4700 includes a diagnostic validation circuit 4704 that determines a diagnostic confirmation value 4716 based on the actuator responses to the diagnostic command value 4712 (e.g., confirms whether the actuators performed the commanded function and / or whether the vehicle across the actuators performed an active diagnosis in accordance with the active diagnostic description 4705). The example diagnostic validation circuit 4704 stores the diagnostic confirmation value 4716 (e.g., as part of the diagnostic data set 4714) and / or communicates the diagnostic confirmation value 4716 to an external device. In certain embodiments, the diagnostic validation circuit 4704 adjusts the storage and / or communication of the diagnostic data set 4714 in response to the diagnostic confirmation value 4716, e.g., to ensure that the diagnostic data set 4714 is related to the performance of an active diagnosis. In certain embodiments, the diagnostic execution circuitry 4702 may store all or a portion of the diagnostic data set 4714 as a rolling buffer of data and save selected portions of the diagnostic data set 4714 in response to the diagnostic validation circuitry 4704 providing a diagnostic confirmation value 4716 (e.g., if the diagnosis has a time value or actuator position as part of the diagnostic execution, allowing the diagnosis to be fully determined when a timer or other accumulation state completes).

[0169] The example active diagnostic description 4705 includes a target device description 4718 (e.g., fuel actuator, engine controller, door actuator, mirror position adjustment actuator, etc.), which does not identify on which network zone 5612, 5614 the endpoint supporting it is located. The example system includes a configuration circuit 5604 that determines a network address value 4722 (e.g., a port number for an Ethernet network, a message ID for a CAN network, etc.) for the endpoint responsive to the target device description 4718, and the diagnostic execution circuit 4702 further provides a diagnostic command value 4712 to the endpoint responsive to the network address value 4722. For example, the target device description 4718 can include a standardized description for the endpoint (e.g., engine speed, ambient temperature, passenger seat occupancy sensor, etc.), and the configuration circuit 5604 has access to a configuration table that associates the standardized description with a local network address for the component for which it is intended. Additionally or alternatively, target device description 4718 may have a description matching a baseline product (e.g., the 2020LX version of a given vehicle), a description matching an original version of the vehicle (e.g., when the vehicle was configured after manufacture), and / or a description matching an earlier version of the vehicle (e.g., when the vehicle was as of a certain date). In certain embodiments, the configuration table or other information utilized by configuration circuit 5604 to determine network address value 4722 may be one or more configuration files maintained by the network interface circuit, a configuration file maintained by the policy management circuit, a configuration file maintained by the CND, and / or a configuration file maintained as part of policy 5606.

[0170] Example active diagnostic description 4705 includes a target device description 4718 (e.g., a fuel actuator, an engine controller, a door actuator, a mirror position adjustment actuator, etc.) that identifies an endpoint on one network zone (e.g., a first network zone 5612), and configuration circuit 5604 determines that the endpoint is on another network zone (e.g., a second network zone 5614) in response to target device description 4718. For example, configuration circuit 5604 may determine that target device description 4718 indicates an incorrect or absent device and / or further determine that an external device is utilizing a previous, different, and / or standardized configuration file to provide target device description 4718, in which case configuration circuit 5604 utilizes a local configuration file to determine the appropriate network address value and / or network zone for the endpoint specified by target device description 4718. In certain embodiments, the configuration circuit 5604 determines the proper network address value and / or network zone for this endpoint using other information from the target device description 4718, such as parameter names, intended function, etc. Similarly, the configuration circuit 5604 can correct the target device description 1718 that indicates an incorrect address, such as one address on the first network zone, when the correct address is another address on the first network zone, other than the incorrect network zone.

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

[0172] 49 , an exemplary system 4900 includes a vehicle 102 having a first legacy network zone 4902 and a second, advanced network zone 4904. For example, the first legacy network zone 4902 can be a first network type, such as a CAN bus, and the second advanced network zone 4904 can be a second network type, such as an Ethernet network. In certain embodiments, the second advanced network zone 4904 can be the same type as the first legacy network zone 4902, but can also be a more highly capable version, such as a high-speed CAN bus, a faster Ethernet network, etc. In certain embodiments, a system 4900 such as that shown in FIG. 49 can exist when a vehicle transitions to an upgraded network type, for example, during a transition over several vehicle model years, when new components utilizing a more highly capable network are added to the vehicle, and similar times.

[0173] The exemplary system 4900 includes a CND108 interposed between a first legacy network zone 4902 and a second advanced network zone 4904, where the CND108 includes a policy management circuit 5602 that interprets a policy 5606 including an external communication value 4906, and an external communication control circuit 4908 that coordinates communications between an external device 5618 and an end point of the first legacy network zone 4902 and / or an end point of the second advanced network zone 4904 in response to the external communication value 4906. For example, external communications between endpoints of the first legacy network zone 4902 may be restricted to reduce traffic generated by communications to and from external devices 5618 on the first legacy network zone 4902 and / or due to the need to protect endpoints on the first legacy network zone 4902 (e.g., if vehicle control and / or proprietary information is maintained on the first legacy network zone 4902 and / or if security protocols for the first legacy network zone 4902 are more restrictive than those available in the second high-performance network zone 4904). In another example, external communications between endpoints of the second advanced network zone 4904 can be limited (e.g., where the higher capability devices on the second advanced network zone 4904 may have the capability to generate high data rates) to reduce external transmissions from the vehicle (e.g., those that go through the vehicle's transceiver, those that utilize a specific data provider) due to the potentially large number of devices on the second advanced network zone 4904, including devices that may have been recently added to the vehicle (and therefore do not have a long known usage history, security pre-screening, and / or vehicle operation impact data) and / or devices that may have been added by an entity that is not as closely controlled as the provider of the devices on the first legacy network zone 4902 (e.g., devices that may be provided by a third party and that involve recently developed vehicle functions and / or entertainment providers that do not involve core vehicle functions).The reasons presented for restricting external traffic between endpoints on various networks and external devices are non-limiting and are presented for illustrative purposes, but the external communications control circuitry 4908 may regulate communications between endpoints in any network zone and any external device for any reason.

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

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

[0176] 50, an example procedure 5000 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5000 includes an operation 5002 for interpreting a policy including an active diagnostic description, an operation 5004 for providing an endpoint with a diagnostic command value in response to an active diagnostic condition, and an operation 5006 for commanding an actuator in response to the diagnostic command value.

[0177] 51, an example procedure 5100 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5100 includes an operation 5102 for interpreting a policy including an active diagnostic description and a diagnostic execution condition, and an operation 5104 for determining whether the vehicle operating conditions are consistent with the diagnostic execution condition and / or the diagnostic command value (e.g., determined from the active diagnostic description). In response to operation 5104 determining "YES," the procedure 5100 includes an operation 5004 for providing a diagnostic command value to an endpoint in response to the active diagnostic condition, and an operation 5006 for commanding an actuator in response to the diagnostic command value.

[0178] 52, an example procedure 5200 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5200 includes an operation 5002 for interpreting a policy including an active diagnostic description and an operation 5002 for performing a diagnostic data collection operation in response to the active diagnostic description. Additionally, the example procedure 5200 includes an operation 5004 for providing a diagnostic command value to an endpoint in response to an active diagnostic condition, and an operation 5006 for commanding an actuator in response to the diagnostic command value.

[0179] 53, an example procedure 5202 for performing a diagnostic data collection operation is generally depicted. The example procedure 5202 includes an operation 5302 for processing the collected data (e.g., processing payload and / or frame information of messages of the collected data), an operation 5304 for storing the collected and processed data, and an operation 5306 for communicating at least a portion of the stored data to an external device.

[0180] 54, an example procedure 5400 for storing and / or communicating a diagnostic confirmation value is generally depicted. The example procedure 5400 includes an operation 5002 for interpreting a policy including an active diagnostic description, an operation 5004 for providing an endpoint with a diagnostic command value responsive to an active diagnostic condition, and an operation 5006 for commanding an actuator in response to the diagnostic command value. Additionally, the example procedure 5400 includes an operation 5402 for determining a diagnostic confirmation value and an operation 5404 for storing and / or communicating the diagnostic confirmation value to one or more external devices.

[0181] Referring to Figure 55, an example procedure 5500 for commanding an actuator in response to a diagnostic command value is generally depicted. In addition to the operations listed with respect to Figure 50 and earlier, example procedure 5500 includes operation 5502 for determining whether the target device description indicates a network address value for a target endpoint for the commanded actuator (e.g., operation 5502 determines NO if the target device description does not point to a network address value or points to an invalid network address value). In response to operation 5502 determining YES, procedure 5500 proceeds to operation 5004. In response to operation 5502 determining YES, procedure 5500 includes operation 5504 for supplying or adjusting the network address value for the target endpoint, before proceeding to operation 5004.

[0182] Referring to FIG. 56, an example system 5600 for providing off-vehicle communication control consistent with embodiments of the present disclosure is shown. The systems described throughout this disclosure may be provided on a mobile application, such as in a vehicle, or as described throughout this disclosure. The example systems herein recite specific arrangements of, for example, a centralized network device (CND) 108, circuits, controllers, or other components. These arrangements are provided for purposes of clarity of this description, but these components may be distributed, combined, split, and / or have relationships distinct from those depicted to form the systems and implement the procedures described herein.

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

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

[0185] The example system 5600 includes a vehicle 102 having a first network zone 5612 and a second network zone 5614, where the first network zone 5612 and the second network zone 5614 are different types of networks. Without being limited to any other aspect of the present disclosure, the various types of networks described herein contemplate any differences in networks such as differences in network capabilities (e.g., bandwidth, message size, latency, noise sensitivity, etc.), differences in network protocols at any layer (e.g., hardware type, message frame requirements, addressing scheme, acknowledgment type, requirements, or capabilities, cast availability, e.g., unicast, multicast, and / or broadcast), network standard type (e.g., Controller Area Network (CAN), Media Oriented Systems Transport (MOST) network, Local Interconnect Network (LIN), FlexRay network, Time Triggered Protocol (TTP) network, Low Voltage Differential Signaling (LVDS) network, Audio Video Bridging (AVB) compliant network, customized versions of any one or more of these, and / or proprietary versions of any one or more of these). Exemplary network zones include electrical signal zones (e.g., networks where a corresponding network interface circuit interprets electrical signal values ​​as communications and / or provides electrical signal values ​​as communications to an endpoint of the electrical signal zone, e.g., a sensor providing an electrical value indicative of a sensed parameter value, a diagnostic value, etc., and / or an actuator that moves to a selected position and / or applies a selected force in response to the electrical value, and / or where the actuator can additionally or alternatively provide feedback and / or diagnostic information on the electrical signal zone). The electrical signal for the electrical signal zone can be of any type, including at least a voltage value, a frequency value, a current value, and / or a configured pulse width modulation (PWM) value, e.g., a duty cycle, an amplitude, a selective period, etc.

[0186] The example system 5600 further includes a policy management circuit 5602 that interprets a policy 5606 including a network regulation description (not shown), and a configuration circuit 5604 that includes at least one network interface circuit (e.g., a first network interface circuit 5608 corresponding to a first network zone 5612 and / or a second network interface circuit 5610 corresponding to a second network zone 5614) in response to the policy 5606. For example, the policy 5606 can be provided by an external device 5618 and / or can be pre-stored (e.g., at the time of manufacture, assembly, and / or during a previous update from the external device 5618), where the policy 5606 includes a network regulation description having an indication of devices on the vehicle 102 selected with respect to capabilities for utilizing the network zones 5612, 5614, for communicating between the zones, and / or for communicating with the external device 5618.

[0187] The example system 5600 includes a first network interface circuit 5608 provided as part of a CEG when a first network zone 5612 is a CAN bus network, and a second network interface circuit 5610 provided as part of a CES when a second network zone 5614 is provided as an Ethernet network. In this example, the first network interface circuit 5608 provides selected communications from the first network zone 5612 to the second network interface circuit 5610 at selected ports of the Ethernet network and / or receives selected communications from the second network zone 5614 at selected ports of the Ethernet network, thereby enabling inter-network communications between the first network zone 5612 and the second network zone 5614. In this example, communications from the first network zone 5612 to the external device 5618 may be provided through the second network zone 5614 (e.g., if the external device 5618 is coupled to the second network zone 5614 and / or wirelessly connected to the vehicle 102) or directly to the external device 5618 (e.g., if the external device 5618 is directly coupled to the first network zone 5612 or the CAN bus).

[0188] The exemplary system 5600 includes a first network zone 5612 as a virtual local area network (VLAN) that is logically separate from, but located on hardware that is at least partially shared with, the second network zone 5614. In this example, the first network interface circuit 5608 and the second network interface circuit 5610 may operate as elements of a network switch or router and control communications between endpoints in the first network zone 5612 and the second network zone 5614 in response to policy 5606.

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

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

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

[0192] The example policy management circuit 5602 receives policy communication 5616 from an external device 5618 and interprets the policy 5606 by performing operations such as storing the policy 5606 (e.g., in a memory location accessible to the policy management circuit 5602 and / or distributing it across several memory locations) and / or updating the stored policy 5606. In certain embodiments, the policy management circuit 5602 configures the policy 5606 for use by the network adjustment aspects of the system 5600 by, for example, updating the number of configuration files used by the interface circuits 5608, 5610, adjusting the high-level description of the policy communication 5616 into instructions executable by the network adjustment aspects of the system 5600 (e.g., limiting external communication data to 32 GB per month), adjusting criteria values ​​of the policy communication 5616 (e.g., associating the local address value of the endpoint described in the policy communication 5616 when the endpoint is moved without notification to the external device 5618 and / or when specific addressing information of the local device is abstracted from the external device 5618), associating system-specific designations (e.g., names or IDs of local parameter values, names or IDs of flows, names or IDs of applications, etc.) with elements of the policy description 5620, etc.

[0193] The example system 5600 includes an external device 5618 communicatively coupled to the policy management circuit 5602 through at least one of the first network zone 5612 or the second network zone 5614, for example, using a CAN bus port, an OBD port, an Ethernet port, a proprietary port, or other direct coupling to a network zone. The example system 5600 includes an external device 5618 communicatively coupled to the policy management circuit 5602 by a wireless connection, such as a WiFi connection, a cellular connection, and / or a Bluetooth connection.

[0194] The example system 5600 includes a policy management circuit 5602 that validates the policy 5606 communicated by the policy communication 5616 before storing and / or updating it. For example, the policy management circuit 5602 may require authentication of the external device 5618 and / or a determination of permissions associated with the external device 5618 before implementing changes to the policy 5606. In certain embodiments, the policy management circuit 5602 may determine the permissions associated with the external device 5618, the entity utilizing the external device 5618, the application or flow utilizing the external device 5618, etc. before implementing changes to the policy 5606. In certain embodiments, the policy management circuit 5602 may reject the policy communication 5616 if the policy 5606 contained in the policy communication 5616 is greater than the permissions associated with the external device 5618 and / or if the policy 5606 cannot be enforced (e.g., executing the policy 5606 is deemed greater than the capabilities of the system 5600, such as network zone bandwidth, external communication limits, memory storage limits, etc.). In certain embodiments, the policy management circuit 5602 can partially enforce the policy communication 5616 if the policy 5606 contained in the policy communication exceeds the permissions associated with the external device 5618 and / or if the policy 5606 cannot be fully enforced. For example, the policy management circuit 5602 can implement authorized portions of the policy communication 5616 and / or portions of the policy communication 5616 that the system 5600 has the capability to implement.In certain embodiments, the policy management circuit 5602 implements portions of the policy communication 5616 according to priority, such as the associated endpoint, flow, application, or vehicle function of the policy communication 5616, for example, when full implementation is greater than the system's capabilities (e.g., implementing higher priority aspects until a lim...

Claims

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

2. 10. The system of claim 1, wherein the policy management circuitry is further configured to receive a policy communication from an external device and interpret the policy by one of storing the policy or updating a stored policy in response to the policy communication.

3. The system of claim 2 , wherein the external device is communicatively coupled to the policy management circuitry through at least one of the first network zone or the second network zone.

4. The system of claim 2 , wherein the external device is communicatively coupled to the policy management circuitry through at least one of a wireless network connection or a cellular network connection.

5. The system of claim 2 , wherein the policy management circuitry is further configured to validate the policy before performing one of storing the policy or updating the stored policy.

6. The system of claim 5 , wherein the policy management circuitry is further configured to provide a notification to the external device in response to verifying the policy.

7. The system of claim 1 , wherein the policy includes at least one data collection parameter.

8. the policy includes a permission value corresponding to at least one endpoint of the first network zone or the second network zone; The permission value includes at least one permission value selected from the group consisting of a data collection permission value, a service publication permission value, a service subscription permission value, and an external communication permission value. The system of claim 1 .

9. The system of claim 1 , wherein the policy is communicated to the CND from an external device.

10. 1. A system comprising: a first network zone of vehicles including a first plurality of interconnected endpoints; a second network zone for the vehicle including a second plurality of interconnected endpoints; a centralized network device (CND) interposed between the first network zone and the second network zone and configured to coordinate communications between endpoints in the first network zone and the second network zone; a first vehicle controller on the first network zone; a second vehicle controller on the second network zone; network redundancy circuitry structured to selectively provide coordinated control commands; Including, the CND is further configured to adjust the coordination of the communication between an end point of the first network zone and an end point of the second network zone in response to the coordination control command. system.

11. The system of claim 10 , wherein the regulatory control command includes an abnormal condition corresponding to the first vehicle controller.

12. the abnormal condition includes a loss of a data element; adjusting the adjusted communication includes providing an alternative data element to the first vehicle controller. The system of claim 11.

13. the abnormal condition includes a loss of control function of the first vehicle controller; adjusting the adjusted communication includes providing a data element corresponding to the control function of the first vehicle controller to the second vehicle controller. The system of claim 11.

14. The system of claim 13 , wherein the lost control function comprises one of a partial loss or a complete loss of the control function.

15. the loss control function utilizes a data value provided by an endpoint on the first network zone; adjusting the adjusted communication includes providing the data value to the second vehicle controller. The system of claim 13.

16. the loss control function utilizes a data value provided by an endpoint on the second network zone; adjusting the regulated communication includes suppressing communication of the data value to the first network zone. The system of claim 13.

17. coordinating the communication includes processing data values ​​from endpoints on the second network zone into processed data values ​​and providing the processed data values ​​to the first vehicle controller; the loss control function utilizes the processed data values; adjusting the adjusted communication includes providing the processed data values ​​to the second vehicle controller.

17. The system of claim 16.

18. The system of claim 10 , wherein the adjustment control command comprises a loss of functionality of the first vehicle controller.

19. the first vehicle controller is positioned in a first risk exposure profile; the second vehicle controller is positioned at a second risk exposure profile; the first risk exposure profile is distinct from the second risk exposure profile; The system of claim 10.

20. 72. The system of claim 71, wherein the distinction between the first risk exposure profile and the second risk exposure profile comprises a geometric distinction.

21. 72. The system of claim 71, wherein the distinction between the first risk exposure profile and the second risk exposure profile comprises an environmental distinction.

22. The system of claim 10 , wherein the regulatory control instructions include an abnormal condition corresponding to the first network zone.

23. 23. The system of claim 22, wherein the abnormal condition includes at least one condition selected from the following conditions: a loss of communication between at least one endpoint of the first network zone and the first network zone, a physical failure of at least a portion of the first network zone, and a bandwidth limitation of the first network zone.

24. 1. A system comprising: a vehicle having a first network and a second network; a first device on the first network; a centralized network device (CND) interposed between the first network and the second network and structured to facilitate communication between the first device and the second network; Including, the first network is of a different type than the second network; system.

25. a second device on the second network and configured to communicate with the first device through the CND; 25. The system of claim 24, further comprising:

26. an external device communicatively coupled to the CND and structured to adjust a configuration of the CND; 25. The system of claim 24, further comprising:

27. 25. The system of claim 24, wherein at least one of the first network and / or the second network is a Controller Area Network (CAN) based network.

28. 25. The system of claim 24, wherein at least one of the first network and / or the second network is an Ethernet-based network.

29. 30. The system of claim 28, wherein the Ethernet-based network comprises a data bus architecture.

30. 25. The system of claim 24, wherein the first network is a controller area network (CAN)-based network and the second network is an Ethernet-based network.

31. The CND is a configurable edge gateway (CEG) configured to access the CAN-based network; an Ethernet switch configured to access said Ethernet-based network; Including, the CEG providing messages to the Ethernet switch in response to corresponding messages on the CAN-based network; 31. The system of claim 30.

32. 32. The system of claim 31, wherein the CEG is configured to provide the message to the Ethernet switch as an Ethernet message that includes an encapsulated CAN message based on the corresponding message on the CAN-based network.

33. the CEG is positioned in a first housing; the Ethernet switch is positioned in a second housing; 32. The system of claim 31.

34. the CEG is disposed on a first substrate; the Ethernet switch is positioned on a second substrate; 32. The system of claim 31.

35. a vehicle having a first network and a second network of a different type than the first network; interposed between the first network and the second network; and configured to generate network status data by monitoring communications of one or more devices on the first and / or second networks, and to transmit the network status data to a sensor device external to the vehicle. a centralized network device (CND); Including, the system.

36. the CND includes a plurality of ports on the first network; the CND is further configured to configure at least a first port of the plurality to mirror at least a second port of the plurality; 36. The system of claim 35.

37. the CND includes a plurality of ports on the first network; The CND is assigning a first device of a plurality of devices on the second network to a port of the plurality; and transmitting the network status data to the sensor device on the first network through at least one port of the plurality of ports; It is further structured as follows:

37. The system of claim 36.

38. 38. The system of claim 37, wherein the second network has a bus topology and the first network has a star topology.

39. The CND is modifying the network status data; It is further structured as follows:

36. The system of claim 35.

40. The CND is selectively modifying said network status data in response to data selection command values; and including in the network status data data corresponding to at least one device on the first or second network identified by the data selection command value; It is further structured as follows:

40. The system of claim 39.

41. The CND is selectively modifying said network status data in response to data selection command values; and including in the network status data data corresponding to one or more systems of the vehicle identified by the data selection command value; It is further structured as follows:

40. The system of claim 39.

42. The CND is selectively modifying said network status data in response to data selection command values; and including in the network status data data corresponding to at least one protocol identified by the data selection command value; It is further structured as follows:

40. The system of claim 39.

43. 43. The system of claim 42, wherein the identified protocol includes one of a controller area network (CAN) or an on-board diagnostics (OBD).

44. 36. The system of claim 35, wherein the first network and / or the second network are controller area network (CAN) based.

45. a vehicle having an Ethernet-based network and a Controller Area Network (CAN)-based network; a CAN vehicle control device located within the vehicle, connected to the CAN-based network, and configured to control operation of components of the vehicle; an Ethernet vehicle control device located on board the vehicle, connected to the Ethernet-based network, and structured to electrically communicate with the CAN vehicle control device; an Ethernet switch located onboard the vehicle, the Ethernet switch having a plurality of physical ports connected to the Ethernet-based network, at least one physical port of the plurality forming part of a physical network path between the Ethernet switch and the Ethernet vehicle control device; a CAN gateway located within the vehicle and connected to the CAN-based network and the Ethernet switch; network convergence circuitry defined at least in part by the Ethernet switch and / or the CAN gateway and structured to facilitate electronic communications between the Ethernet vehicle control device and the CAN vehicle control device by converting and forwarding data messages between the Ethernet-based network and the CAN-based network; Including, the system.

46. 46. ​​The system of claim 45, wherein the network-centralized circuitry is selectively configurable through configuration commands sent over the Ethernet-based network from a service device external to the vehicle.

47. a first physical port of said plurality selectively mirroring a second physical port of said plurality in response to said configuration command value; 47. The system of claim 46.

48. 47. The system of claim 46, wherein the configuration circuitry is further configured to modify the CND through selectively configuring which of one or more portions of the CND are defined by the Ethernet switch and / or the CAN gateway.

49. 1. An apparatus comprising: a first network interface circuit configured to interpret the first set of Ethernet data and transmit a second set of Ethernet data; a second network interface circuit configured to transmit a first controller area network (CAN) data set and to interpret a second CAN data set; determining a first message value from the first Ethernet data set and encapsulating the first message value in the CAN data set; and determining a second message value from the second CAN data set and encapsulating the second message value into the second Ethernet data set; a conversion circuit structured as follows: Including, the first network interface circuit, the conversion circuit, and the second network interface circuit are defined by an Ethernet switch and / or a CAN gateway, both configured to be integrated into a vehicle; Device.

50. 50. The apparatus of claim 49, further comprising a configuration circuit defined by the Ethernet switch and / or the CAN gateway and structured to modify the first network interface circuit, the conversion circuit, and / or the second network interface circuit in response to configuration command values.

51. 51. The apparatus of claim 50, wherein the configuration circuitry is further configured to selectively configure which of one or more portions of the first network interface circuit, the conversion circuit, and / or the second network interface circuit are defined by the Ethernet switch and / or the CAN gateway.

52. 50. The apparatus of claim 49, wherein the first network interface circuit is defined by the Ethernet switch and the second network interface circuit is defined by the CAN gateway.

53. 53. The apparatus of claim 52, wherein the conversion circuit is defined by the CAN gateway.

54. 53. The apparatus of claim 52, wherein the conversion circuitry is defined by the Ethernet switch.

55. 1. A system comprising: a vehicle having a first network zone and a second network zone; a centralized network device (CND) interposed between the first network zone and the second network zone; Including, The CND is a policy management circuit configured to interpret a policy including a network adjustment description and including default policy values; a configuration circuit structured to configure at least one network interface circuit in response to said external data routing description and said external data service description; the at least one network interface circuit configured to coordinate communications between an endpoint of the first network zone and an endpoint of the second network zone; Including, system.

56. the policy further includes a primary policy value; the configuration circuitry is further configured to configure the at least one network interface circuit in response to the primary policy value.

56. The system of claim 55.

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

58. the policy further includes a secondary policy value; the configuration circuitry is further configured to configure at least one network interface circuit in response to the secondary policy value.

57. The system of claim 56.

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

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

61. the default policy values ​​include a permanent storage policy; the primary policy value includes a tool-supplied policy; 57. The system of claim 56.

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

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

64. the default policy values ​​include a permanent storage policy; the primary policy value includes a tool-supplied policy; 59. The system of claim 58.

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

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

Images