JPWO2021055952A5 - - Google Patents

Description

[Cross reference to related applications]
This application is based on a provisional patent application filed on September 20, 2019 entitled "SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK." No. 62/903,462 (SONA-0001-P01), filed on October 5, 2019, titled “SYSTEM, METHOD AND APPARATUS FOR A MIXED VEHICLE NETWORK” ``Systems, Methods, and Apparatus for Cloud-Based Interaction with Mixed Vehicle Networks (SYSTEM, 62/911,248 (SONA-0003-P01), March 2020 “Configurable vehicle related” application filed on the 6th U.S. patent application Ser. SONA-0004-P01), and U.S. Patent Application No. 63/024 entitled “SYSTEM, METHOD AND APPARATUS TO TEST AND VERIFY A VEHICLE NETWORK” filed May 13, 2020. , No. 383 (SONA-0005-P01).

Each of the above-mentioned applications is incorporated herein by reference in its entirety.

Vehicle communication networks are utilized to connect sensors, actuators, controllers, and communication devices throughout the vehicle. With more devices connected, more data passed between devices, lower latency requirements to meet vehicle performance, safety, and emissions requirements, and added vehicle features, The trend is increasing the burden on these vehicle communication networks. In addition to this, consumers expect ever-increasing connectivity and functionality, which increases the burden on vehicle communication networks. These trends are expected to continue and accelerate for the foreseeable future.

Conventional vehicle communication networks (CAN, LIN, FlexRay, MOST, LVDS, etc.) have several drawbacks and challenges. These vehicular communication networks have been developed to meet the specific challenges of the vehicular environment, and therefore include computer local area networks, wide area networks, large-scale interconnection networks (e.g., the Internet), and others such as wireless networks. It was developed separately from the network. Most vehicle networks consist of a data link layer and an application layer, such as a controller area network (CAN) bus, with dedicated or shared wiring between devices that utilize specific data protocols (e.g., J1939, OBD, etc.). Utilize robust and dedicated equipment. Modern vehicles may have multiple network buses where specific commands and communications are available and limited customization and data rates are available. For example, CAN buses typically operate at up to about 1 Mbps, and high-performance CAN buses operate at up to about 10 Mbps. In addition to this, CAN buses experience latencies longer than 25ms and typically longer, from about 60ms to 500ms depending on configuration, traffic on the CAN, and priority for particular messages, etc. .

As the number of devices and data rate demands from the devices increase, conventional vehicular communication networks require higher performance bus implementations. Because the auto industry is a high-volume industry with very low tolerance for component failure, auto manufacturers utilize the same components for long periods of time and across a wide range of vehicles, making it difficult to maintain configurations between manufacturers. Including sharing elements. In addition to this, changes to components of nominally higher functionality may introduce risks, 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-functioning network configurations, it is important to keep network types separate within the system and to maintain a large number of legacy devices (e.g., CAN-enabled) within the system for long periods of time. It is desirable to maintain this for a long time.

Data collection from vehicles includes some additional challenges. For example, data collection operations are subject to regulation and debt risk, 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 retaining the data, for example, in the event of inadvertent or malicious access to the data. Regarding vehicle data being collected, large amounts of data may be collected and there may be numerous purposes for collecting the data, which may pose risks compared to other common data storage uses. It increases. Therefore, it may be desirable to control data collection, storage, and access to reduce risk, and may include verification of data access and partitioning or other elimination of data when it is not in use. It may be even more desirable.

Data collection on vehicles is further complicated by the amount and type of data that will be communicated between the vehicle and external devices, and vehicle network systems are subject to mobile applications, cost, and/or high data rates and/or Limited by bandwidth limitations imposed by large data transfers. Having said all this, customer demands, market expectations, increasing requirements regarding the efficiency of vehicle operation, and increasing functional capabilities for data-related applications are driving the overall amount of data that will be transferred, The number of applications, the number of purposes for which data can be utilized, and the number of users or entities that have a legitimate need for each piece of data to be transferred continues to proliferate. In addition to this, the applications that utilize the data continue to grow in sophistication and power, increasing data demands on the limited available transfer resources and increasing the cost and complexity of the logistical control and storage of transferred data. . For example, more sophisticated routing or actuation algorithms associated with vehicles, increasing automation of vehicle functions, increasing demands for predictive decision making and/or maintenance support, and increasing media streams (the number of media streams and (both quality and quality) are all driving increasing demands on data speed, amount of stored data, and number of entities or applications accessing the stored data.

The description herein refers to vehicle applications by way of 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 may have multiple end points, including multiple data sources, controllers, sensors, and/or actuators, and to any application that may further include endpoints residing in different network and/or distributed network environments and/or may be transitioning to newer and/or more capable network connectivity or communication systems. It is applicable to applications that have historical or legacy network connectivity or communication systems (within a given system, as a division of a system, and/or as an industry). Exemplary and non-limiting embodiments include 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. Certain features, aspects, and/or advantages of the present disclosure may be applicable to any one or more of these applications and may not be applicable to other of these applications. However, the applicability of certain features, aspects, and/or advantages of the present disclosure may depend on the operating conditions, constraints, and cost parameters of a particular application (e.g., operating costs, integration costs, operating costs, communication of data). It will be appreciated that this may vary depending on costs and/or storage costs, service costs, and/or downtime costs, etc.). Accordingly, as will be understood by those skilled in the art who have the benefit of the present disclosure, the present disclosure when referring to vehicles, vehicle systems, mobile applications, industrial equipment, robotic systems, and/or manufacturing systems, Certainly each of these is also contemplated herein and may be applicable in certain embodiments or not applicable in certain other embodiments.

The disclosure herein as reflected in the described embodiments demonstrates that the above-listed complexities and other challenges cause the complexity of the vehicle data environment to be greater than the sum of the individual contributions from each challenge. It has been recognized that there is a synergistic effect.

As an example, an increase in the number of entities or applications accessing data increases the likelihood that individual data requests will become repetitive, for example, if multiple entities request the same or similar data. Furthermore, the increasing number of entities or applications accessing data requires that members of these access groups have similar authorizations, such that data access for individual members of the entity group or application group will benefit from data management. Increase the likelihood that you will end up sharing a level.

In another example, regulations regarding sensitive data are increasing, which not only increases data management requirements for systems in general, but also makes data management subject to multiple constraints and/or regulations at a given point in time. There is also an increased likelihood of being subject to constraints that change over time as the vehicle changes, and/or constraints that change based on the applicable jurisdiction, which may change as the location of the vehicle changes.

In yet another example, the complex environment of currently known and transitioning vehicle network architectures, e.g., vehicles with mixed network types and/or segmented networks, increases the complexity of data access for individual entities; This is because, without using certain aspects of the present disclosure, it would otherwise be necessary to determine required parameter specifications for particular data elements and update these required parameters as the vehicle network architecture evolves. There may be cases where In view of the increasing number of entities requesting data access, the total cost to the automotive support market increases non-linearly as each entity incurs the cost of tracking required parameter specifications. In addition to this, the trajectory of additional entities requesting data access is moving towards entities located far away from the core vehicle functions within the technical knowledge space, and thus the on-vehicle network. The complexity and specificity of vehicle applications and/or automotive applications, including configuration, specific data descriptions, data request and communication protocols, industry norms or conventions for providing information, etc., increases with each new entity. As a whole, cost-volume functions (e.g., car manufacturers and/or vehicle markets, geographic markets, and/or industries such as the automobile industry, the passenger car industry, etc.) are becoming less familiar. This further increases the cost over time for a given entity to reach the desired data collection product. For example:
Consider a nominal cost-volume function such as COST = Number of Entities ^* Basic Learning Cost ^* Migration Adaptation Cost Trajectory ^* Data Trajectory Cost ^* Regulatory Adaptation Cost ^* Data Access/Storage Obligation Cost.

The described COST function illustrates how the various challenges and drawbacks of currently known systems interact to create synergies that increase the cost of achieving future data collection capabilities for vehicle applications. This is a non-limiting, nominal example for illustrative purposes. The described cost parameters are not intended to cover all costs associated with the automotive data collection industry or the challenges that exist with currently known systems. Parameters may be averages or other complex functions, and the value of a particular parameter will generally not be known by virtue of its singularity. In addition to this, units of COST are measured as resources (e.g. man-hours, computation time, etc.) to reach data collection targets over time, e.g. carbon dioxide equivalents, customer satisfaction, risks incurred, loss of public perception, etc. or can be expressed as another non-monetary unit such as gain. The number of entities parameter generally reflects the number of entities accessing vehicle data over time, and the base learning cost is the amount by which new entities learn the details of data collection requirements and protocols for a particular vehicle, vehicle type, market, etc. The transition adaptation cost trajectory reflects the cost of learning and adapting to changing vehicle network configurations, including network types and organization, and interactions with endpoints or devices on these networks; Data trajectory costs include communication and storage of data and derived functional consequences such as inability to support desired applications or costs to improve the data communication infrastructure over time from the corresponding vehicle. Regulatory adaptation costs reflect the increasing demands for data collection, reflect the costs associated with an increasing number of regulations, an increasing number of regulatory frames, and/or an increasing number of regulatory authorities, and reflect the costs associated with an increasing number of regulations, an increasing number of regulatory frames, and/or an increasing number of regulatory authorities, and Storage liability costs reflect costs incurred with respect to data compliance and security, and/or losses incurred due to data breaches, unauthorized use, premature expiration of data, and the like.

Without being limited to any other aspect of the present disclosure, aspects of the disclosure herein include the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, the cost of each entity added to a data collection system, The basic learning costs to implement, the costs of adapting to changing vehicle network configurations, the costs incurred to meet increasing demands for data collection, the costs of adapting to a changing regulatory environment, and/or the costs of protecting data. reduce and/or eliminate any one or more of the costs 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. While certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters, the target vehicle, vehicle type, entity, industry, etc. beneficial by reducing the overall cost function for etc. Certain embodiments and/or aspects of the disclosure herein may increase one or more given cost parameters while providing other benefits, such as improved functionality. In certain embodiments, functional improvements may be achieved at a lower cost than previously known systems configured to achieve similar functional improvements, although at a higher cost.

Without being limited to any other aspect of the present disclosure, embodiments herein provide for operation of a system that has multiple networks, endpoint devices are distributed across the networks, and Transfer data, communications, and/or commands to endpoint devices 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. Provide the actuation you want to use. Embodiments herein provide a configuration for network management and processing of manufacturing, body building, service, upfits or upgrades, part replacements, maintenance, campaigns, part changes, and/or industry code changes. Adaptation to changes in the location of endpoint devices within the system, failures or malfunctions of the system, and/or updates to the system that may occur during the process. Embodiments herein provide monitoring of network status and/or performance for a network on a vehicle, including monitoring when the vehicle is intermittently connected to external devices. Embodiments herein provide configuration changes to monitor operations, including changes to monitored networks, monitored parameters, and monitor event execution. Embodiments herein provide endpoint devices, network communications, communications between specific endpoints (on the same or distinct networks), and monitoring operations of these configurations. Embodiments herein provide control, coordination, and/or support of network traffic both on a particular network or between networks. Embodiments herein provide for embedding functionality within existing controllers, distributing functionality between controllers, providing redundancy and malfunction support, and distributing functionality between similar systems while supporting full functionality. providing selective distribution of network management, monitoring, and control functions, including providing a diversity of redundancy and malfunction support, and combinations thereof. Embodiments herein provide monitoring operations for endpoint devices, network communications, and communications between particular endpoints when a monitor application or device communicates with a first network and monitors a second network. provide. Embodiments herein provide for monitoring any network, network zone, flow, device group, virtual group, etc. that may exist within the system.

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 describe devices, endpoints, controllers, flows, devices, functionality of a vehicle that can reside on any network of a vehicle and/or be distributed across more than one network of a vehicle. The method includes enabling active control from a device, application, or controller capable of communicating with any network of the system, such as for applications in a vehicle or a vehicle. Additionally or alternatively, embodiments herein provide control after changes to controlled devices, endpoints, controllers, flows, devices, vehicle functionality, and/or vehicle applications. Active control of a device can be supported with selective levels of knowledge about changes made by the device, application, or controller, including a level without any knowledge of this change. Embodiments herein describe devices, endpoints, controllers, flows, devices, functionality of a vehicle that can reside on any network of a vehicle and/or be distributed across more than one network of a vehicle. or enabling active monitoring, service event execution, and/or test execution from a device, application, or controller capable of communicating with any network of the system, such as for applications in a vehicle, or for applications in a vehicle. Additionally or alternatively, embodiments herein provide control after changes to controlled devices, endpoints, controllers, flows, devices, vehicle functionality, and/or vehicle applications. may support active monitoring of devices, service event execution, and/or test execution with selective levels of knowledge of changes made by the device, application, or controller, including levels without knowledge of any of this change; can.

Embodiments herein apply to mixed networks and/or scalable network topologies that include mixed networks and/or multiple instances of a given network type (e.g., isolated and/or partially isolated networks). handle. The number and placement of networks should, at a minimum, allow for a mix of legacy and new devices, the physical location and functional separation of networks, changes to the vehicle during service, maintenance, upgrades, and/or model changes; The invention may be configured to support any aspect of vehicle design, operation, and life cycle management including/or reducing design effort and/or integration effort and/or compartmentalization. Embodiments herein support, but are not limited to, dual-zone network architectures and/or n-zone network architectures.

Embodiments herein may reduce the number of physical connections to a network system, for example, to reduce the number of controllers and/or processing devices that must be installed, integrated, and/or have interfaces therebetween. to reduce risks, to reduce the cost of the network system, and/or to reduce the footprint of the network system (e.g., to reduce the overall footprint of the vehicle and/or to another system of the vehicle). support aggregation of control that may otherwise be distributed around the system in order to allow a complete or partial shift of the footprint of the system. Embodiments herein include extracting data providers from data consumers; implementing data authorization, security, and partitioning; reducing network traffic; and managing functional differences between devices, networks, etc.

Embodiments herein provide configuration of a mixed network control device that includes an interface to enable configuration of a network management application, a network control application, and a network monitor application. Accordingly, embodiments herein provide for interfacing networks and collecting, encapsulating, and/or processing communications from a first network for communication onto a second network. provides a configuration of mixed network control subcomponents including interfaces to devices etc. that facilitate Embodiments herein may include external tools (e.g., service tools, manufacturing tools, diagnostic tools, (e.g., consumer devices); In certain embodiments, a configuration tool herein can be an external tool, a web application, a mobile application, a dedicated or proprietary application, or a combination thereof.

To facilitate an understanding of the principles of the present disclosure, reference is now made to the embodiments illustrated in the drawings and described in the specification below. It is understood that this reference is not intended to limit the scope of the present disclosure. The present disclosure includes all variations and modifications to the illustrated embodiments, and the present disclosure contemplates any further uses of the principles disclosed herein that would commonly occur to those skilled in the pertinent art. It is further understood that including.

1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a centralized network device (CND); FIG. 1 is a schematic diagram of a configurable Ethernet switch; FIG. 1 is a schematic diagram of a configurable edge gateway; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. 1 is a schematic diagram of an exemplary system for coordinating a network on a vehicle according to certain embodiments of the present disclosure; FIG. FIG. 3 depicts example operations for processing messages. FIG. 3 depicts an example operation of downsampling a message. FIG. 3 depicts an example operation of upsampling a message. 1 is a schematic diagram of a system for coordinating a network on a vehicle in accordance with certain embodiments of the present disclosure; FIG. 2 is a schematic diagram depicting network zones within a distributed risk profile; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle in accordance with certain embodiments of the present disclosure; FIG. 1 is a schematic diagram depicting a distributed CND with network redundancy circuitry; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle in accordance with certain embodiments of the present disclosure; FIG. 2 is a schematic flow diagram depicting an example procedure for adjusting inter-network communication coordination. 1 is a schematic flow diagram depicting an example procedure for encapsulating communications; 1 is a schematic flow diagram depicting an example procedure for processing communications; 1 is a schematic diagram of a system for providing data services; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle; FIG. 1 is a schematic diagram of a system for coordinating a network on a vehicle; FIG. 1 is a schematic diagram depicting example network coordination components; FIG. 1 is a schematic diagram depicting example network coordination components; FIG. 1 is a schematic diagram depicting example network coordination components; FIG. 1 is a schematic flowchart of a procedure for publishing a data service; 3 is a schematic flowchart of a procedure for encoding a first network data set into a second network data set; FIG. 1 is a schematic flow diagram of a procedure for providing network status data; 3 is a schematic flow diagram of a procedure for mirroring ports; FIG. 3 is a schematic flowchart of a procedure for encoding a first network data set; FIG. 1 is a schematic flow diagram of a procedure for performing an active test procedure. 1 is a schematic flowchart of a procedure for coordinating a network of vehicles; 1 is a schematic flow diagram of a procedure for coordinating inter-network communication of a vehicle; 1 is a schematic flowchart of a procedure for encoding an Ethernet-based data set; 1 is a schematic flow diagram of a procedure for providing network status data; 1 is a schematic flowchart of a procedure for implementing control operations; 1 is a schematic flow diagram of a procedure for providing external message values; It is a schematic diagram of CND. FIG. 2 is a schematic diagram of the endpoints of a network responsive to actuator command values. 1 is a schematic diagram of a system for coordinating network communications of a vehicle; FIG. 2 is a schematic flowchart of a procedure for commanding an actuator. 2 is a schematic flowchart of a procedure for commanding an actuator. 2 is a schematic flowchart of a procedure for commanding an actuator. 1 is a schematic flow diagram of a procedure for transmitting collected data to an external device. 1 is a schematic flowchart for performing active diagnosis; 2 is a schematic flowchart of a procedure for commanding an actuator. 1 is a schematic diagram of a system for coordinating network communications of a vehicle; FIG. 1 is a schematic flow diagram of a procedure for coordinating network communications of a vehicle; 1 is a schematic flow diagram of a procedure for coordinating network communications of a vehicle; 1 is a schematic flow diagram of a procedure for coordinating network communications of a vehicle; 1 is a schematic diagram of a system for coordinating network communications of a vehicle using planned policies; FIG. 1 is a schematic diagram of a system for providing visualization data of a network of vehicles; FIG. 2 is a schematic diagram of an example local DNS table; FIG. FIG. 3 is a schematic diagram of an example of vehicle communication data. FIG. 2 is a schematic diagram of an example of visualized data. FIG. 2 is a schematic diagram of an example of visualized data. FIG. 2 is a schematic diagram of an example of visualized data. FIG. 2 is a schematic diagram of an example of visualized data. FIG. 2 is a schematic diagram of an example of visualized data. FIG. 2 is a schematic diagram of a visualization management controller. 1 is a schematic flowchart of a procedure for providing visualization data; 1 is a schematic flowchart of a procedure for providing visualization data; 1 is a schematic diagram of a system for coordinating network communications of a vehicle; FIG. 1 is a schematic diagram of an example policy; FIG. 1 is a schematic diagram of an example policy; FIG. 1 is a schematic diagram of an example policy; FIG. 1 is a schematic flow diagram of a procedure for coordinating network communications of a vehicle; 1 is a schematic flowchart of a procedure for providing visualization data; 2 is a schematic flow diagram of a procedure for updating a policy. 1 is a schematic diagram of a system for coordinating network communications of a vehicle; FIG. 1 is a schematic diagram of an example policy; FIG. 1 is a schematic flow diagram of a procedure for coordinating network communications of a vehicle;

Referring to FIG. 1, an exemplary system schematically illustrates aspects of embodiments of the present disclosure. The example system includes an application 102 (eg, a vehicle) having a first network 104 and a second network 106. As used herein, networks should be understood broadly and include hardware implementation (e.g., wire and wiring configurations, applicable standards, e.g., connectors, insulation, shielding, wire requirements, e.g., standard dimensions, (stranded organization, coaxial organization, etc.), implementation of any layer (e.g. from the ISO 7 layer model, e.g. application layer, presentation layer, session layer, transport layer, network layer, data link layer, and/or physical (although a given network may have fewer layers and/or layers organized in a distinct manner) and/or All or part can be wired or wireless. Without limiting any aspect of the present disclosure, exemplary and non-limiting networks include a Controller Area Network (CAN), a Media Oriented System Transport (MOST) network, a Local Interconnect Network (LIN). , a FlexRay network, a time-triggered protocol (TTP) network, a low voltage differential signaling (LVDS) network, and/or an Ethernet-implemented network. In certain embodiments, the one or more networks include electrical signal zones such as sensors or actuators electrically coupled to an interpretation device (e.g., electrical signals such as voltage values, frequency values, indicated resistance values, etc.). (a device that provides data and/or receives commands as a device), and an interpretation device that receives information from and/or transmits information to one or more electrical devices on the electrical signal zone. Or has the function of passing instructions.

The example 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 are to be understood broadly and may include different protocols, at least one layer that is distinctly different from each other (e.g., a distinct application layer, presentation layer, etc.). two networks that are not operationally compatible (e.g., a device coupled to one of these networks will not function on the second network without changes to connectivity, communication, or other aspects) ), and/or two networks that are message incompatible (e.g., configured for the first of the networks due to differences in addressing, frame structure, logical compatibility of messages, etc.) (a message cannot be placed directly onto a second one of the networks). The example system includes a first network 104 that is an Ethernet-implemented network and a second network 106 of a different type, such as a CAN network and/or a LIN network.

The example system includes a centralized network interposed between a first network 104 and a second network 106 that is structured to facilitate communication between the first network 104 and the second network 106. The device further includes a converged network device (CND) 108 . A CND 108 inserted between networks 104, 106 passes communications between networks 104, 106, e.g., receives communications from first network 104 and converts communications toward second network 106 ( For example, encapsulating all or a portion of the communication in a message for the second network 106 and/or changing aspects of the communication, such as device addresses, bit depth for the data, and/or unit values for the data. and/or adding or removing aspects of communication such as priority information, message delivery requirements or requirements, and industry standard information such as message identifiers). In certain embodiments, CND 108 does not physically pass communications or only partially pass communications, but may coordinate, manage, or grant permissions, throttle messages, or receive communications between networks. Other devices (eg, switches, routers, gateways, repeaters, etc.) that perform the handing operation may be controlled by others. Accordingly, a CND 108 inserted between networks 104, 106 may be physically located between networks 104, 106 in certain embodiments such that communications to and from networks 104, 106 are physically received by a component of the In certain embodiments, a CND 108 inserted between networks 104, 106 provides visibility into communications on networks 104, 106 and controls to regulate the passing of messages between these networks. device. In certain embodiments, a CND 108 inserted between the networks 104, 106 is configured to coordinate the visibility of the endpoints on the networks 104, 106 and the passing of messages between the endpoints of each network 104, 106. and a control device.

A person skilled in the art who has the benefit of the disclosure of the present invention and who has the information normally available when considering a particular system will be able to understand one of the intervention schemes described above and/or more than one of these intervention schemes. The CNDs 108 can be easily arranged according to the combination of objects. Certain considerations when designing an intervention scheme for a CND 108 for a given system include the number and type of networks on the vehicle, the capabilities of the individual networks (e.g., the throughput, bandwidth, address availability, broadcast/unicast/multicast availability and desirability, acknowledgment requirements and/or availability for each network and/or endpoint; encryption requirements and/or availability for endpoints), availability, location, and/or control on networks implementing multiple controllers (e.g., presence and ownership of switching devices, firmware for available devices) or access to instructions such as buffers, 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 responses. the capabilities of the network implementing multiple controllers (e.g., buffer sizing and availability, message rate capacity, processing capacity); Hardware cost considerations for adding, providing functionality for CND operation within other components of the system, implementing additional CND specific components and/or for CND operation integration cost considerations and system capabilities for adding functionality within other components of the system, the number, type, and/or message throughput of endpoints utilizing inter-network communications, and aspects of these over the life of the vehicle. (e.g., due to campaign events such as service events, upgrades, and/or product recall events for the vehicle) and/or aspects of these over the life cycle of the associated fleet of vehicles; Expected changes in one or more of the following (e.g., related vehicle fleets, vehicle model years, and/or system-related model year groups; e.g., changes in device distribution, changes to networks, etc.) but similar including, but not limited to, multiple vehicles expected to have a network infrastructure of

In the example depicted in FIG. 1, first external device 110 is shown as being communicatively coupled to application 102. In the example depicted in FIG. The first external device 110 is directly coupled to the application 102, and this coupling includes a directional wired connection (e.g., to a service port, OBD port, or other available connection) and/or a wireless connection ( For example, 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 (first network 104 or second network 106) and/or another device that directly manages communications with the external device 110 (e.g., CND 108 and/or devices regulated thereby). Regardless of whether external device 110 is coupled to networks 104, 106 or another device, such as CND 108, in certain embodiments, CND 108 ensures that external device 110 receives only authorized communications. Ability to manage communications and further manage communications so that external device 110 can request communications from endpoints on either network 104, 106 and receive requested information notwithstanding such controls. has. In certain embodiments, the first external device 110 is a service tool, an original equipment manufacturer's (OEM) tool, a manufacturer's tool, a bodyworker's tool, and/or an application (e.g., laptop, desktop, etc.). The application may be an application that communicates through a mobile device and/or a computing device such as a mobile phone, e.g., an application operated by an owner, service personnel, fleet manager, or the like.

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

Endpoint, as used herein, should be understood broadly. An endpoint is an organizing concept for accessing a vehicle's network 104, 106, and includes specific devices (e.g., engine controller, transmission controller, door controller, infotainment system, etc.), devices with single network access. (e.g., multiple devices communicate with each other through a single network access point, in which case networks 104, 106 and/or CND 108 may have visibility into individual devices, or (can only have visibility into communications from endpoints as a group). For example, a door controller (not shown) may be the endpoint for one of the networks 104, 106 and may be associated with underlying devices (e.g., door position sensors, door lock actuators and position sensors, window actuators and position sensors, etc.). Communication proceeds through the door controller endpoints to the networks 104, 106, where the CND 108 provides visibility to underlying devices (e.g., indicating the door location including the identifier that the door location sensor is attempting to send the message). Messages) or may have visibility only to the door controller endpoints (e.g., it is known that messages indicating door position are provided by the door controller, but the CND 108 does not know which underlying devices (I don't know who may have sent the message). Those skilled in the art who have the benefit of the present disclosure and who have the information normally available for the system under consideration will readily determine which devices in the system are the endpoints for each network 104, 106. I can do it. Certain considerations for determining endpoint placement include the availability of hardware ports on the network, the distribution of vehicle controllers, the messages passed between vehicle controllers, and the ability of a given endpoint to be determined in the present disclosure. the desired granularity of data control; the desired granularity of data control; (e.g., permissions for certain devices to provide or request information, permissions for applications located either in the vehicle or outside the vehicle to provide or request information, security permissions 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 associated devices). , and/or redundancy of CND operation when CND components are distributed in more than one location on the vehicle).

Application as utilized herein should be understood in a broad sense. Exemplary applications include a group of related vehicle functions or operations, such as speed control (e.g. of the vehicle or a subcomponent thereof, e.g. engine or drivetrain), anti-lock braking system (ABS) actuation, advanced driver assistance. systems (ADAS), performance controls (eg, providing torque requests, speed requests, or other performance requests from the driver), or other vehicle functions. Exemplary applications include applications that support positioning and/or navigation, request and/or process service information about the vehicle, and/or interact with the driver (e.g., nearest hotels, selected events, etc.). (to find out) including a group of non-vehicle related functions such as third-party applications. The application may be performed by a vehicle manufacturer, supplier, contract manufacturer, body builder, third party, operator, service personnel, or the like. The applications used herein provide an organizational concept that can be utilized to associate certain data, certain endpoints, and/or related functions of a vehicle. In certain embodiments, CND 108 identifies data sources, data destinations, available permissions for applications, or priority information regarding applications, etc., and performs certain data coordination operations described herein. (regulating operations) can be used.

As used herein, flow should be understood in a broad sense. Exemplary flows include related data sets (e.g., speed data, temperature data, audiovisual data, navigation data, etc.), related functions (e.g., service activation and/or data collection, among other vehicle functions, additional functions such as aggregation and/or combinations thereof for a particular system), associated devices (eg, door actuators), and/or associated applications. Flows, as used herein, provide an organizational concept that can be utilized to associate certain data, certain endpoints, certain applications, and/or related functions of a vehicle or otherwise. In certain embodiments, CND 108 identifies data sources, data destinations, available permissions for flows, or priority information regarding flows, etc., and performs certain data coordination operations described herein. You can use flows to do this. In certain embodiments, the utilization of flows allows 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, CND 108 gives high priority to vehicle speed messages when the vehicle speed is being communicated to support a vehicle speed management application. However, if the vehicle speed is being communicated in support of a trip planning flow (e.g., a trip planning flow exists but does not have a high priority), the CND 108 sends the vehicle speed message a lower priority can be granted. In yet another example, a failure of a portion of the vehicle controller, network, or other abnormal condition may result in the migration of the vehicle speed management application to another controller in the system such that vehicle speed messages are Communicated to support speed management applications (eg, if the backup controller is on another network), CND 108 can give higher priority to vehicle speed messages. The use of flows and applications to organize the components of the system allows the same or similar information to be coordinated in a differential manner by the CND 108 to support various functions and network coordination operations. provides performance and security improvements (e.g., reduces unnecessary inter-network traffic and provides only the necessary information), and provides redundancy support, distributed control, and texture compared to previously known systems. Supports additional features such as fine-grained inter-network message communication.

The services utilized herein should be understood in a broad sense. Exemplary services include related applications for vehicles. Related applications (e.g., one or more vehicle systems, functions, or other applications of the vehicle) may all be located on the vehicle, and/or external devices (e.g., processing, data collection, etc.) may be located on the vehicle. or storage, use of externally sourced data by services, etc.), which may be a web application, a web tool, a cloud application, a service application, or the like. In certain embodiments, any local communication devices may be logically associated as a service. The use of services to organize system components and/or applications allows the same or similar information to be tailored in a differential manner by CND 108 to support various functions. Provides performance and security improvements to network coordination operations (e.g., reducing unnecessary inter-network traffic, providing only necessary information, and/or coordinating communications with external devices) and previously known systems support additional features such as redundancy support, distributed control, and fine-grained inter-network message communication.

As utilized herein and without limitation to any other aspect of the present disclosure, coordinated components include data collection, subscriptions, data requests, access to external devices and/or addresses, network Includes any system component that is coordinated with respect to communications, including access to zones, access to endpoints, utilization of communications resources (e.g., network zone bandwidth, external communications portals, aggregate data limits or amounts, etc.). The coordinated components are endpoints, flows, applications, controllers, services, interface circuits, network zones, external communication portals, external devices, source addresses, destination addresses, vehicle functions associated with any of these. including, but not limited to, one or more of an entity, a user associated with any of these, and/or a user role associated with any of these.

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

Referring to FIG. 3, an exemplary embodiment is shown that includes a vehicle 202 illustrating certain additional details that may be present in certain embodiments. The example 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 (eg, interactive dashboard 302, door actuators 310, and 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 CND 108. In this example, the third network 318 is of the same type as one of the other networks that is separated from the other networks to improve installation costs, risk management, or other considerations, for example. and/or may be of different types to support devices, for example sensors operating on a LIN network. Third network 318 may communicate with CEG 314 of CND 108, Ethernet switch 312, or another device (not shown).

The example depicted in FIG. 3 includes a first device 308 on the first network 104 (e.g., a controller for a prime mover in the example depicted in FIG. 3) and some devices on a second network (e.g., 3 includes an interactive dashboard 302, a fuel tank sensor 306, and a door actuator 310). The system includes one of the devices 302, 310, 320 on the second network communicating through the CND 108 to the first device 308. For example, the door actuator 310 locks the door when the vehicle 202 moves and receives vehicle movement information (e.g., engine speed, gear position, vehicle speed, and/or a Boolean value that says "vehicle is moving") from the first device 308. , or state parameters such as a bitmask, etc.).

The arrangement depicted in FIG. 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, e.g., the controller of prime mover 308 may provide each with an identifier. may provide a number of parameters to the first network 104 (e.g., engine temperature from an engine temperature sensor), each of which may be actuated as a separate endpoint, and/or provided as such by the controller of the prime mover 308. (e.g., engine temperature from the engine controller).

To illustrate the example described in FIG. 3, the first network 104 may be a CAN bus network, in which case the desired data (e.g., vehicle movement indicators) are transmitted through CAN messages according to CAN network considerations. provided as. Door actuator 310 is provided on a second network, for example an Ethernet network, in which case door actuator 310 is on a port of the second network. The port to the door actuator 310 can be a physical port (e.g., an Ethernet switch 312 dedicated to the door actuator 310) or a virtual port (e.g., a second physical port that can reside on a shared physical port with one or more other devices). location of the address relative to the network). 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 a vehicle movement indicator from the door actuator 310 and sends this message to the first network 104 and sends it to the door actuator 310 over a second network.

The operations performed to send a message may vary depending on the application. For example, CND 108 may expose to devices on a second network that certain parameters are available from first network 104 (and/or third network 318) and provide selected parameters directly to the device. (e.g., provide a vehicle movement indicator to the requesting device) or make the subscription parameter available to the subscriber device (e.g., make the subscription parameter available using a broker, not shown). ) can expose data values representing these parameters. In certain embodiments, CND 108 may limit publication of available parameters to devices, endpoints, applications, and/or flows that are authorized to view these available parameters. In other words, different devices on the second network may see different available parameter lists depending on the authorization of these devices and/or the applications or flows for these devices. In certain embodiments, the CND 108 provides these parameters to devices, endpoints, applications, and/or flows that are authorized to receive the parameters, such as by denying periodic reception requests for the parameters; /Or it can be restricted by suppressing the transmission of parameters to unauthorized devices despite regular reception. Accordingly, in certain embodiments, if a device is able to confirm that a parameter is available (e.g., in a public list of available parameters), but is unable to receive a data value for the parameter. There is. In certain embodiments, a device may be limited to viewing only available parameters that it is authorized to receive.

In certain embodiments, the device may have only limited availability to receive parameters; for example, the CND 108 may limiting the accuracy, resolution, and/or data rate of sensitive parameters) and/or proprietary considerations (e.g., if the application reverse-engineers or otherwise (e.g., limiting the accuracy, resolution, and/or data rate of parameters that may be associated with proprietary control operations) Value speed can be limited.

In certain embodiments, CND 108 determines which parameters to publish and provide based on stored data that defines the permissions and/or capabilities of devices, endpoints, applications, flows, etc., and the conditions for providing them. Determine. In certain embodiments, CND 108 also stores 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. access. In certain embodiments, the CND 108 provides authorization for applications and/or flows that are on-vehicle, off-vehicle (e.g., operating on an external device such as 110, 114, 204), or a combination of on-vehicle and off-vehicle. Determine. In certain embodiments, CND 108 prioritizes data flows based on associated devices, endpoints, applications, flow prioritization, including the rate at which devices provide or receive information, or other parameters. can be supported. In certain embodiments, the CND 108 provides differential prioritization based on vehicle status or operating conditions, such as using a first priority scheme during a start-up operation and a second priority scheme during a run-time operation. can be supported, such as by using a third priority scheme when the vehicle is moving. In certain embodiments, the CND 108 is configured to respond to any specified conditions, such as charging operation, regenerative operation, aftertreatment operation, control planning (e.g., cruise versus driver control), emergency events, failure conditions, or service conditions. can respond to vehicle conditions.

The example CND 108 illustrated in FIG. 3 includes a first device 314 that communicates with the first network 104. Exemplary first device 314 includes a configurable edge gateway (CEG) that reads communications from first network 104 and provides them to second network 106 . In certain embodiments, the first device 314 converts the communication toward the second network, e.g., converts the communication, a portion of the communication frame, and/or the payload of the communication into a message for the second network. encapsulated in. In certain embodiments, the first device 314 requests communication from a device on the first network 104 and, for example, sends parameters that are available but not currently communicated over the first network 104. Has the required functionality. In certain embodiments, the first device 314 is not part of the CND 108, but responds to commands from the CND 108, for example, by accessing stored data written in whole or in part by the CND 108; It is controlled by CND 108 with other operations provided throughout the present disclosure.

The example CND 18 illustrated in FIG. 3 includes a second device 312 that communicates with a second network. Exemplary second device 312 may be configurable and includes an Ethernet switch that reads communications from the second network. In certain embodiments, second device 312 receives messages from first network 104 through first device 314, eg, in a format communicable over the second network. The exemplary first device 314 includes a CEG that communicates through a port on the Ethernet switch provided for messages from the first device 314 to the Ethernet switch. Accordingly, FIG. 3 provides an embodiment of a second device 310 on a second network communicating with a first device 308 via a CND 108.

The example system includes external devices 110, 114, 204 that communicate with CND 108. In the example depicted in FIG. 3, external devices 110, 114, 204 communicate through transceiver 304 and/or by direct access to the network of vehicle 202 (e.g., using a service port, OBD port, WiFi, Bluetooth, etc.). can do. External devices can configure CND 108 by modifying stored data that defines, for example, available data to be exposed, associated permissions, defined applications, defined flows, defined destinations, and defined devices. Structured to adjust. In certain embodiments, the external device has an associated permission value, and the CND 108 provides changes according to the associated permission value, e.g., for a certain network, device, endpoint, application, or Prevent adjustments to changes in flow, etc.

The exemplary system includes a first network as a bus network, and the bus network may be a CAN bus network. The example system includes the second network as an Ethernet network that can have any alternative topology, such as a data bus architecture. In certain embodiments, an Ethernet network has a data bus architecture as its hardware topology, but can be operated in a logically different manner (eg, as a switched network).

Referring to FIG. 4, the example 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 coupled to one or more endpoints 408, e.g., CAN networks 406, to provide communications to and/or receive communications from the respective CAN networks 406. A CEG that accesses one or more CAN-based networks 406, each having devices that perform The example depicted in FIG. 4 illustrates two CAN networks 406 that can be arranged for integration convenience (e.g., vehicle components by function, by location within the vehicle, and/or on a common CAN network 406). (for division by any other arrangement, such as a group of related components that communicate). In this example, the first network gateway device 404 communicates with both CAN networks 406, but the CND 108 may, for example, have one CEG accessing each CAN network 406 and/or each CEG accessing the CAN network on the vehicle. More than one CEG may be included and/or the CEGs may be configured to coordinate accessing a subset of network 406. Although the example depicted in FIG. 4 shows a bus network 406, and the network 406 is described as a CAN network for illustrative purposes, the network 406 can be any type described throughout this disclosure. Endpoint 408 is any type of endpoint that has the ability to communicate with network 406 , such as a controller, smart sensor, or smart actuator, or that has the ability to provide communications to and/or receive communications from network 406 . It can be any other device that has.

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 network gateway device 402, 404, such as regulating data stored therein, regulating stored data accessible to devices 402, 404, providing instructions to those devices, and/or the present disclosure. It may be configured by performing any of the other operations listed throughout.

In the example depicted in FIG. 4, the second network gateway device 402 is an Ethernet switch, and the Ethernet switch 404 accesses an Ethernet-based network 410, shown as a number of endpoints 412 communicating with a number of ports 414 thereof. . Ports 414 are shown schematically and can be logical ports, hardware ports, or a combination thereof. The physical topology of Ethernet network 410 may be a bus arrangement, a hub arrangement, a star arrangement, or any other type of network topology, and may be different from the logical topology of Ethernet network 410. A second network gateway device 402 is shown as having a network interface 416, which may include a physical port connection. In certain embodiments, the second network gateway device 402 includes a processor, computer readable storage (e.g., for storing instructions, configuration information, buffering for data communication and/or collection operations, and the like). is a configurable Ethernet switch that can include Although these aspects are not shown for clarity of depiction and this description, it is assumed that these aspects reside on the second network gateway device 402 and are in the same housing as the second network gateway device 402 . The presence of a separate board from the network interface 416 located on another device in the system and communicating with the second network gateway device 402 and/or separate from the remainder of the second network gateway device 402 ( (e.g., mounted on separate printed circuit boards) (e.g., on the first network gateway device 404, on the vehicle controller, and/or on another controller in the system); and/or It can be distributed across a combination of these locations.

In the example depicted in FIG. 4, the first network gateway device 404 has one or more network interfaces 418 (and/or network interface circuitry) communicatively coupling it to the network 406 and communicatively connecting it to the network 406. and/or a conversion circuit 420 that includes messages from the Ethernet network 410 for communication to the Ethernet network 410 and/or includes messages from the network 406 for communication to the Ethernet network 410 . Additionally or alternatively, for example, these networks 406 may be of different types, utilize different protocols, or otherwise have conflicting source or destination information, and/or or managed by the first network gateway device 404 to ensure message compatibility, successful mission operation of the vehicle, and/or to perform any other configuration operations set forth in the present disclosure. Translation circuit 420 includes messages for passing from one of networks 406 to another of networks 406 if the other is considered to have distinctly different characteristics. Although conversion circuits 420 are shown as a single device, conversion circuits 420 may each be configured in one type of configuration, e.g., to distribute its processing operations and/or memory operations, or for any other reason depending on the particular system. may be implemented as one or more devices having several components of translation circuitry 420 that implement and interact with some type of network 406. In the example depicted in FIG. 4, the first network gateway device 404 provides a message to the Ethernet switch in response to a corresponding message on the CAN-based network 406. In the example depicted in FIG. 4, first network gateway device 404 provides messages to port 414 of an Ethernet switch. In the example depicted in FIG. 4, any message provided from network 406 appears on Ethernet network 410 as a message on a port between conversion circuit 420 and network interface 416, and any message from Ethernet network 410 , is received through a port between conversion circuit 420 and network interface 416. Translation circuitry 420 provides configuration operations between messages so that endpoints such as those described above on each network 406, 410 can communicate between each other, coordinated by CND 108.

The example depicted in FIG. 4 further includes an on-board diagnostic (OBD) interface 422, which in this example communicates with a dedicated OBD port 424. The example depicted in FIG. 4 is illustrative and non-limiting, and the OBD interface 422 can connect to any network or connect to more than one network (e.g., connect to a vehicle). ) to support multiple OBD tools. The exemplary embodiment includes an OBD interface 422 connected to a second network gateway device 402, e.g., in this case the OBD system is substantially CAN-based and many of the OBD parameters are connected to the CAN network. 406 allows for less traffic between translation circuit 420 and network interface 416. OBD interface 422 may alternatively reside on Ethernet network 410 or on more than one network 406, 410 of the system. Regardless of the location of the OBD interface 422 and the origin of OBD-related data on the networks 406, 410, OBD requests and information may authorize and provide inter-network communications from any endpoint of the networks 406, 410. Activation of CND 108 may enable OBD port 424 (which may be a physical connection, a wireless connection, or another external connection, including a mobile data connection). Additionally, the example described in FIG. 4 utilizes an OBD interface 422 as a non-limiting example, but allows any data from any endpoint on the network 406, 410 to be made available and configurable adjustment by the CND 108. Any type of special dedicated and/or proprietary interfaces having interfaces and ports capable of receiving data may be provided in a similar manner.

The exemplary system includes a CND 108 inserted 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 may be an electrical connection to a second network gateway device 402 having an associated endpoint 408 as an electrical sensor, in which case the conversion circuit 420 connects the electrical The signals are converted into communications for a respective network (eg, network 410 or another network 406). In this example, conversion circuitry 420 includes analog-to-digital (A/D) processing, determination of display bits, determination of display values, signal debouncing, signal filtering, diagnostic bit detection (e.g., fault determination and corresponding conversion to a 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., display Processing operations can be performed on the electrical signals, such as applying rate-of-change limits to the values. 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.

In another example, the system includes a CND 108 inserted between an electrical actuator and one of the networks 406, 410 and structured to provide a command value from the network as a configured electrical response to the electrical actuator. . For example, one of the networks 406 may be an electrical connection to a second network gateway device 402 having an associated endpoint 408 as an electrical actuator, in which case the conversion circuit 420 is connected to the respective network ( For example, communications from network 410 or another network 406) are converted into electrical signals for actuators. In this example, conversion circuit 420 may perform processing operations on the electrical signal, such as digital-to-analog processing, determining from display bits to corresponding values, providing diagnostic bits, saturation management, slew limiting, and the like. I can do it. The electrical signal to the actuator, if present, may 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 actuators may be provided on the same or distinct electrical connections and/or the sensing values (e.g., position feedback, acknowledgments, etc.) and are logically connected to the same network 406 or There may also be other feedback values (e.g., indicating an actuator) that may be part of distinctly different networks (e.g., actuation on one network 406 and feedback on a second network 406). Certain electrical values have fault conditions, are non-responsive, are stationary, saturated, etc.).

The embodiments described in FIG. It can be seen that communication between Without being limited to any other aspect of the present disclosure, the embodiment described in FIG. Give the function for. Furthermore, the embodiment described in FIG. 4 provides for operation of the vehicle as the device moves between networks without being limited to whether or not the device has changed communication capabilities. For example, a first device on a CAN network that is moved to an Ethernet network may, through appropriate configuration of CND 108, move the messages that this device was using from the CAN network to the Ethernet network and send them to the device at its new location. It is possible to continue functioning by being available to the public. In certain embodiments, the migrated device retains the previous CAN messages, including the previous algorithms (e.g., same local control), e.g., bit depth, resolution information, message rate, floating point/fixed point data nature, etc. computer-readable instructions specifically configured to the specifications of the original CAN message so that the device that has migrated it can receive the previous CAN message that was originally presented and utilized by this same local control. It may continue to be utilized with a CND 108 configured to encapsulate (eg, in a frame, in a packet, and/or in a specified manner) within an Ethernet message. Accordingly, the embodiments described in FIG. 4 and the principles illustrated with respect to FIG. Updates to the configuration of the CND 108 to support these changes, whether they occur (changes that occur) or within the same vehicle (e.g., service repairs, endpoint upgrades or modifications, upgrades, upfits, recall replacements, etc.) made possible only by In certain embodiments, the embodiments described in FIG. 4 and the principles illustrated with respect to FIG. and the CND 108 is configured to determine the endpoint configuration present on the vehicle and thus utilize the selected configuration (e.g., from among two or more available configurations). Enables mixed state changes of endpoint devices between networks without requiring configuration updates. Accordingly, the embodiment described in FIG. 4 and the principles illustrated with respect to FIG. It further enables inter-network changes to a mixed state of endpoint devices, at least within a predetermined range of endpoint devices and configurations, without communication.

Referring to FIG. 5, an exemplary system may be physically and logically separated on a vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme). and/or a CND 108 that coordinates communications between multiple networks, one or more of which may be of different types. The embodiment illustrated in FIG. 5 is generally consistent with the embodiment illustrated in FIG. 4, with some differences noted to highlight certain aspects of the present disclosure. The example depicted in FIG. 5 includes additional interfaces 504, 506, which may be separate networks or network zones with respect to network 406. The example depicted in FIG. 5 includes any type of vehicle controller (e.g., engine controller, transmission controller, anti-lock braking system (ABS) controller, advanced driver assistance system (ADAS) ) and/or electrical interfaces to sensors, actuators, or combinations of sensors and actuators. ) 508 is drawn. The example depicted in FIG. 5 depicts an additional interface 506 to the endpoint 502, which can be any type of communication device as understood in the art or illustrated herein. In the embodiment illustrated in FIG. 5, a network interface circuit 418, 508 connects the endpoint 408, 502 to the converter circuit 420 to allow the converter circuit 420 to interface with the many network types that may be present on the vehicle. Between circuits 420 and 420 are shown. The interface circuits 418, 508 may be co-located with the translation circuit 420 or located elsewhere and communicatively coupled to an associated network and the translation circuit 420. The example depicted in FIG. 5 further depicts networks 512, 514 communicatively coupled to first network gateway device 404 through endpoint 412 on the same network as network interface 416. In certain embodiments, CND 108 does not have or require specific knowledge of networks 512, 514 or associated endpoints 516, 518 because communication to networks 512, 514 is provided through endpoints 412. However, CND 108 is structured to provide communications from a network in communication with second network gateway device 402, such as network 406 and/or networks interfaced at endpoints 504, 506. Communications from the second network gateway device 402 may include requested information (e.g., ambient temperature, door position, vehicle speed) as an encapsulated payload providing these information, or as a unique message (e.g., ambient temperature, door position, vehicle speed). (CAN messages indicating position, vehicle speed, and/or LIN messages with associated sensor information). Thus, endpoints 516, 518 may send and receive tunneling messages in a shared format with network 406 (or other networks) or receive information from any network onboard the vehicle and subject to coordination by CND 108.

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

Without being limited to any other aspect of the present disclosure, the collocation shown in FIG. device 404 and/or located on the same board as the first network gateway device 404), and/or logical co-location (e.g., grouping of operational burdens of execution hardware, e.g. connections, connectivity, operating instructions, stored data, data storage, and/or processing resources, etc.). Determining the colocation scheme depends on the objectives of the colocation (e.g., sharing hardware resources, reducing the number of external interfaces, the risks of colocating components and/or other components in the system for these components). the nature of the colocation components (e.g., the hardware implementation, processing resources, and/or memory resources for the colocation components); the division of ownership of the colocation components (e.g., simplifying and/or diversifying the profile); (manufacturer, supplier, service provider, vehicle owner, vehicle operator), components and/or vehicle operating charges (e.g., ensuring, operating obligations, service, insurance, operational charges, etc.); or depend on component integration burdens (eg, installation, design, meeting footprint requirements, compromises between and/or the ability to influence these). Accordingly, in certain embodiments, collocating the components includes arranging the components in a housing or group of housings, arranging the components in a selected geometric neighborhood, selecting the components. (e.g., associating within the same flow or group of flows, associating within the same application or group of applications, establishing operational constraints such as parameter naming, memory allocation, or execution order) placing components in a selected risk profile arrangement (e.g., placing components in a selected risk profile arrangement (e.g., placing components with the same failure mode (e.g., electrical effects, logical effects, failure effects, physical effects, and/or pumps, cooling systems, etc.); the same impact zone, the same temperature environment, the same NVH environment, the same EMI environment), on the same board, and/or on a shared memory location. (eg, the computer readable instructions are located in a shared memory location and/or executed by the same processor resource). In this example, NVH is the "noise, vibration, and harshness" environment and EMI is the "electromagnetic interference" environment. A person skilled in the art who has the benefit of this disclosure and the information normally available when considering a particular system can readily determine the implementation of collocated components as set forth in this disclosure. . Components arranged in one or more of the described collocation schemes may be collocated in certain embodiments or not in other embodiments, and/or for purposes of certain operating conditions. It can be seen that it colocates, but may not colocate for purposes of other operating conditions. Certain considerations for determining whether components are colocated, and the colocation scheme chosen for these components, include the purpose of the colocation, the operational costs of the resources (e.g., communications, processing resources, operational constraints on the vehicle's mission, operational effects on the vehicle's mission, such as cooling requirements, and power consumption), capital costs of resources (such as computer power, network infrastructure, memory resources, quality requirements of individual components). or functional requirements, shielding requirements, data throughput whether on-vehicle or off-vehicle), integration costs for components (e.g. footprint availability and cost, interface management, design flexibility and locking); down trajectory and/or the ability to compromise and/or optimize with other aspects of the system) and/or the ability to spread costs to other stakeholders regarding the system (e.g., these stakeholders may manufacturers, customers, and/or service providers, including the ability to spread high costs for high functionality and/or transfer costs between stakeholders) but not limited to).

In the example illustrated in FIG. Communication may be provided by communicating with (not shown).

Referring to FIG. 7, an exemplary system may be physically and logically separated (e.g., as a virtual local area network (VLAN) or other logical separation scheme) on a vehicle. and/or a CND 108 that coordinates communications between multiple networks, one or more of which may be of different types. The embodiment illustrated in FIG. 7 is generally consistent with the embodiment illustrated in FIG. 4, with some differences noted to highlight certain aspects of the present disclosure. Without being limited to any flexibility of the arrangement shown in FIG. 4, the example shown in FIG. 404 and a collocated second portion 704. Each portion 702, 704 of translation circuitry 420 may be configured to perform processing by a network (e.g., which network 406 is being served), by a predetermined endpoint, by a flow, or by a translation operation (processing frame information, processing payload information, etc.). managing functional differences by providing processing, communication instructions, downsampling, upsampling, buffering, encapsulation of messages within another message format, etc.), and/or by direction of communication (e.g., The conversion operations may be separated for any reason, including at least separating the conversion operations (directions between networks that are connected, between gateway devices, between endpoints, between flows, or a combination of these directions).

Referring to FIG. 8, an exemplary system may be physically and logically separated on a vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme). and/or a CND 108 that coordinates communications between multiple networks, one or more of which may be of different types. The embodiment illustrated in FIG. 8 is generally consistent with the embodiment illustrated in FIG. 4, with some differences noted to highlight certain aspects of the present disclosure. In the example illustrated in FIG. 8, the first network gateway device and the second network gateway device are colocated and have been omitted as shown as part of CND 108. In certain embodiments, the CND 108 described in FIG. 8 may instead form a part of, but instead be a composite gateway device coordinated by the CND 108. In certain embodiments, one or more portions of a composite gateway device may form part of CND 108, and other portions of the composite gateway device are coordinated by CND 108.

Policies, as utilized herein and without limitation to any other aspect of the present disclosure, may provide information on data parameters, collection rates, resolution information, priority values (e.g., all data collection parameters). including a description of the data collected, such as ordering the data collection values in response to abnormal conditions that may not be possible. In certain embodiments, the policy is based on parameter- or quantitative-based events (e.g., a given data value being greater than a threshold), and/or categorical events (e.g., specific fault codes, operating conditions, or states). , or vehicle location/jurisdiction in which the event occurs). In certain embodiments, the policy may include event responses, such as data values to be captured in response to the occurrence of an event, and/or other data collection schemes, such as increasing or decreasing data collection rate, changing collection resolution, etc. further including changes in In certain embodiments, the event response includes a time frame relative to the event occurrence, such as a period after the event occurs to utilize an adjusted data collection scheme, and/or a period preceding the event occurrence (e.g., a rolling buffer or further includes utilizing other data collection operations to provide temporary information that can later be captured if an event occurs. In certain embodiments, changing the data collection scheme for an event includes multiple changes, e.g., changes over a period of time, further changes based on the progression of the event (e.g., if the event severity worsens), and/or changes in the data collection scheme for the event. or may include further changes based on the criteria for determining that the event is resolved. In certain embodiments, changes to the data collection scheme may be made based on event-related resolution of the same or different events, such as when a service technician Data collection changes are implemented during a selected number of outage events, or a similar period of time, until the problem is resolved. Additionally or alternatively, the policy may include parameters for performing any adjustment actions on any of the adjusted components listed throughout this disclosure.

The use of policy herein can refer to secondary policies, e.g., implicit policies to be implemented in response to a single data collection scheme from a single user, and can refer to a complete policy. is prepared, verified, and communicated to the vehicle after one or more secondary policies are collected. The use of policies herein refers to unverified policies, e.g., after some user-responsive policies have been collected, but the policy verification operation has not yet been completed (e.g., (before a decision can be made as to whether data collection can be carried out). The use of policy herein refers to a previously applied policy (e.g., a policy that existed before an updated version of the policy was communicated to and/or implemented on the vehicle). Can be done. The use of policy herein may refer to an updated policy, eg, a verified policy (eg, from CND 108) awaiting communication to and/or confirmation by the vehicle.

Referring to FIG. 9, an exemplary system may be physically and logically separated on a vehicle (e.g., as a virtual local area network (VLAN) or other logical separation scheme). and/or a CND 108 that coordinates communications between multiple networks, one or more of which may be of different types. The embodiment illustrated in FIG. 9 is generally consistent with the embodiment illustrated in FIG. 4, with some differences noted to highlight certain aspects of the present disclosure. In the example depicted in FIG. 9, the first network gateway device 404 and the second network gateway device 402 are not colocated, and the CND 108 is shown in communication with the first network gateway device 404. CND 108 can be in communication with and/or can be at least partially disposed on any one or more of the network gateway devices. . Additionally or alternatively, CND 108 may access memory locations (e.g., policies, configuration instructions, or configuration tables, etc.) available to one or more of the network gateway devices; and/or may coordinate communications between networks by adjusting the applicable portion of the instructions (if any exist), in which case the CND 108 does not communicate directly with other network gateway devices. can be passed to these devices. In certain embodiments (not shown), CND 108 utilizes one or more of the networks, such as at port 414 of first network gateway device 404, to connect one or more of the network gateway devices to one or more of the network gateway devices. Can communicate. In certain embodiments, CND 108 is disposed at least partially on one or more of the network gateway devices, colocated with one or more of the network gateway devices, and/or The gateway device may be included (at least partially) within one or more components (eg, translation circuitry and/or network interface circuitry) of the gateway device.

Referring to FIG. 10, an exemplary first network gateway device 404 is shown. 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 an Ethernet network interface circuit) having a number of ports 414 for communication with an Ethernet network. be. Port 414 can be a physical port, a logical port, or a combination thereof.

Referring to FIG. 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). The use of secondary and primary to refer to networks merely indicates the logical arrangement of the networks, in which case interfaces to other networks other than the primary are referred to as edge interfaces (e.g., interfaces to edge gateways). connected). In certain embodiments, the primary network may have higher functionality (e.g., dedicated bandwidth, throughput, and/or resources), more devices or endpoints on the network, or a migration target network for the endpoints over time ( (over the lifespan of a vehicle, fleet, model year, etc.) and/or for external communications (e.g., over-the-air updates, configuration updates, data collection, etc.), but with specific Embodiments may have some, all, or none of these considerations that exist for networks that are considered primary networks. The example depicted in FIG. 11 depicts an optional OBD interface 422 that may exist elsewhere in the system or may not be present in the system.

Referring to FIG. 12, a vehicle is shown that has several networks on it and communication between these networks is coordinated by a CND 108. The arrangement depicted in FIG. 12 is presented to illustrate certain aspects of the present disclosure and is a non-limiting arrangement. The example depicted in FIG. 12 has endpoints 1202, 1204 (e.g., one or more vehicle controllers) coupled to a first network 406 and a switch colocated with a second network (e.g., CND 108). , and/or a number of endpoints 1206, 1208, 1210, 1212 coupled to an Ethernet network that is at least partially separate from CND 108). In the example depicted in FIG. 12, controllers 1202, 1204, 1206, 1208, 1210, 1212 can pass communications coordinated by CND 108 between disparate networks of vehicles. In certain embodiments, a given controller can be switched between networks, maintain communication with other controllers within the vehicle and/or external to the vehicle, and further communicate with associated controllers (or knowledge of the switch (external controller, application, or device) can be maintained regardless of whether it has knowledge of the switch.

Referring to FIG. 13, a vehicle is shown that has several networks on it and communication between these networks is coordinated by a CND 108. For illustration purposes, the example depicted in FIG. 13 includes the same network and controller set as the example depicted in FIG. 12. In the example depicted in FIG. 13, controllers 1204, 1208, 1210, and 1212 have been co-located 1302, and further, controller 1204 has been moved from the first network 406 to the second network. Co-location 1302 of controllers 1204, 1208, 1210, 1212 allows for fewer housings (1-3 total housings instead of 4), fewer boards (1-3 total housings instead of 4), and fewer boards (1-3 total housings instead of 4). any implementation that involves aggregation of controllers onto a total number of boards) and/or utilization of at least partially shared computer resources (e.g., shared processing, shared memory, shared cache, and/or a combination thereof). be able to. In certain embodiments, utilization of the CND 108 is accomplished solely by configuration updates to the CND 108 and/or solely by aggregate changes to the vehicle controller that fall within the available predetermined configurations of the CND 108 (thereby 13, including the aggregation of vehicle controllers, by allowing coordination of communications and maintenance of connectivity (which can be implemented without updates to the vehicle controller). Additionally, controller aggregation can reduce network costs, reduce network traffic, selective risk distribution (e.g., placing controller locations in lower risk or distributed risk locations and/or network routing), and/or lower risk to other system components, taking advantage of footprint gains and/or cost savings through controller aggregation. In certain embodiments, aggregation of controllers may enable deeper information sharing between controllers (e.g., greater available network capacity, avoidance of network limitations with shared controllers, and/or increased use of shared memory resources). due to utilization), thereby providing higher functionality controller operations and/or operations that were previously unavailable because shared information between controllers was not readily available. . In certain embodiments, the CND 108 further enables controller aggregation by separating controller locations from endpoint locations (not shown) that require them to be distributed (e.g., to perform their own functions). Due to the operation of CND 108 and/or CEG 402, there is no longer a need to locate sensors and actuators close to their respective controllers that need to be located in a certain location for the purpose of operation). In certain embodiments, aggregation of controllers can be used, for example, to reduce hardware costs for shared computer resources, to enable higher functionality (e.g., processing power and/or memory) computer resources, or to The combination allows for low cost and/or high functionality. Thus, operation of CND 108 provides centralized operation of the vehicle controller that was not previously available. In certain embodiments, the example described in FIG. 13 may be an illustration of an aggregation and/or unrelated embodiment of the controller with respect to FIG. 12.

Referring to FIG. 14, a vehicle is shown that has several networks on it and communication between these networks is coordinated by a CND 108. For illustrative purposes, the example depicted in FIG. 14 includes the same network and similar set of controllers as the example depicted in FIG. 12. In the example depicted in FIG. 14, the colocation 1302 controller includes a set of controllers 1402, 1404, 1406 and a CND 108 shown as a controller on the colocation 1302 controller. CND 108 may be disposed at least partially on one or more of colocation controllers 1402, 1404, 1406, and/or may be separate as illustrated. In certain embodiments, the example described in FIG. 14 may be an illustration of a further aggregation of controllers with respect to FIG. 13 and/or a co-location 1302 controller unrelated to the examples described in FIGS. 12 and 13. Can be done.

Referring to FIG. 15, a vehicle is shown that has several networks on it and communication between these networks is coordinated by CNDs 1502, 1504. For illustrative purposes, the example described in FIG. 15 utilizes two aggregated controllers 1302, 1506, each including the colocated vehicle controllers listed throughout this disclosure. The example described in FIG. a second CND 1504 (or CND portion) inserted between the first network 406 and the second network (the endpoint 412 is directly coupled to the CND 1504 and the aggregation controller 1302 directly coupled to CND1502). 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 the same type of network ( (e.g., an Ethernet network) and/or may utilize hardware that is the same or electrically coupled to each other. Although the example described in FIG. 15 shows a CND 1504 with primary network coordination for a first network 406, the coordination of the first network 406 is based on distributing, sharing, endpoints, or applications and/or flows. You can make adjustments, etc. In certain embodiments, coordination of the second network may be performed by only one of the CNDs 1502, 1504 and/or may be coordinated accordingly to distributed, shared, endpoints, applications, and/or flows.

Several representative aspects of FIG. 15 are described below, any one or more of which may be present in certain embodiments. The example aspects described in FIG. 15 include network coordination shared by the CNDs 1502, 1504, e.g., when the endpoint, the network, the other (or part) CND, and/or the controller malfunction, fail, or become inoperable. Both CNDs 1502, 1504 have the ability to fully or partially support coordination of all networks when received. The example aspects described in FIG. 15 include primary regulation of the network by one CND 1502, 1504, such as when an endpoint, network, primary CND, and/or controller experiences a failure, failure, or reduced operational capability. In this case, the other CND has the capability to fully or partially support the coordination of all networks. The example aspects described in FIG. 15 at least partially take over control operations for the other of the aggregate controllers 1506, 1302 in the event that the other aggregate controller loses functionality, connectivity, etc. with an endpoint. 1302, 1506, or both. In certain embodiments, the CNDs 1502, 1504 have the ability to responsively pass parameters that were previously available only to the original controller 1302, 1506 on behalf of control operations by the replacement controller 1506, 1302. . In certain embodiments, the availability of redundant network routing is provided by the CNDs 1502, 1504 to provide at least partial connectivity between endpoints that have lost connectivity when a portion of the network fails. Available for use. The CNDs 1502, 1504 can include equivalent parameters (e.g., another endpoint with the ability to provide equivalent data), alternative parameters (e.g., the ability to provide alternative or backup parameters that can be used at least in part as a replacement for a lost parameter). another endpoint with an endpoint), may provide the same parameters (e.g., if the data from the original endpoint or the same data value from another endpoint can be routed through the remaining network infrastructure), and /or management parameters such as controller handoff communications, heartbeat communications, status communications, etc. may be provided. In certain embodiments, one or both of the CNDs 1502, 1504, or portions of the CNDs, may be colocated with another system component, such as one of the aggregate controllers 1302, 1506. Certain embodiments pose distinct risk profiles for multiple networks on a vehicle, making the vehicle less susceptible to such missions and/or at least with respect to limp home activation, controlled shutdown, data capture, etc. Network routing is provided for these networks on the vehicle in a manner that reduces the risk of single failures rendering them inoperable. In certain embodiments, the location of the controller, CND, and/or aggregate controller presents distinctly different risk profiles for multiple associated devices, with respect to such missions and/or at least limp home actuation, controlled It may be selected to reduce the risk of a single failure rendering the vehicle inoperable with respect to stopping, data acquisition, etc. In certain embodiments, network routing that results in lower operational costs, installation costs, integration costs, overall risk profile, or distribution of weight and/or footprint of components on the vehicle may be is applied to the network.

Referring to FIG. 16, an embodiment of some embodiments of message transformation and/or message encapsulation is shown. The example depicted in FIG. 16 is illustrative, depicting certain aspects of the present disclosure, and is not intended to limit 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 conversion circuit, and/or a CND, and in certain embodiments, may be coordinated by a CND. Can be done. The first example message transformation 1602 includes a message from the first network having a payload 1610 and other frame information 1608. Other frame information may include headers, trailing aspects, and/or termination bits, further determined by the associated protocol, network type, source endpoint, destination endpoint, or other aspects known in the art. be able to. In certain embodiments, payload 1610 can be message data, data values represented by the message, or other information that is intended to be the content of the message. However, in certain embodiments, payload 1610 may be any other aspect of the message, during certain operating conditions for certain operations, and/or for certain endpoints. For example, a network monitor operation may utilize timestamps, acknowledgment information, source and/or destination information, or other portions as the payload of the message. The example message transformation 1602 includes separating the payload 1610 and packaging the payload into a new frame (or packet) 1612 in information configured to fit the target network. Additionally or alternatively, the new frame 1612 may include an identifier (e.g., source or destination) adjustment, timestamp, or other information that allows endpoints on the disparate network to be extracted from knowledge of each other. can include. In certain embodiments, the payload 1610 may, for example, change the utilization unit, change the bit depth (e.g., 2 bytes vs. 4 bytes), change the representation precision, or convert between floating point or fixed point. It can be processed to change.

A second example message transformation 1604 includes the original messages 1608, 1610, eg, completely encapsulated within a new frame 1612 to provide the original message provided by the original source to the target endpoint. (e.g., it provides for previously developed algorithms to operate as-is without the need to transform them into new messages, provides certain network monitor operations that utilize the complete original message, and provides similar ). In certain embodiments, either the original payload 1610 or the message frame 1608 may be processed, e.g., the source identifiers may be converted into a new arrangement to process the payloads described above and extract the endpoints from each other. or update timestamps, etc., but otherwise provide equivalent or systematically adjusted information.

A third example message transformation 1606 includes original messages 1608, 1610 with adjusted payloads 1614. Adjustments to the payload 1614 may include transforming the payload in any manner (e.g., value correction, virtual sensing or modeling of the value based on the original payload 1610, or upsampling or downsampling the payload 1610, etc.). , may additionally or alternatively include processing of the payload. Although the third example message transformation 1606 describes an adjusted payload 1614, adjustments may additionally or alternatively be performed on other portions of the message frame 1608. The third example message adds a new frame 1612 for communication to another network.

Referring to FIG. 17, a schematic diagram of the operation of downsampling a message sequence 1702 is shown. In the example depicted in FIG. 17, a message sequence 1702 (eg, 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 set forth in FIG. 17, the downsampling operation systematically updates the data represented by message 1702 to match the data rate of the receiving endpoint, e.g., in response to any downsampling operation described herein. for the purpose of maintaining buffer memory, providing speed, managing bandwidth on the vehicle's network and/or for off-vehicle communications, or any other method including downsampling operations of any of the present disclosures. Concerning purpose. In the example depicted in FIG. 17, the downsampling device 1704, which can be a conversion circuit, a network interface circuit, a CND, a circuit connected to a CND, a circuit conditioned by a CND, etc., converts the converted message sequence 1708 ( (e.g., processed as illustrated in FIG. 16 and related disclosure and/or processed in accordance with any other message transformation and/or message processing operations set forth herein). The example depicted in FIG. 17 depicts a transformed message sequence 1708 for purposes of clarity. However, the translated message sequences 1708 may not all exist at the same time; for example, the messages may be removed from the cache, deleted, expired, etc. as they are translated and sent. Message sequence 1708 is shown to illustrate aspects of the present disclosure. Additionally or alternatively, the transformation of message 1708 may be performed after the downsampling operation is performed, eg, to reduce processing resource utilization. For example, rejecting a portion of a message as part of downsampling before conversion operations (e.g., frame portion or metadata exchange, encapsulation, payload and/or frame portion processing, etc.) are performed. I can do it. In the example depicted in FIG. 17, the downsampled message sequence 1706 may, for example, be a different network gateway device, a different vehicle network that is the source of the first message sequence 1702, an external device (e.g., a service tool, a cloud server, a driving and/or stored on a memory storage device on the vehicle (e.g., as part of stored vehicle data for later data collection operations). In this example, the five messages of original sequence 1702 are downsampled to three messages of downsampled sequence 1706. The downsampling operation involves converting selected messages from the original sequence 1702, e.g., changing the original 10ms data stream 1702 to a downsampled 20ms data stream 1706 by utilizing every other data message. It can include stages. The downsampling operation may additionally or alternatively include interpolation of the data message 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 be done by taking the closest message in time or by performing an interpolation operation. (e.g., applying a linear fit, spline fit, polynomial fit, or other interpolation operation to the interpolated data points) as the downsampled message 1706.

As used herein, interpolated data points or interpolated data values refer to data values within downsampled message 1706 that are not temporally aligned with the corresponding original data message 1702. As used herein, non-interpolated data points or non-interpolated data values refer to data values that are time-aligned or synchronized within the downsampled message 1706 with the corresponding original data message 1702. . The original data message 1702 message and the downsampled message 1706 message may additionally or alternatively have a phase difference, such that in certain embodiments the original data message It will be appreciated that any or all of 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, the trajectory characteristics of the stream of the original data message 1702 (e.g., time-domain If any phase difference can be ignored for the purpose of a device or operation that utilizes the downsampled message 1706 to provide a baseline downsampled message 1706 that follows (e.g. If such device or actuation has a response time or required reaction time that is significantly greater than the magnitude of any such phase difference), certain messages of the original data messages 1702 may be replaced with non-interpolated data messages. Or it can be processed as a synchronous data message.

In yet another example, synchronous data values (e.g., every fifth data value when converting from 40 ms to 100 ms) can be used directly, or a fitness function can be used (e.g., a smooth (to provide a data value stream that has been filtered, filtered, or otherwise processed). In certain embodiments, minor transient behavior from various time steps is not related to how the downsampled data values 1706 are utilized, or timestamp data is further communicated with the message; Therefore, a process that utilizes downsampled data 1706 can either downsample the actual data values provided by first data stream 1702 and satisfy the differential time steps between messages. It may be desirable to utilize it as a sampled data value 1706. In certain embodiments, it may be desirable to utilize smoothed data values that simulate the time response behavior of the underlying data, and these data values may be smoothed using interpolated data with respect to interpolated data values. (e.g., processing responsive to the rate of change of the downsampled data 1706, e.g., threshold testing for the rate of change). In certain embodiments, all downsampled data messages 1706 are generated from the same process, for example, if the downstream process is particularly sensitive to time variations in data messages 1702 (e.g., the differential portion of a PID controller). , it may be desirable to ensure that interpolation operations (or smoothing, filtering, or moving averages) can be performed to generate both interpolated and non-interpolated data values 1706. In certain embodiments, the downsampled data message 1706 further includes metadata or other embedded information indicating whether it corresponds directly to the original data message 1702 or is a processed message. (e.g., to enable more than one use on the downsampled data message 1706, diagnostic operations on the device providing the original data message 1702, and/or any other purpose).

It can be seen that the downsampling operations described in FIG. 17 enable communication between devices and/or procedures having different data rate capabilities, expectations, and/or utilizations of downsampled data. Additionally, the downsampling operations described in FIG. 17 reduce the expected time for proper functioning of devices and procedures where the intended functionality of the devices and/or procedures may depend on the time-dynamic characteristics of the communicated data values. Enable network utilization reduction while providing enough data to implement using domain responses (e.g., differential behavior, integral behavior, step change response, etc.). The downsampling operations described in FIG. 17 may include mixed network configurations and/or legacy communication aspects (e.g., lower data rate capabilities and/or data rate expectations, and/or distinct network protocols, characteristics, and message types). (e.g., components, devices, procedures, and/or operations that each communicatively interact with a network and/or other components, devices, procedures, and/or operations) operation) with the latest communication aspects (e.g., higher data rate capabilities and/or data rate expectations, and/or distinctly different network protocols, characteristics, and message types). You can see it.

Referring to FIG. 18, a schematic diagram of the operation of upsampling a message sequence 1802 is shown. In the example depicted in FIG. 18, a message sequence 1806 (eg, a series of three communications in this example) is received, eg, at a network interface circuit of one of the network gateway devices. In the example described in FIG. 18, the upsampling operation schedules the data represented by message 1806 to match the data rate of the receiving endpoint, for example, in response to any upsampling operation described herein. managing bandwidth on the vehicle's network and/or for off-vehicle communications, maintaining buffer memory, or any other method including upsampling operations of any of the present disclosures. Concerning purpose. In the example depicted in FIG. 18, the upsampling device 1804, which can be a conversion circuit, a network interface circuit, a CND, a circuit connected to a CND, a circuit conditioned by a CND, etc., converts the converted message sequence 1808 ( (e.g., processed as illustrated in FIG. 16 and related disclosure, and/or processed in accordance with any other message transformation and/or message processing operations set forth herein). The example depicted in FIG. 18 depicts a transformed message sequence 1808 for purposes of clarity. However, the transformed message sequences 1808 may not all exist at the same time; for example, these messages can be removed from the cache, deleted, expired, etc. as they are transformed and sent. . Message sequence 1808 is shown to illustrate aspects of the present disclosure. Additionally or alternatively, the transformation of message 1808 may be performed after the upsampling operation is performed, eg, to reduce processing resource utilization.

For example, parts of the message may be excluded or adjusted as part of upsampling before conversion operations (e.g., exchange of frame parts or metadata, encapsulation, processing of payload and/or frame parts, etc.) are performed. can do. In the example depicted in FIG. 18, the upsampled message sequence 1802 may be generated by, for example, a different network gateway device, a different vehicle network that is the source of the first message sequence 1806, an external device (e.g., a service tool, a cloud server, a driving and/or stored on a memory storage device on a vehicle (e.g., as part of stored vehicle data, for later data collection operations, etc.). In this example, the three messages of original sequence 1806 are upsampled to five messages of upsampled sequence 1802. The upsampling operation involves transforming selected messages from the original sequence 1806, e.g., converting the original 50ms data stream 1806 into an upsampled 20ms data stream 1802 by inserting one or more generated messages 1810. The step of changing may be included. Upsampling operations may additionally or alternatively include interpolation and/or extrapolation of the data message 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, upsampling may be performed using the temporally closest message taken or interpolation operation and/or or performed extrapolation operations (e.g., linear fits, spline fits, polynomial fits, moving averages, and/or low-pass filters between available data points and/or between available data points and the expected next data point) (applying the sequence) as the upsampled message 1802.

As used herein, interpolated data points or interpolated data values refer to data values within upsampled message 1802 that are not temporally aligned with the corresponding original data message 1806. As used herein, non-interpolated data points or non-interpolated data values refer to data values that are time-aligned or synchronized within upsampled message 1802 with the corresponding original data message 1806. . The original data message 1806 message and the upsampled message 1802 message may additionally or alternatively have a phase difference, such that in certain embodiments the original data message It will be appreciated that any or all of 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, the trajectory characteristics of the stream of the original data message 1806 (e.g., time domain If any phase difference can be ignored for the purpose of a device or operation that utilizes the upsampled message 1802 to provide a baseline upsampled message 1802 that follows the upsampled message 1802 (e.g., If such device or actuation has a response time or required reaction time that is significantly greater than the magnitude of any such phase difference), certain messages of the original data messages 1806 may be replaced with non-interpolated data messages. Or it can be processed as a synchronous data message.

In yet another example, synchronized data values (e.g., every other data value when switching from 50 ms to 20 ms, e.g., 0 ms phase value and 100 ms phase value) can be used directly, or an adaptation function can be used. (eg, to provide a smooth filtered or otherwise processed data value stream). In certain embodiments, for example, minor transient behavior from various time steps may be unrelated to how the upsampled data values 1802 are utilized or timestamp data may not be further communicated with the message. , so that the actual data values provided from the first data stream 1806 are either It may be desirable to utilize it as an upsampled data value 1802. Thus, in certain embodiments, each message of upsampled data values 1802 may directly correspond to one or more of the values of the first data stream 1806 (e.g., the first The most recent and/or synchronized value of the data stream 1806 is selected (e.g., while retaining the communicated value until the next value is available).

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); (e.g., processing responsive to the rate of change of the upsampled data 1802, e.g., threshold testing for the rate of change) and/or may also be controlled with respect to non-interpolated data values. can. In certain embodiments, all upsampled data messages 1802 are generated from the same process, for example, if the downstream process is particularly sensitive to time variations in the data messages 1806 (e.g., the differential portion of a PID controller). , ensuring 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. It may be desirable to do so. In certain embodiments, non-interpolated upsampled data values 1802 are utilized directly (e.g., to potentially provide a stream of upsampled data 1802 with the actual content of data message 1806) and interpolated upsampled The resulting data values are processed as described herein. In certain embodiments, all original messages 1806 are provided within 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 message 1806 and also support upsampling rates). In certain embodiments, upsampled data message 1802 may further include metadata or other embedded information indicating whether it corresponds directly to original data message 1806 or is a processed message. (e.g., to enable more than one use on upsampled data message 1802, diagnostic operations on the device providing original data message 1806, and/or any other purpose).

In certain embodiments, interpolated upsampled data values 1802 may be determined based on expected values between non-interpolated data values, and this determination may be based on virtual sensors (e.g., other available within the system). (a value model that utilizes information about the value model) and/or an extrapolation fitting operation. In certain embodiments, determining interpolated upsampled data values 1802 may additionally or alternatively utilize upsampled data values 1802 determined according to original data values 1806. providing an expected value and/or an interpolated/extrapolated value that provides a rate of change representation of the upsampled data value 1806 adjusted according to characteristics of the device, component, operation, and/or procedure used. For example, an upsampling operation may include performing predictive operations and/or interpolation/extrapolation to determine the rate of change for the upsampled data value 1802, and a final interpolation to provide the expected rate of change for the upsampled data value 1802. and providing a calculated data value 1802. In certain embodiments, the act of providing the upsampled data value 1802 determines a rate-of-change (or derivative) determination operation within the device that utilizes the upsampled data value 1802 and determines a rate-of-change parameter within the device. Adjusting the rate of change of the upsampled data values 1802 in response to determining, for example, data regarding the time step utilized in the differential operation (e.g., ΔT/5ms or 5ms per temperature change) and/or the time constant. (e.g., the time constant of a low-pass filter, the time constant inherent in a moving average calculation, etc.) in which the upsampled data value 1802 is the change to be performed on it. The rate calculation is adjusted to give the desired response. For example, if the upsampling operation has a significant time step difference between the original data value 1806 and the upsampled data value 1802 (e.g., 50 ms vs. 5 ms), then the upsampled data value 1802 is utilized; Operations such as linear interpolation/extrapolation of data values on the output of a low-pass filter operated by a device that may be configured to process true 5 ms data may introduce significant distortion. Thus, in this example, the operation of upsampling the original data value 1806 may include adjusting the original data value 1806 according to the expected response of the 5ms device that determines the value, thereby performing a simple linear extrapolation. Alternatively, a significant difference can be provided in the trajectory of upsampled data values 1802 between non-interpolated data points compared to a moving average or the like. Operations to adjust the rate of change representation may be performed on upsampled data 1802 and/or downsampled data 1706, or may be omitted.

Whether the non-interpolated original data values 1702, 1806 are utilized directly, the metadata stored with the upsampled and/or downsampled data 1802, 1706, the interpolated data values and/or the non-interpolated Processing operations performed on data values, whether all original data values 1702, 1806 are communicated, providing a rate of change representation of upsampled data and/or downsampled data 1802, 1706 upsampling operations and/or rate-of-change parameters (e.g., filter constants, differential operations, etc.) within the device that utilize the upsampled data and/or downsampled data 1802, 1706; Configuration information regarding downsampling operations may be provided in a memory storage location accessible to a controller and/or circuitry that implements upsampling operations and/or downsampling operations. Any such configuration information may be provided, in whole or in part, at design time, e.g., when including a mobile application and its various network communicating devices, and/or may be provided during runtime operation or Can be updated. In certain embodiments, one or more aspects of configuration information regarding upsampling operations and/or downsampling operations is provided as part of a policy, as a configuration instruction, and/or between devices on separate networks of a mobile application. It may be provided as a configuration table that may be accessible to the CND 108 that coordinates communications. In certain embodiments, one or more aspects of configuration information regarding upsampling operations and/or downsampling operations that are included as part of a policy, configuration instructions, and/or configuration tables adjust and/or update. Can contain default values.

Referring to FIG. 19, an exemplary system that may form part of a mobile application 1902 or a vehicle connects a first network zone 1904 of a vehicle having a first number of interconnections endpoints 1906 and a second interconnection number of endpoints 1906. a second network zone 1908 having a number of connections endpoint 1910; The example system includes a CND 1912 inserted between network zones 1904, 1908 to coordinate communications between endpoint 1906 and endpoint 1910. In the example described in FIG. 19, first network zone 1904 is a first network, second network zone 1908 is a second network, and 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 includes, for example, a configurable Ethernet switch (CES). A distributed topology is utilized in which a plurality of devices 1910 are communicating with a switch 1914 that can communicate with each other. In the example depicted in FIG. 19, a configurable edge gateway 1916 (CEG) can communicate with the first network zone 1904 and read messages from and/or provide messages to the common data bus 1905. In the example depicted in FIG. 19, the CEG 1916 may communicate with the CES 1914 on the second network zone 1908, appear to the CES 1914 as an endpoint device in the second network zone 1908, and/or may be connected to a physical port and/or a logical port of the network zone 1908 .

In the example depicted in FIG. 19, CND 1912 performs operations that coordinate communications between endpoints 1906, 1910 by configuring operations of CEG 1916 and/or CES 1914. The arrangement shown in FIG. 19 is a schematic diagram for clarity of this description and depicts distinctly different components for CND 1912, CEG 1916, and CES 1914. However, CND 1912, CEG 1916, and CES 1914 can be provided in combination, in whole or in part, in the same housing and/or on the same circuit board, and/or can be subdivided in whole or in part. Additionally or alternatively, one or more or all of CND 1912, CEG 1916, and/or CES 1914 may be connected to another controller within mobile application 1902, such as a vehicle controller and/or endpoint 1910. controller. Although network zones 1904, 1908 are shown having separated physical components, network zones 1904, 1908 can 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 a first network zone 1904 as a legacy network with endpoints 1906 that are legacy devices and/or legacy compatible devices, and a first network zone 1904 that has endpoints 1910 that are new, modern, upgraded and/or migrated devices. 2 network zones 1908.

Exemplary operations for coordinating communications between endpoints 1906, 1910 include, but are not limited to, operations such as those described below. Coordinating operations may 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 communication, and/or destination addresses for communication. In certain embodiments, applications, services, and/or flows may be provided with identifiers as an implementation for associating related components, such as endpoints. Coordinating operations may be performed by, but not limited to, a CND, a network gateway, a network interface circuit, and/or a gateway interface circuit. Although adjustment operations are described in the context of certain exemplary adjustment devices throughout this disclosure, embodiments can be configured with other devices that perform adjustment. Exemplary communication and/or coordination operations include:
- Communication between the first endpoint 1906 and the second endpoint 1910 (both a step of providing
- encapsulating the message from the first network zone 1904 and providing the encapsulated message to the second network zone 1908;
- determining whether the requesting device (and/or associated flow) on one of the network zones (1904, 1908) has permission to request communication to a device on the other one of the network zones; , providing a communication in response to the authorization decision;
Determination of authorization for the requesting device, communication performance of the requesting device and/or provider device, and/or network performance parameters of one or both network zones (e.g. current available bandwidth, absolute or current network capabilities, network utilization, etc.) and/or the data rate, requested resolution, of communications between devices in these network zones based on priority values for communications associated with the requesting device (and/or associated flows); , and/or adjusting at least one of the request response time.
- performing up-sampling and/or down-sampling operations on data communicated between network zones;
- mirroring the communications from the first endpoint 1906 to a port of the second network zone 1908, including encapsulating, configuring, processing, and/or upsampling or downsampling the communications of the mirroring target;
- providing communications from the first endpoint 1906 to a device coupled to the second network zone 1908, such as a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool, and/or a network monitoring device; and/or multicast, in which case providing the communication includes encapsulating, configuring, processing, and/or upsampling or downsampling the provided communication and/or unicasting the provided communication. and/or can be provided as a subscription service;
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 providing to a network monitoring device and/or in which case providing the communication includes encapsulating, configuring, processing, and/or upsampling or downsampling the provided communication; or the provided communications may be unicast, multicast, and/or provided 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 monitoring devices to the first endpoint 1906; and/or in this case, providing the communication includes encapsulating, configuring, processing, and/or upsampling or downsampling the provided communication, and/or unicasting the provided communication; can be multicast and/or provided as a subscription service;
o Further, providing the communication as a command value (e.g., a set value, a target value, or setting a threshold),
- 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 monitoring devices to the first endpoint 1906; and/or in this case, providing the communication includes encapsulating, configuring, processing, and/or upsampling or downsampling the provided communication, and/or unicasting the provided communication; capable of being multicast and/or provided as a subscription service;
o Additionally, providing the communication as a test run value, e.g., when the first endpoint 1906 performs an action related to an active text run action of the mobile application in response to the command value (e.g. performing certain operations or active diagnostic operations, etc.);
unicasting, multicasting the provided communication, configured such that the provided communication satisfies a superset of requirements (e.g., data rate, resolution, units, etc.) of the second endpoint 1910 device; and/or providing communications from the first endpoint 1906 to a number of second endpoint 1910 devices, if provided as a subscription service;
- A first device (e.g., a device coupled to the first endpoint 1906, second endpoint 1910, and/or network zone 1904, 1908, e.g., a diagnostic device, an OBD device, a service tool, a manufacturing tool, an OEM tool) , and/or network monitor device), determine a target device that responded to the parsed communication value (e.g., a communication recipient and/or a communication provider that responded to the communication value), and including communication of the target communication recipient and/or communication provider depending on the analyzed communication value;
For example, the communication value may include a generic and/or standard component identifier (e.g., turbine temperature, front passenger door actuator, etc.), and the CND 1912 may include a component identifier according to the current configuration of the mobile application. Corresponding respective endpoints 1906, 1910 can be determined, as well as the routing, encapsulation, processing, etc. of communications for performing transformations between the first device and the target device. For example, such actuation may change the configuration and placement of a device on a network zone without requiring the device, service personnel, or other requestor to track the specific configuration and placement of the device. enable
o In addition or in the alternative, such operations may cause the CND 1912 to perform configuration changes (e.g., replacing or moving a device from one network zone to another, changes to a device's communications parameters or capabilities). etc.) and/or for use during runtime operation, for subsequent use, and/or as a default configuration subject to further updates. performing runtime decisions to establish the location, identity, configuration, communication parameters, and/or communication capabilities of the capable device;
- For example, multiple devices may be 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 performing any one or more of the above-described operations with respect to a group or sub-group of devices, where the tools and/or network monitoring devices can be treated as separate devices;
For example, a first configuration has two (or more) devices using separate endpoints 1906, 1910 and a second configuration has two (or more) devices utilizing a single endpoint 1906, 1910. of devices (and/or two devices aggregated into a single device), such operation allows for multiple configurations, updates, and/or upgrades of the mobile application. Exemplary and non-limiting embodiments include the aggregation of multiple sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) that communicate to network zones 1904, 1908 through a single interface, and/or a single network. interface (e.g., a single communication device such as an edge gateway or configurable edge gateway that interfaces as a single endpoint 1906, 1910 to a single network zone 1904, 1908 and manages communications for the associated devices) It involves replacing the interfaces of the underlying components. In yet another example, such operation allows devices to communicate across multiple network zones regardless of configuration changes, support upgrades and updates regarding device relationships with endpoints 1906, 1910, and support backward compatibility (e.g. , subsequent configurations and subsequent inter-device control distribution where the operation of the CND 1912 enables previous systems with distinctly different configurations to support the latest configuration and/or inter-device control distribution). enable
o In addition or in the alternative, such operation may cause CND 1912 to respond to configuration changes (e.g., participation of a single endpoint between more than one device and a network zone, aggregation of devices, etc.). storing the responsive configuration information and/or for use during runtime operation, for storage for subsequent use, and/or for storage as a default configuration subject to further updates; performing runtime decisions to establish location, identity, configuration, communication parameters, and/or communication capabilities, and/or aggregate status of the device;
- For example, the device is distributed among more than one endpoint 1906, 1910, but other endpoints or devices (e.g., diagnostic devices, OBD devices, service tools, manufacturing tools) in communication with the network zone 1904, 1908 , OEM tools, and/or network monitoring devices) perform any one or more of the above operations on a group or subgroup of devices if the device is capable of treating these devices as a single device; step,
For example, a first configuration includes a device that utilizes a single endpoint 1906, 1910, and a second configuration includes a device (or a portion thereof) that utilizes more than one endpoint 1906, 1910 (and/or a second Such operation allows for multiple configurations, updates, and/or upgrades of the mobile application, including previously aggregated devices (including two or more separate devices in the configuration of the mobile application). . An exemplary and non-limiting embodiment includes a group of sensors (e.g., smart sensors with network communication capabilities, multiple signals, etc.) that communicate to a network zone 1904, 1908 through a single endpoint 1906, 1910, each with a separate endpoint. 1906, 1910 (and/or subgroups of multiple sensors each having a separate endpoint). In yet another example, such operation allows devices to communicate across multiple network zones regardless of configuration changes, supports upgrades and updates regarding the device's association with endpoints 1906, 1910, and supports backward compatibility ( (e.g., subsequent configurations and inter-device control distribution where operation of the CND 1912 enables a prior system with a distinctly different configuration to support a later configuration);
o In addition or in the alternative, such operation may cause CND 1912 to perform configuration changes (e.g., splitting multiple devices behind a single endpoint on a single network zone into more than one endpoint). and/or for use during runtime operation, for storage for subsequent use, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation, and/or for use during runtime operation. or performing runtime decisions to establish the location, identity, configuration, communication parameters, and/or communication capabilities of the device, and/or the aggregate status of the device, which may be stored as a default configuration subject to further updates. including stages;
・The CND 1912 determines the available services (e.g., data parameters available for communication, command values available for execution, and/or their configurations, e.g., speed information, units, resolution, accuracy, precision, available determining the subscription clients (e.g., devices, flows, and/or endpoints) for the available services; implementation of a service specification architecture to
o In addition or in the alternative, such operations may cause CND 1912 to view available services (and/or portions of available services) in order to publish available services; and/or determining permission and/or authorization to subscribe to available services;
o In addition or in the alternative, such operation allows the CND 1912 to control endpoints, devices, flows, and/or external devices, such as diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, and and/or determining a subscriber entity as a network monitoring device;
o In addition or in the alternative, such operation may depend on the devices, endpoints, or associated flows that CND 1912 publishes and/or that the CND 1912 subscribes to. determining the priority of service-specific communications that may be
o In addition or in the alternative, such operation may be performed by the CND 1912 based on operating conditions (e.g., mobile application operating conditions, network status of the affected network zone or zones, one or more external adjusting the service specification architecture operation in response to a communication status of the device (such as a communication status of the device);
o In addition or in the alternative, such operation may cause the CND 1912 to store information indicating available services, public parameters (permissions, priorities, associated operating conditions, etc.), and/or subscription entity information. including accessing information;
o In addition or in the alternative, such operations may include the CND 1912 receiving updates such as policy descriptions, service configuration descriptions, e.g., but not limited to, launching mobile applications. or updating the stored information in response to one or more runtime updates from endpoints, devices, and/or flows executed during the operation of the shutdown;
o In addition or in the alternative, such operations may be performed by the CND 1912 based on runtime operations using the service specification architecture with or without storing information and/or updating stored information. and/or in response to priorities and/or permissions for devices, endpoints, and/or flows requesting updates and/or runtime implementation. enabling updates to stored information, runtime updates to stored information, and/or runtime operations implementing the service specification architecture;
- Additionally or alternatively, operation of the example CND 1912 may include adjusting the operation of any one or more of the above in response to operating conditions of the mobile application (e.g., high power operation). , high transient operation, stop operation, start operation, selective operation modes, e.g., during certain operations such as vocational operation, power take-off (PTO) operation, charging operation, cruise control operation, autonomous vehicle operation. adjusting the communication operation). Adjustments to communications may be qualitative (e.g., allowing or disallowing certain communication types during certain operating conditions, certain communication priority thresholds, etc., and/or during certain operating conditions as a data ingestion event). capture certain data values), quantitative (e.g., control communication speed, network zone utilization, external device communication speed, etc.), or a combination thereof (e.g., control communication speed for certain communication types, etc.) (e.g., enabling a reduction in the communication capabilities of a device during an outage operation, but not allowing external devices to be increasing the communication capabilities of the device for certain devices or flows during a start-up operation, but reducing the communication capabilities of the device for other devices or flows;
- Additionally or alternatively, operations of the example CND 1912 may cause any one or more of the operations described above to result in network zone degradation (e.g., loss of throughput, network zone failure conditions of one or more devices (e.g., loss of communication with endpoints of the network, injection of noise onto or presence of noise on the network zone, physical failure of at least a portion of the network zone); When the CND 1912 adjusts a data source for a failed device, adjusts a data rate for a failed device, implements a backup data source for a failed device, reroutes data to a backup data destination for data provided to a failed device. If specified, the vehicle controller's loss of control function (e.g., when the vehicle controller lacks data values to perform its mission), such as when implementing an event-driven data collection scheme when a device failure is an event. the loss control function indicates that the vehicle controller has lost communication with the connected network zone; and/or the loss control function indicates that the vehicle controller has lost communication with its adjusting in response to abnormal operating conditions for the mobile application, including conditions such as an indication by the vehicle controller or another controller in the system that the system is unable to perform the program. Yet further exemplary operations of CND 1912 in response to abnormal conditions include one or more of the following:
o Providing data values to the vehicle controller from alternative sources (e.g., the data values are from different endpoints, network zones, etc.; this provisioning step involves encapsulating, configuring, processing, and and/or upsampling or downsampling to provide a communication equal to the original data value that was lost, or a replacement communication that may be sufficient as a backup data value to the vehicle controller);
o For example, a second vehicle controller may be configured to act as a backup to the vehicle controller and be fully capable of performing the lost control function and/or perform alternative operations in place of the lost control function. (e.g., 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. Loss of controller Communication of data values to an alternate source (e.g. with distinctly different data rates, resolution, units, precision, etc.) or to another data value (e.g. a second vehicle) to replace all or a portion of the control functions In addition to or in the alternative, if the controllers utilize distinctly different data sets to perform full-featured operation or alternative operation) and each other to a second vehicle controller, CND1912 may provide data from either network zone 1904, 1908 to a vehicle controller and/or a second vehicle controller that may reside on either network zone 1904, 1908;
o For example, if a failure condition, loss of device, or endpoint indicates that one or more data values are not being used, one or more data values may be given a lower priority in view of this abnormal condition. 1 in response to an abnormal condition if and/or one or more data values are indicated as incorrect in view of this abnormal condition (e.g., a sensor value from a sensor has a fault condition or a fault condition). or suppressing communication of two or more data values;
o When endpoints and/or devices are reachable through more than one network zone (e.g., if these zones are logically separated but physically coupled, one (see FIG. 15), and/or the second vehicle controller and/or second endpoint coupled to the second network zone is connected to the first network zone. A first network zone (e.g. a degraded shifting communications from a network zone to a second network zone;
o repeating communications from a first network zone (e.g., a degraded network zone) onto a second network zone;
o For example, if the endpoint is physically coupled or capable of coupling to both the first network zone and the second network zone (e.g., if the separation between these network zones is a logical separation) , and/or if the endpoint is reachable through more than one network zone as illustrated in FIG. shifting the endpoint from a first network zone (e.g., a degraded network zone) to a second network zone, which further includes adjusting any other operation occurring within the system. further comprising updating the location of the shifted endpoint to other devices/endpoints or converting communications with other devices/endpoints in the system;
o Shifting the termination point from the first network zone to the second network zone, shifting the related communication to the second network zone, and/or repeating the related communication on the second network zone. A combination of these stages,
- the endpoint of the first network zone (and/or one or more additional network zones) and external devices (e.g. diagnostic devices, OBD devices, service tools, manufacturing tools, OEM tools, network monitoring devices, driver devices) , cloud computing devices, and/or third party applications), in which case includes any one or more of the operations described above, and/or components of the system (e.g. , endpoints, devices, flows, network zones, etc.); restricting communications according to operating conditions of the mobile application; authorizing and/or prioritizing endpoints, associated flows, and/or external devices; Restrict communications according to degree, time (e.g., daily, weekly, monthly, etc.), aggregated according to operating conditions (e.g., travel, events, etc.), and/or data values are total data sent/received values, data rate values , and/or a combination thereof (e.g., associated data service providers, endpoints, associated flows, and/or and/or restricting communications according to an external data access type (e.g., cellular, WiFi, Bluetooth, hardware/port connection, etc.); and/or a combination of any one or more of the above.

The described operation of CND 1912 may be included in all or any portion in the embodiments listed throughout this disclosure. endpoints, associated entities (e.g., owners, manufacturers, operators, service personnel, OEMs, third parties, etc.), flows, devices (e.g., controllers, actuators, sensors, tools, and/or external devices, Permissions and/or priorities for any aspect, including switches, gateways, etc.) may depend on the operating conditions of the mobile application and/or on one or more devices (the same device or It will be understood that it may differ according to the status of different devices). Additionally, 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 when viewing published available services, but a low priority when publishing and/or subscribe to available services. and/or may have only permission levels. In another example, a given endpoint has 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 may have only a lower priority for communicating data values to other endpoints during other operating conditions (e.g., steady state cruise control operation). The priorities presented herein generally relate to comparisons between competing rights in terms of resources (e.g., network bandwidth, response times, data storage, access to limited data resources, etc.), and However, the permissions provided herein generally require the ability to perform the requested operations, such as certain data, metadata, data rates, data storage, access to the device and/or external devices, etc. related to the ability to Thus, an aspect may have a high priority and a low permission level (e.g., the aspect has a high priority to access a limited number of data values, functions, etc.), or any other combination. can have separate priorities and permissions.

Resolving conflicting priority rights is to always give priority to the highest priority requestor, and to provide a weighted response based on priority (e.g., requesting higher priority requests over lower priority requests). (providing information more often in response to requests) and/or utilizing trust-based schemes that allow information to be provided to lower priority requests after a period of time and/or number of requests. This can be done using any of the following methods:

As used herein, the task of a device (e.g., controller, endpoint, vehicle, mobile application, etc.) should be understood broadly and at least performs the intended or primary function of the mobile application. including the related functionality, structure, capabilities, and operation of a device that supports the operation of a mobile application. Without being limited to any other aspect of the present disclosure, the intended functionality or primary functionality of the mobile application may include the propulsion operation of the mobile application in accordance with the design of the propulsion functionality (e.g., specified torque, speed, response, etc.). non-propulsive actuation of mobile applications with designed non-propulsive functions (e.g. industrial actuation, occupational actuation, pumping actuation, shaft power, provision of travel range, and control thereof) ), including one or both of the following. In certain embodiments, the intended or primary functionality of the mobile application may be affected by abnormal operational responses, such as in a limp-home mode, which may have only lower functionality than the designed propulsive or non-propulsive functionality. including operation, failure conditions or communication of failure conditions, and/or prevention of further degradation of the vehicle and/or mobile application. In certain embodiments, the intended functionality or primary functionality of a mobile application is to send and/or receive external data, perform update operations, facilitate service operations, facilitate updates. and/or upgrade operations. Accordingly, the tasks of a device may differ 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 components, devices, and/or their controllers. Those skilled in the art who have the benefit of the disclosure of the present invention, and who have the information normally available when considering a particular mobile application, will be able to understand the mission of the mobile application, the role of the device of the mobile application, and the operational and status conditions of the mobile application. The availability of these devices will be readily understood.

Referring to FIG. 20, the example 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 distinctly different from the second risk exposure profile 2004. As utilized herein, a risk exposure profile refers to the risk to which, in at least one aspect, a possible associated component (e.g., first network zone 1904 and/or second network zone 1908 in the example set forth in FIG. 20) profiles, e.g. geometric risks (e.g. risks due to location within the mobile application for the components provided), environmental risks (e.g. temperature, contaminants, NVH, EMI, heat transfer environment (e.g. exposure to radiant energy) , conductive heat transfer, and/or convection or lack of convection), and/or environmental factors for the installed components, such as exposure to environmental disturbances such as collisions with service technicians, or falling tools, etc. risks from), failure mode risks (e.g. short circuit events, exposure to bare wire events, and/or mobile application components (e.g. exhaust components, engine components, aftertreatment components, and/or high temperatures) identified or apparent failure of the mobile application or its components, such as, but not limited to, failure of any other component having fault-inducing energy, such as electric potential, rotational energy, or mechanical energy, etc. failure modes), dominant risk types (e.g., a given risk may affect multiple areas or systems of the vehicle, and any failure modes located in or coupled to these areas) When components may share a risk type, whereas components that are isolated from these areas or systems may not share a risk type, regardless of their proximity or other considerations. ), and/or dominant disturbance risks (e.g., a given disturbance, such as a particular service event, operating conditions, weather event, abnormal charging voltage, may affect multiple areas or systems of the vehicle). , components located in these areas or coupled to these systems may share disturbance risks, whereas components isolated from these areas or systems may be affected by their proximity or other including cases where the risk of disturbance may not be shared regardless of considerations).

In certain embodiments, the first risk exposure profile 2002 is located at a distinctly different location on the vehicle than the second risk exposure profile 2004 (e.g., one on the left and one on the right); It is considered that a given environmental risk is arranged such that it is unlikely to affect both network zones, and that a given failure mode is arranged such that it is unlikely that it affects both network zones. be arranged in such a way that risks (e.g. collisions, accidents, operational failures, malfunctions of components, etc.) are unlikely to affect both network zones, and/or possible disturbances that affect both network zones. They are clearly different in at least one aspect of their risk exposure profile, such as being less likely to have a negative impact. In certain embodiments, a difference in one risk aspect is sufficient for the risk exposure profile to be distinctly different, e.g., one or more failures (e.g., complete loss of power) may cause both Although there may be a high probability of impacting network zones, these network zones may still have distinctly different risk exposure profiles with respect to other potential failures. Furthermore, such network zones may have exposure to the same types of risks, but still have a first network zone exposed to frontal collisions and a second network zone exposed to rearward collisions. These network zones can be considered to have distinctly different risk profiles.

In the example depicted in FIG. 20, CND 1912 is inserted between first network zone 1904 and second network zone 1908 and is configured to coordinate communications between network zones 1904, 1908. In the example depicted in FIG. 20, CND 1912 has the ability to communicate with the remaining network zones 1904, 1908 if one of the network zones 1904, 1908 undergoes a failure or degradation event. Accordingly, CND 1912 has the ability to reroute communications away from failed network zones 1904, 1908, such as to a backup controller (not shown), other network zones (not shown), etc. The example described in FIG. 20 provides risk partitioning of network zones 1904, 1908 and allows for redundancy design and continued operation of mobile applications in the event that one of network zones 1904, 1908 experiences failure or degradation. (regardless of whether or not it complies with the mobile application mandate or is in a low-functionality operating condition).

Referring to FIG. 21, the example system includes a mobile application 1902 having a first network zone 1904, a second network zone 1908, and a third network zone 2108. Network zones 1904, 1908, 2108 can have distinctly different risk exposure profiles, and/or any two of network zones 1904, 1908, 2108 can have distinctly different risk exposure profiles. . The example system includes a CEG 2102 communicatively coupled to a first network zone 1904 , a CES 2104 communicatively coupled to a second network zone 1908 , and a CES 2104 communicatively coupled to a third network zone 2108 . and a second CES 2106. In the example depicted in FIG. 21, CND 1912 is distributed, with a portion of CND 1912 configured to coordinate communications for each network zone 1904, 1908, 2108. The example depicted in FIG. 21 showing the components as a CEG 2102, a CES 2104, and a second CES 2106 is a non-limiting example, and the network zones 1904, 1908, 2108 may It can be of type. In certain embodiments, corresponding operational components (CEG 2102, CES 2104, and CES 2106 in the example depicted in FIG. 21) may share risk exposure profiles associated with associated network zones 1904, 1908, 2108. may have distinct risk exposure profiles associated with the associated network zones 1904, 1908, 2108. Additionally or alternatively, corresponding portions of CND 1912 may share risk exposure profiles associated with associated network zones 1904, 1908, 2108. The embodiment described in FIG. 21 illustrates the division of risk into network zones and components and the planned addition of redundancy between these network zones and components, which can be provided in either manner. ing. 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 distinct risk exposure profiles. For example, because it does not have a backup network available and is already a single point failure mode within the system, it may be shared with yet another risk exposure profile or one of the other networks (e.g., network zones 1908, 2108). risk exposure profile. In certain embodiments, one or more of the networks (e.g., network zone 2108) may be configured to have a very low risk exposure profile (e.g., environmental risk, disturbance risk, and/or (in a central location insulated from failure mode risks, etc.), and can be configured to provide backup operation to one or more other networks (eg, network zone 1908). In certain embodiments, the configuration for functioning backup operations includes redundant connectivity to the endpoint to other networks, provision of a backup controller and/or stored executable instructions to implement backup control operations, preparing an associated operating component (e.g., CES 2106) to perform data communication operations to other networks; and/or performing operations at an associated CND portion 1912 of any or all other CND portions 1912; It includes one or more of the preparations for In certain embodiments, any or all of the networks may be configured to provide backup operations for one or more or all of the other networks. In certain embodiments, colocating one or more portions of the CND 1912 with relevant ones of the actuating components; disposing them in a housing with the relevant ones of the actuating components; and/or may be located on the same substrate as related ones of the operating components. In certain embodiments, one or more portions of the CND 1912 may be co-located with the distributed controller through the vehicle, placed in a housing with the distributed controller through the vehicle, or placed on the same board as the distributed controller through the vehicle. can do. In certain embodiments, one or more portions of CND 1912 may be provided as executable instructions stored on another device (e.g., an operating component, a vehicle controller, and/or another controller). The processor, which executes the instructions, causes the device to perform one or more of the operations of CND portion 1912. In the example depicted in FIG. 21, CES 2104 coordinates communications between a second network zone 1908 and a third network zone 2108 that communicates, for example, at a port of CES 2106. In the example depicted in FIG. 21, CEG 2102 coordinates communications between a first network zone 1904 and a third network zone 2108, which communicate on separate ports of CES 2106, for example.

Exemplary and non-limiting network types for each network zone are Controller Area Network (CAN), Media Oriented System Transport (MOST) Network, Local Interconnect Network (LIN), FlexRay Network, Time Triggered Protocol (TTP) networks, Low Voltage Differential Signal Transfer (LVDS) networks, Audio Video Bridging (AVB) capable networks, customized versions of any one or more of the foregoing, and/or any one or two of the foregoing. Contains one or more of the above proprietary versions.

Referring to FIG. 22, an exemplary apparatus for performing network redundancy operations is shown. The example described in FIG. 22 is consistent with the embodiment described in FIG. 21, but may be applied to any of the systems and/or mobile applications listed throughout this disclosure. The example apparatus includes network redundancy circuitry 2202 that selectively provides regulation control commands 2204 where one or more CND portions 1912 are mobile in response to regulation control commands 2204. Inter-network communications 2206, 2208, 2210 are performed between multiple network zones (eg, 1904, 1908, 2108) of the application. Exemplary and non-limiting inter-network communications 2206, 2208, 2210 include rerouting data between network zones, shifting endpoints between network zones, and connecting a first CND portion to a second CND portion. taking over the coordination of different network zones, utilizing alternative data sources and/or backup control operations, and/or transferring data between and/or on one or more network zones; Includes operations that shift, mirror, and/or suppress values.

Exemplary and non-limiting coordination control commands 2204 may include one or more endpoints of a network zone being unavailable, one or more endpoints of a network zone being in a failure condition, and/or one or more endpoints of a network zone including an indication that one or more of the endpoints are unable to perform their respective endpoint mission operations and/or are providing unauthorized communications. In certain embodiments, the coordination control instructions 2204 include instructions to utilize alternative data sources and/or backup control operations, instructions to shift endpoints between available network zones, and/or instructions to utilize one or more and/or instructions for shifting, mirroring, and/or suppressing one or more data values between and/or on network zones of the network. In certain embodiments, the coordination control commands 2204 include a status condition, such as "one of the network zones has failed," one or more endpoints or a list of other values indicating the status of the endpoints and/or network zones. , where one or more CND portions 1912 conduct communications in response to coordination control commands 2204 and/or control redundant operation according to stored configuration information.

Referring to FIG. 23, an example 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 of the CAN network type, the second network zone 1908 is of the Ethernet network type, the third network zone 2322 is of the Ethernet network type, and the fourth Network zone 2324 is an electrical signal zone. The example network zones 1904, 1908, 2322, 2324 were selected to depict certain aspects of the present disclosure and are non-limiting.

In the example depicted in FIG. 23, the CND 1912 communicates with the first CEG 1916 and provides communication to the ports of the first CES 1914 to connect the endpoints of the first network zone 1904 and the second network zone 1908. communicating between the endpoints of the fourth network zone 2324 and the endpoints of the second network zone 1908 by communicating with the second CEG 2308 and providing communication with a port of the first CES 1914; a first CES 1914 communicatively coupled to a second CES 2320 , thereby providing communication between the second network zone 1908 and the third network zone 2322 (and further by communication of the CEGs 1916 , 2308 ); a first network zone 1904 and a fourth network zone 2324); , 2324 (through the second network zone 1908 in the example illustrated in FIG. 23). The CND 1912 may, for example, communicate authorization information, priority information, etc. to the first CES 1914 and/or the second CES 1916, which may selectively communicate with an external communication device 2326 (e.g., a head unit). further coordinate communications between the endpoints of network zones 1904 , 1908 , 2322 , 2324 and external communication devices 2326 . Although the CND 1912 in the example described in FIG. 23 is shown as being inserted between the CES 1914, 1916 device and the external communication device 2326, the CES 1914, 1916 device can be coupled directly to the external communication device 2326. , and/or an external communication device 2326 may be coupled to one port of the network zone 1908, 2322. The example depicted in FIG. 23 depicts a transmitter/receiver 2328 that performs communication operations with external devices (eg, cloud servers, service tools, manufacturing tools, driver devices, etc.). In certain embodiments, transmitter/receiver 2328 can be integrated with external communication device 2326 and/or more than one transmitter/receiver 2328 can be present. Additionally or alternatively, for example, physical port access on one or more of network zones 1904, 1908, 2322, WiFi transmitters/receivers, Bluetooth transmitters/receivers, etc. A plurality of external communication access paths may be available, including but not limited to.

Although CND 1912 is shown as a separate device, CND 1912 may be co-located with one or more of network operating components 1916, 1914, 2308, 2320, with a vehicle controller (not shown), and/or with any number of can be distributed across devices. The example depicted in FIG. 23 further includes a network redundancy circuit 2202, shown separately for convenience of this description, that selectively provides coordination control commands and degrades or loses network zones and/or their endpoints. The network operating components 1916, 1914, 2308, 2320 provide redundancy commands and data rerouting commands responsive to the . Exemplary operation of network redundancy circuit 2202 routes communications from first endpoint 2302 on first network zone 1904 to second endpoint 2304 on second network zone 1908 (during normal operation). and changing the routing from the first endpoint 2302 on the first network zone 1904 to the third endpoint 2312 on the third network zone 2322 (e.g., if the second endpoint 2304 fails or malfunctions). (in response to) steps.

Exemplary operation of CND 1912 provides differential priority and/or permissions for second endpoint 2304 on second network zone 1908 compared to third endpoint 2306 on second network zone 1908. providing access, where the differential priority and/or permission access includes communicating with an external communication device 2326, storing data (e.g., a buffer on any device of mobile application 1902; (into memory storage) and/or data communication throughput, acquisition speed, etc.

Exemplary operations of CEG 2308 include operations that perform analog/digital (A/D) processing of communications on fourth network zone 2324. For example, endpoint 2310 can be a sensor that provides an electrical signal representative of a sensed value and/or an actuator responsive to an electrical signal from CEG 2308. In certain embodiments, endpoint 2310 can include more than one electrical signal, such as, for example, a diagnostic signal, a heartbeat, or a status signal. In certain embodiments, CEG 2308 performs signal processing of communications from endpoint 2310, such as debouncing, filtering, saturation (e.g., setting aside high or low values for diagnostic information), rescaling, linearization, or perform other operations. In certain embodiments, the CEG 2308 includes converting the electrical signal into a sensed value (e.g., pressure, temperature, velocity, 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 the standard 16-bit value provided by endpoint 2310 or a lookup table for endpoint 2310), normalizing the sensed value (e.g., adjusting the sensed parameter to Giving a value between 0 and 1 with matching importance and/or when the algorithm operated on the receiving endpoint, such as 2314 on the third network zone 2322, utilizes different sensors with different scales, 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. generating an electrical signal payload that may include one or more of the steps of converting between and/or rescaling fixed point values of the sensor; Those skilled in the art who have the benefit of the disclosure of the present invention, and who have the information normally available when considering electrical signal-based endpoints 2310 and data destination endpoints (any other endpoints), will appreciate that provided by the endpoints 2310 considered Payload processing operations to be performed that provide a payload configured for a destination endpoint can be easily determined from the electrical signal. Payload processing can be performed in reverse, e.g., by taking an incoming payload from a communication and transmitting an electrical signal from the incoming payload (e.g., a command to adjust an actuator, not configured to a particular endpoint 2310). It will be appreciated that a potential electrical signal, etc.) can be configured to the endpoint 2310. The example CEG 2308 is provided to a port of the CES 1914 by, for example, providing communication frames, encapsulating processed payloads, and having a protocol configured for the second network zone 1908 (in this example). Generate further communications. In certain embodiments, the CEG 2308 provides the timestamp, e.g., by adjusting the timestamp (e.g., if the endpoint 2310 provides a timestamp that is not properly configured for the mobile application 1902). 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 the mobile application 1902) and/or by preparing or adjusting a destination indicator of the communication.

Exemplary operations of CEG 1916 include processing payloads of communications from endpoint devices 1906, 2302 and/or performing any other payload processing operations set forth in this disclosure. Exemplary operation of the CEG 1916 includes encapsulating the payload of the communication from the endpoint device 1906, 2302 and/or transferring all or a portion of a frame of the communication from the endpoint device 1906, 2302 to the second network zone 1908 (in this example (a) encapsulating the communication with a protocol configured for the communication. In certain embodiments, the encapsulated portion of the frame of the communication from the endpoint device 1906, 2302 includes, for example, adding or adjusting a timestamp, adding or adjusting a source indicator, and/or Further processing may be performed to add or adjust destination indicators. In certain embodiments, encapsulation of frames or portions thereof, with or without processing, allows one or more CAN devices not to be directly coupled to a CAN network, but to another endpoint (e.g., FIG. 23 for example, to enable communication between CAN devices when on separate network zones, including when interfacing through a third network zone 2322 (termination point 2316), which in the example described in , is an Ethernet network.

In certain embodiments, the CEGs 1916, 2308 may share a port of the CES 1914 and/or may utilize separate ports to couple to the second network zone 1908. A network zone of a mobile application may have any alternative 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. The exemplary mobile application includes a first network zone configured as a first virtual local area network and a second network zone configured as a second virtual local area network. In this example, the first network zone and the second network zone may share the physical hardware of the network and/or a portion thereof.

Referring again to FIG. 23, the example system includes a first vehicle controller (e.g., endpoint 2302) on a first network zone 1904 and a second vehicle controller (e.g., endpoint 2302) on a second network zone 1908. 2304) and a network redundancy circuit 2202 that selectively provides coordinated control commands, in which case the CND 1912 includes a Adjust the stage of coordinating the communication of. Exemplary and non-limiting regulatory control commands include an off-nominal condition supporting first vehicle controller 2302, loss of a data element for first vehicle controller 2302, and and/or include one or more of the loss control functions of the first vehicle controller 2302. Example and non-limiting adjustments to coordinating communications include providing alternative data elements to the first vehicle controller 2302 (e.g., from different endpoints 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., the second vehicle controller 2304 is configured to implement backup operation for all or a portion of the lost control function); step) and/or providing normally available data values on the first network zone 1904 to the second network zone 1908 (e.g., for use in implementing backup operations for all or a portion of the loss control function). the second vehicle controller 2304). An example adjustment to the step of regulating communication suppresses communication of data values normally available on first network zone 1904 in response to a loss control function of first vehicle controller 2302 (e.g., suppressing data of a suppression target). (if the value is no longer needed on the first network zone 1904 and/or if the data value of the suppression target is no longer indicated as legitimate data). The example system transfers data values typically available on the first network zone 1904 to the second vehicle controller 2304 (e.g., includes the data values for utilization by the second vehicle controller 2304). CND 1912 (e.g., to provide data to the second vehicle controller 2304 to perform backup operations for all or a portion of the lost control functions) as a data value for the second network zone 1908 (e.g., to provide data to the second vehicle controller 2304 to perform backup operations for all or a portion of the lost control functions). . A loss of control function may include the total or partial loss of a control function normally performed by the first vehicle controller 2302, the endpoint 1906 of the first network zone (e.g., the endpoint 1906 is unable to perform the lost control function) loss of communication with the first vehicle controller 2302 (e.g., failure codes, fault conditions, and/or unauthorized access provided by the first vehicle controller 2302); 2302) and/or loss of communication with the first vehicle controller 2302.

The example system includes a first vehicle controller 2302 positioned in a first risk exposure profile and a second vehicle controller 2304 positioned in a second risk exposure profile, where: The first risk exposure profile is distinctly different from the second risk exposure profile. An exemplary and non-limiting difference between these risk exposure profiles may be one of a geometric distinction, an environmental distinction, a failure mode distinction, a dominant risk type distinction, and/or a dominant disturbance distinction. or two or more.

Certain alternative and/or additional coordination control commands provided by network redundancy circuit 2202 may include abnormal conditions supporting first network zone 1904, at least one endpoint 1906 of first network zone and first network including one or more of a loss of communication between the zones 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 and non-limiting adjustments to coordinating communications include: routing at least one communication from first network zone 1904 to second network zone 1908; repeating one communication to a second network zone 1908; shifting at least one endpoint (e.g., 1906) from the first network zone 1904 to a second network zone 1908; shifting 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 the communications associated with the at least one endpoint (e.g., 1910) from a network zone 1908 to a first network zone 1904 (e.g., utilizing endpoint 1910 as an alternate data source for lost endpoint 1906 in first network zone 1904); Contains 2 or more. Although the operation between the first network zone 1904 and the second network zone 1908 has been described for illustrative purposes, the operation may include first network zone-second network zone, first network zone-third network zone. zone and/or between a second network zone and a third network zone. Additionally or alternatively, certain operations (e.g., shifting the endpoint from one network zone to another) may be available in the circumstances to be understood. suggests that the associated endpoint is movable between network zones, at least if the endpoint is joined or can be joined to more than one network zone. If the endpoint is reconfigurable to provide legitimate communication (e.g., if the endpoint is able to detect the network protocol, frame structure, etc., and/or if the endpoint is able to If these network zones are compatible (e.g., have matching protocols, frame configurations, etc.) and/or have somewhat variable protocols, frame configurations, etc. and/or where these network zones are separate virtual local area networks (e.g., the separation between each network zone is at least partially logical rather than physical). (if applicable).

In certain embodiments, CND 1912 can be colocated and/or have portions colocated with one or more vehicle controllers (not shown) of the system. See, eg, FIG. 15 and related description. The example system includes a vehicle controller 2302 on a first network zone 1904 and a first portion of the CND 1912 colocated with the vehicle controller 2302 that, when executed by the process of the vehicle controller 2302, communicates. and a portion including non-transitory computer readable instructions configured to perform at least a portion of the coordinating operations.

In certain embodiments, CND 1912 includes a portion colocated with a vehicle controller (not shown) that includes an Ethernet switch (e.g., 1914), in which case network zone 1908 includes an Ethernet network; communication between the endpoint of the network zone 1904 and another network zone 1904 is routed through an Ethernet switch 1914 (e.g., the CEG 1916 provides communication from the network zone 1904 through a port of the CES 1914), which along with the vehicle controller located within the housing and/or located on the same board as the vehicle controller.

In certain embodiments, CND 1912 includes a portion colocated with a vehicle controller (not shown) that includes a CEG (e.g., 1916), where network zone 1904 includes an Ethernet network and network zone 1904 includes a Communications between the endpoint 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 on the CES 1914), and the CEG 1916 is connected to the housing along with the vehicle controller. and/or on the same board as the vehicle controller.

The example system includes a second vehicle controller 2304 on a second network zone 1908, where the CND 1912 has a first portion colocated with a vehicle controller (not shown) and a second vehicle controller (not shown). A controller 2304 and a collocated second portion are included. Each of the first or second portions of CND 1912, when executed by the processing of the CES, CEG, and/or respective vehicle controller (e.g., vehicle controller and/or second vehicle controller 2304), One or more of the non-transitory computer readable instructions configured to perform at least a portion of the operations of coordinating communications between zones 1904, 1908 (and/or 2322, 2324) can be included. Each of the first portion or the second portion of the CND 1912 may be disposed within the housing of the respective vehicle controller and/or on the same substrate as the respective vehicle controller.

Certain aspects of the present disclosure are presented as procedures for carrying out operations related to the present disclosure. Actuation may be performed by any controller, circuit, device, component, sensor, actuator, logic circuit, or other aspects of the present disclosure, including but not limited to. Procedures are shown as embodiments, and acts may be omitted, combined, divided, and/or reordered in whole or in part. In certain embodiments, one or more acts of a first procedure can be combined with one or more acts of another procedure.

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

Referring to FIG. 25, encapsulating and/or processing communications from a first network for communication on a second network for mobile applications (e.g., communications between endpoints on separate network zones). A procedure 2500 is shown for doing so. The example methodology 2500 includes an act 2502 of receiving a first network communication (e.g., a communication provided by any endpoint on any network zone of a mobile application), non-payload frame information (e.g., a the data, identifiers, timestamps, and/or payload or any other communication information for the communication rather than the underlying data); Further, the example methodology 2500 processes, removes, or includes payload frame information from the communication (e.g., removes the payload if the communication is utilized for a reason other than the payload, such as in network monitoring operations; and/or changing payload units, resolution, bit depth, data type, etc.) and an act 2508 of encapsulating the communication for communication onto a second network of the mobile application. Further, the example methodology 2500 includes an act 2510 of providing the encapsulated communication as a second network communication for the mobile application. In certain embodiments, procedure 2500 may be performed between endpoints on separate networks that have incompatibilities (e.g., network protocols, message characteristics, network addressing, etc.) and/or otherwise incompatible data usage (e.g., , payload unit, data type, bit depth, etc.). In certain embodiments, the actuation of procedure 2500 provides encapsulation of a message from a first network (e.g., a CAN network) to a second network (e.g., an Ethernet network), and/or Messages may be tunneled from a first network having a network type to another network having a first network type by passing them through a relay network having a second network type.

Referring to FIG. 26, illustrated is a methodology 2600 for providing upsampled and/or downsampled communications from a networked endpoint of a mobile application. The example methodology 2600 includes an act 2602 of determining an upsampling scheme and/or a downsampling scheme for a communication (eg, from a first network). Without being limited to any other aspect of the present disclosure, example operations 2602 include requesting data rates for communications, data efficiency for communications with respect to the network and/or source endpoints, data storage values with respect to devices within the system. (e.g., communication buffer storage and/or long-term data storage location), and/or priority for communication (e.g., compared to competing communications, according to operating conditions for the mobile application, and/or flow, endpoint, vehicle determining an up-sampling scheme and/or a down-sampling scheme (according to associated priorities for features, etc.).

The example procedure 2600 includes, for example, processing payload information and/or non-payload information of a communication and providing the payload information and/or non-payload information (processed or unprocessed) toward a second network. (See, eg, FIG. 25 and procedure 2500).

The example methodology 2600 further includes an act 2604 of upsampling and/or downsampling the second network communication. Without being limited to the general concept that all acts for the procedures described herein can be reordered, split, omitted, and/or combined, acts 2500 and 2604 of procedure 2600 are: Iterative, simultaneous, and/or sequential may be performed in any order including each other because, in certain communications, upsampling operation 2604 and/or downsampling operation 2604 may obviate operation 2500. (e.g., excluding downsampled communications and/or excluding interpolated or non-interpolated communications) and/or act 2604 may include payload information about the communication that would otherwise be provided in act 2500 and/or It will be appreciated that non-payload information may be generated (eg, the addition of upsampled communications and/or the addition of interpolated or non-interpolated communications). Without being limited to any aspect of the present disclosure, act 2604 may include any act described with respect to FIGS. 17 and 18 and related description. The example methodology 2600 further includes an act 2606 of providing upsampled and/or downsampled communications to a second network. Although for purposes of clarity of this description, the acts for procedure 2600 have been enumerated with respect to providing communications from an endpoint on a first network to an endpoint on a second network, procedure 2600 may include data services (e.g., 27 and related discussion), communications passed to external devices, and/or communications for the same network range (e.g., from a first endpoint on a first network to a second network). It will be appreciated that it is applicable to any communication on a mobile application, including (to a second endpoint above).

Referring to FIG. 27, illustrated is an example apparatus 2700 for providing a service specification architecture for a mobile application with a mixed network environment. 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 network of vehicles 1904, 1908. For example, the vehicle data service definition circuit 2702 may receive a communication from the endpoint 1906, 1910 that provides an indicator that one or more data values are available for communication, and/or an indicator of data values available for communication. can be read from the configuration file 2718 (shown as storage in the example depicted in FIG. 27). Service availability description 2704 includes sensed values, actuator feedback values (e.g., position, status, fault values, etc.), parameters from any controller in the system, virtual sensor values, control parameters (e.g., set points, criteria, etc.). any type of data available on the vehicle, including points, determined situation values, reference error values, etc.) and/or stored values (e.g. accumulated parameters, snapshot information, calibrations, etc.) Can contain values. Service availability description 2704 can be associated with a single endpoint, a group of endpoints, a flow, or any other data provider or group of data providers within the system. Data associated with service availability description 2704 can be raw data values and/or processed versions of data values (eg, filtered low sampling rate, time-delayed data, etc.).

The example apparatus 2700 further includes a vehicle data service management circuit 2706 that publishes a data service availability value 2708 responsive to the service availability description 2704. In certain embodiments, data service availability value 2708 may include the same data provided by service availability description 2704 or a formatted version thereof. In certain embodiments, for example, the device providing the service availability description 2704 may be configured to publish all of the parameters on the list, to publish at the planned data rate, and/or to publish the displayed The data service availability value 2708 is corrected or adjusted in the service availability description 2704 when the data service availability value 2708 does not have full permission to publish at the sampling rate (e.g., determined from the configuration file 2718). version (eg, fewer parameters, lower data rate, lower resolution, etc. than those provided in service availability description 2704). In certain embodiments, the vehicle data service management circuit 2706 determines whether the exposing device (and/or endpoint, flow, etc.) has permission to provide the service exposed within the service availability description 2704. and accordingly does not provide the corresponding data service availability value 2708 to the service availability description 2704 . In certain embodiments, the vehicle data service management circuit 2706 determines that certain data service availability values 2708 are constrained only to certain regularly receiving devices such that unauthorized devices may not receive the corresponding data accordingly. including data service availability values 2708 (e.g., tags, encryption ) The example vehicle data service management circuit 2706 generates data service value descriptions 2709 responsive to periodic receipt requests 2710 of data service availability values 2708 and data values from endpoints 1906, 1910. For example, the data service value description 2709 describes parameters that are collected, grouped, and/or processed, and may further include an endpoint description, and the like. Data service value description 2709 provides collection parameters that CND 1912 can use to support services with active legitimate subscriptions, such as screening authorized data access and/or aggregation of redundant parameters. management of collection operations (for example, if more than one service is likely to provide the same data element as part of their etc.).

The example apparatus 2700 includes a CND 1912 that performs operations to coordinate communications between the vehicle's networks 1904, 1908. Although the example apparatus 2700 shows the circuits 2702, 2706 as co-located with the CND 1912 for purposes of illustration clarity, the components, circuits, communication flows, data elements, and/or other aspects shown in FIG. It will be appreciated that one or more of them can be distributed across multiple devices within the system. The example CND 1912 coordinates communication between the first network 1904 and the second network 1908, generates a data service value 2712 responsive to the data service value description 2709 and the data value from the endpoint, and generates the data service value Coordination circuit 2710 (e.g., may include and/or be in communication with a network operational component, such as a CES, CEG, or other operational component) that exposes data service values 2709 responsive to description 2712 including.

The example coordination circuit 2710 collects data directly from endpoints and allows, for example, broadcast (e.g., visible to all endpoints) and/or multicast (e.g., provided to subscribed endpoints) parameters. Publish according to network capacity, parameter importance, and/or breadth of use. In certain embodiments, the example coordination circuit 2710 provides the data service values 2712 to a service broker 2714 that manages communication of the data service values 2712 to subscribed endpoints or devices. The exemplary embodiment having a service broker 2714 may additionally or alternatively communicate data service availability values 2708 to endpoints or devices and/or receive periodic reception requests 2710 from devices. The service broker 2714 is used to do this. In certain embodiments, vehicle data service management circuit 2706 communicates with service broker 2714 to determine subscription requests 2710. In certain embodiments, vehicle data service management circuit 2706 receives periodic reception requests from endpoint devices on networks 1904, 1908.

The example apparatus 2700 includes a vehicle data service management circuit 2706 and/or a service broker 2714 that receives periodic reception requests 2710 from an external device, such as a service device 2716. In this example, vehicle data service management circuit 2706 determines a data service value description 2709 in response to a periodic reception request 2710 from an external device (this determination includes, for example, determining permissions, etc.) and The device receives parameters according to the regular reception service, as well as end points, devices, flows, etc. in the vehicle that receive regular reception.

In certain embodiments, the service availability description 2704 further includes an authorization description (e.g., when the endpoint and/or device that publishes the service availability applies the authorization level) and further includes a vehicle Data service management circuit 2706 limits publication of data service availability value 2708 and/or limits acceptance of corresponding subscription request 2710 in response to the authorization description. Additionally or alternatively, vehicle data service management circuit 2706 may determine authorization descriptions from configuration file 2718. The exemplary vehicle data service management circuit 2706 includes an endpoint identifier of the subscription requester, 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. , the user identifier of the periodic reception requester (e.g., the ID of the inspection and repair technician, the role of the person in charge regarding the requester's device, application, flow, etc.), and/or the entity identifier of the periodic reception requester (e.g., entity name, entity limit the publication of data service availability values (and/or in response to one or more of the following: role, manufacturer, OEM, service entity, owner entity, third party entity, etc.) (restrict acceptance of receive requests 2710).

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 may result from a failure or malfunction of an endpoint or device providing data for the service, a change in system authorization (and/or conditional authorization if authorization criteria are not currently met). ), and the service is listed in the configuration information 2718, but under certain operating conditions such as the absence of related endpoints, devices, applications, flows, etc. on the vehicle, expiration of permissions, etc. etc. can be given an indication that the public target service is unavailable. In yet another example, service availability value 2720 further includes an authorization description, in which case vehicle data service definition circuit 2702 limits updates to service availability description 2704 in response to the authorization description. The example vehicle data service management circuit 2706 includes 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 restricting updates to the service availability description in response to one or more of the entity identifiers of the service availability value provider. The example vehicle data service definition circuit 2702 receives service availability values 2720 from a data collection management device external to the vehicle, such as, but not limited to, a service device 2716. Accordingly, the apparatus 2700 includes updating configuration information, in-vehicle permissions, etc. by an external device utilized by, for example, a driver, an owner, a service entity, a manufacturing entity, a third party application, a fleet owner, etc. Enable us to provide and update our services.

Referring to FIG. 28, illustrated is an apparatus 2800 for encapsulating network communications to support roaming communications between mixed networks on a mobile application. The example apparatus 2800 includes a first network format 2806 (e.g., protocol, message parameters, start and/or end bits or information, payload format settings, message type, message confirmation protocol, and/or network layer). A first network interface circuit 2802 interprets a first network data set 2804 (e.g., a message from an endpoint on a first network 2805), determines a message value 2810 from the first network data set 2804, and determines a message value 2810 from the first network data set 2804; and a conversion circuit 2808 that encodes the message value 2810 into a second network data set 2812 having a network format 2814 of 2. As used herein, a message data set is to be understood broadly and includes a single message, a group of related messages, a group of messages that exist on a related network over a period of time, operating conditions, or the like. be able to. Message values as utilized herein include any selected message aspect including payload, frame, portion of frame, metadata, and the like.

The example apparatus 2800 further includes a second network interface circuit 2816 that transmits a second network data set 2812 (eg, as a message to a second network 2817). Apparatus 2800 includes a first network interface circuit 2802, a translation circuit 2808, and a second network interface circuit 2816 defined by either a single device or two devices, the first device and/or two It is possible to integrate the device into a vehicle. For example, a CND can include all of a first network interface circuit 2802, a translation circuit 2808, and a second network interface circuit 2816. In another example, the CEG can include a first network interface circuit 2802 and a translation circuit 2808 and the CES can include a second network interface circuit 2816. In another example, the CEG can include a first network interface circuit 2802 and the CES can include a conversion circuit 2808 and a second network interface circuit 2816. In another example, a CEG can include all of a first network interface circuit 2802, a translation circuit 2808, and a second network interface circuit 2816.

In the example depicted in FIG. 28, first network format 2806 is distinctly different from second network format 2814 in at least one aspect. The example device 2800 includes one of the first network format 2806 or the second network format 2814 as a CAN network. The example apparatus 2800 includes a first network format 2806 as a CAN network and a second network format 2814 as an Ethernet network.

The example apparatus 2800 further includes a configuration circuit 2818 that modifies the first network interface circuit 2802, the translation circuit 2808, and/or the second network interface 2816 in response to the configuration command value 2820. Exemplary and non-limiting configuration command values 2820 include which messages of the first network data set 2804 are to be communicated to the second network, and which updates are to be performed on the messages of the first network data set 2804. sampling operations and/or downsampling operations to determine message values 2810 (e.g., which aspects of the message, such as payload, frame portions, metadata, are considered message values 2810) and/or to determine message values 2810; conversion parameters (e.g., encapsulation operations, source and/or destination identification, unit conversion, etc.) and/or network adjustment operations (e.g., see FIG. 19 and related discussion) into the network data set 2812 of including one or more of the following. Exemplary configuration circuit 2818 is defined by a first device, such as a CND, CEG, and/or CES, or by a second device (optionally and if present). In certain embodiments, the configuration circuit 2818 determines 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 is connected to the first device. and/or further selectively configure the configuration defined by the second device (e.g., configuration circuitry 2818 may repurpose a device such as a CEG or CES, and/or system changes, topology (enables coordination of operation between devices to shift network operation and/or coordination functions in response to changes and/or abnormal operating conditions). In certain embodiments, configuration circuitry 2818 receives configuration command values 2820 from a CND, from an external device, and/or by accessing a configuration file.

Referring to FIG. 29, illustrated is an apparatus 2900 for mirroring ports on a mobile application to provide communications from a first network to a second network. The example device 2900 includes a first network interface circuit 2802 having a number of ports 2902 and interpreting first communication data 2904 of a first network 2805 onboard a vehicle. Port 2902 can be a physical port, a logical port, and/or a combination 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 vs. an Ethernet network, a distinctly different network format 2806, 2814, and/or a network with any other type of difference understood in the art). Apparatus 2900 transfers 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., the transfer The second communication data 2906 may further include a conversion circuit 2808 (which may include processing, encapsulating, and/or otherwise configuring the second communication data 2906 for communication over the first network 2805). Exemplary first network interface circuit 2802 mirrors a first port of ports 2902 to a second port of ports 2902, such as an external device 2908, a data collection operation (not shown), and/or a vehicle. allowing other devices within the device to observe and/or obtain data from the second port, thereby receiving the same data communicated at the first port. Without being limited to any other aspect of the present disclosure, port mirroring operation enables network monitoring operation, data collection of any parameter from any endpoint of the network within the vehicle ( without requiring the requesting device's knowledge of the location of the distributed endpoint, e.g., network configuration, communication protocols, and/or vehicles).

The example device 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. Accordingly, the configuration circuit 2818 may include all of the communication values and/or the second communication data 2906, which may include any selected endpoint on the first network 2805 (e.g., if the conversion circuit 2808 If the second communication data 2906 is transferred to one of the ports 2902, the communication value can be provided from any of the ports 2902 to a selected mirror port. In certain embodiments, configuration circuit 2818 receives port selection command values 2820 from a 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 permissions to provide the port selection command value 2820.

The example configuration circuit 2818 identifies the assigned port and the device (e.g., endpoint, controller, flow, application, etc.) on the second network 2817 and corresponds to the device identified in the second communication data 2906. interpret a port assignment command value 2820 that identifies a portion of the second communications data 2906 to be directed to the assigned port (and/or transmit the identified portion of the second communications data 2906 to the assigned port); interface circuit 2802). In certain further embodiments, devices on second network 2817 may additionally or alternatively correspond to devices identified on other networks (e.g., first network 2805). configuration circuitry 2818 and the first network (e.g., when an application, flow, or other device on the second network 2817 includes a manner in which it operates on the other network). Operation of the interface circuit 2802 further supports providing associated communication data from all associated networks to the assigned port.

Referring to FIG. 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 the vehicle and a second communication data 2817 of a second network 2817 onboard the vehicle. and a second network interface circuit 2816 that interprets the data 2906. The second network 2817 is of a different type than the first network 2805 (e.g., a CAN network versus an Ethernet network, a distinctly different network format 2806, 2814, and/or a network with any other type of difference understood in the art). The example apparatus 3000 selectively directs the first communication data 2904 to the second network interface circuit 2816 for transmission over the second network 2817 and/or to the first network 2805 for transmission over the first network 2805. and a conversion circuit 2808 that selectively transfers the second communication data 2906 to the first network interface circuit 2802. The example conversion circuit 2808 further configures the messages from each network into other networks, eg, processes, encapsulates, and/or otherwise configures the messages, and then forwards the messages. The example apparatus 3000 further includes a regulation circuit 3002 that regulates the second network interface circuit 2816, the first network interface circuit 2802, and/or the conversion circuit 2808, which regulation is described in FIG. 19 and the related description. The method may include performing any one or more operations such as, but not limited to, adjusting operations. The example conditioning circuit 3002 adjusts 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. Constrain. The example regulating circuit 3002 may limit data rates (e.g., amount of data per unit of time and/or amount of data over a period of time), saturation rates (e.g., utilization of available bandwidth, etc.), limiting the amount of data based on storage capacity, capabilities of the receiving device (e.g., endpoint on one of the networks), and/or Constrain the amount of communication data by limiting the amount of data based on the requested data rate.

The example conditioning circuit 3002 constrains transmission of one or more portions of the first communication data 2904 and/or the second communication data 2906, e.g., corresponding to a selected endpoint, flow, application, and /or constrain the transmission of data according to vehicle operating conditions, network and/or endpoint abnormal conditions, etc. In certain embodiments, a combination of these constraints may specify, for example, that transmissions to or from certain endpoints are constrained, and/or that transmissions for certain data flows are constrained. May be present if vehicle operating conditions indicate. Constraint actuation may include, but is not limited to any other aspect of the present disclosure, limiting communication, limiting communication speed, suppressing communication (at least for a period of time, and/or (during certain operating conditions); performing downsampling on certain messages (e.g., reducing messaging traffic); and/or performing upsampling on certain messages (during certain operating conditions); For example, this step can shift the operational load between components, a step that reduces the load on some components, such as by utilizing upsampling to reduce the actual data sampling rate, encapsulation generating a message configured to reduce the load on the computer, and the like. In certain embodiments, the constraint operation of the coordination circuit 3002 includes considering priority information associated with the message, endpoint, flow, network, etc., and/or the first communication data 2904 to be transferred and/or The method includes prioritizing a portion of the second communication data 2906.

Referring to FIG. 31, an apparatus that supports 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 a vehicle and a second communication data 2904 of a second network 2817 onboard a vehicle. and a second network interface circuit 2816 that interprets the data 2906. The second network 2817 is of a different type than the first network 2805 (e.g., a CAN network versus an Ethernet network, a distinctly different network format 2806, 2814, and/or a network with any other type of difference 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. Although the example depicted in FIG. 31 shows network status circuit 3102 communicating with port 2902 of first network interface circuit 2802 to collect network status data 3106, network status circuit 3102 is connected to other network interface circuits in the system. The conversion circuit 2808 can collect network status data 3106 from the second network interface circuit 2816 and/or can collect network status data 3106 as data stored on memory storage of the device 3100. It will be appreciated that 3106 is accessible.

The example apparatus 3100 is configured to mirror at least one of the ports 2902 over at least another of the ports 2902, for example, to provide network status data 3106 to a selected port 3902 of the first network interface circuit 2802. It further includes configuration circuitry 2818 configured to. The example configuration circuit 2818 identifies the selected port (e.g., to provide network status data 3106) and further identifies a portion of the first communication data 2904 and/or the second communication data 2906 (e.g., to provide network status data 3106). port assignment commands that direct (and/or direct the first network interface circuit 2802) to communicate the identified portion of the communication to the selected port (based on the monitored device, network, endpoint, flow, etc.); Interpret value 3104. The example apparatus 3100 includes configuration circuitry 2818 that modifies network status data 3106 in response to, for example, selected devices, endpoints, flows, applications, controllers, networks, systems, etc. of the vehicle. The example device 3100 provides network status data in response to data selection command values 3108 (e.g., provided by network status circuit 3102, a CND, an external device, a configuration file, and/or other controllers or components of the system). 3106 to include a configuration circuit 2818 that adjusts the data provided to the selected port (or otherwise to the network status circuit 3102) in response to the data selection command value 3108. In certain embodiments, data selection command values 3108 may additionally or alternatively include one or more protocols (e.g., data collection rate, time value and/or time range, selected processing, Identifies selected parts of the message frame, metadata, protocol type (eg, TCP, UDP, AVB, etc.). The example apparatus 3100 depicts, in a non-limiting example, circuits 2802, 2808, 2816, 2818 disposed within the same housing 3110 and a network status circuit 3102 (e.g., an external device) separated from the housing 3110. There is. The example device 3100 may include circuits 2802, 2808, 2816, 2818 and/or subgroups of these circuits located on the same circuit board.

Still referring to FIG. 31, the exemplary first network 2805 is an Ethernet network and the exemplary second network 2817 is a CAN network. In this example, conversion circuit 2808 is inserted between first network interface circuit 2802 and second network interface circuit 2816 to convert Ethernet communication data to CAN communication data and/or convert CAN communication data to Ethernet communication data. Convert to 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, the network status data 3106 includes messages having addresses that support the same device, the same application, and/or the same flow within the bandwidth, Ethernet communication data, and/or CAN communication data passing through the translation circuit 2808. and/or the number of communication errors (e.g., packet loss, delay events, bad checksums, bad data, handshake or acknowledgment failures, etc.). .

Referring to FIGS. 32-34, for purposes of illustration, example arrangements of apparatus for coordinating communications between networks on a mobile application are shown.

Referring to FIG. 32, the exemplary arrangement includes a first network interface circuit 2802 in communication with a CAN network 3202, a translation circuit 2808 that passes selection messages between ports of the CAN network 3202 and a second network interface circuit 2816, and (e.g., a configurable edge gateway and/or a CAN gateway). The exemplary arrangement includes a CES 3208 that includes a second network interface circuit 2816 in communication with the 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 the CND recited throughout this disclosure and/or operate to coordinate communications between networks 3202, 3204 in response to CND commands. may be implemented, in which case the CND is distributed elsewhere within the system.

Referring to FIG. 33, all or a portion of the CNDs listed throughout this disclosure may form and/or perform operations to coordinate communications between networks 3202, 3204 in response to CND commands. An example arrangement is shown in which the CND can be distributed elsewhere in the system. The example depicted in FIG. 33 is distinctly different from the example depicted in FIG. 32 in that a translation circuit 2808 is co-located with the CES 3208 and receives CAN messages directly from the first network interface circuit 2802.

Referring to FIG. 34, all or a portion of the CNDs listed throughout this disclosure may form and/or perform operations to coordinate communications between networks 3202, 3204 in response to CND commands. An example arrangement is shown in which the CND can be distributed elsewhere in the system. The example depicted in FIG. 34 is distinctly different from the example depicted in FIG. 33, in which configuration circuitry 2818 is distributed between CES 3208 and CEG 3206. In the example depicted in FIG. 34, one of the configuration circuits 2818 may be the master and passes configuration information to the other of the configuration circuits 2818. In certain embodiments, each configuration circuit 2818 can operate independently and receives configuration information from a configuration file, such as through communication with a CND. The examples set forth in FIGS. 32-34 are non-limiting illustrations to depict certain aspects and arrangements of the present disclosure.

Referring to FIG. 35, an example methodology 3500 for providing a service specification architecture for a vehicle with a mixed network is shown. The example procedure 3500 includes an act 3502 of interpreting a service availability description including an availability data value from a first endpoint device on one of a first network or a second network of the vehicle; an act 3504 of publishing a data service availability value responsive to the data service availability value; an act 3506 of generating a data service value description responsive to the periodic reception request for the data service availability value; and data from the first endpoint device. An act 3508 of generating a data service value responsive to the service value description and the data value and an act 3510 of publishing a data service value responsive to the data service value description are included. An example act of publishing 3510 a data service value includes providing the data service value to a second endpoint device, eg, an endpoint device on a different network than the first endpoint device. The example operations 3510 publish data service values by providing network communications that include the generated data service values to a plurality of subscriber endpoint devices, each on one of the first network or the second network. Further comprising steps. Exemplary data service availability values include a name for the service, a list of data parameters provided by the service, a list of availability instructions provided by the service, etc. (e.g., from providing the device to the CND). , the data service value description includes a name for the service, a list of data parameters provided by the service, a list of available instructions provided by the service, etc. (e.g., from a CND to a potential subscriber device), in this case. In addition, data service value descriptions can collate data service availability values or can be configured differently (eg, simplified, expanded, standardized, etc.) from data service availability values. Exemplary data service values include data values that correspond to data service availability values.

In certain embodiments, the methodology 3500 further includes an act 3512 of receiving a subscription request from an endpoint device on both the first network and the second network. The example act 3512 includes receiving a subscription request from a device external to the vehicle, such as a service device, a web application, a cloud-based application, and/or a third party application, in which case the act 3508 and/or 3510 are performed in response to act 3512 (eg, generate a data service value and/or publish a data service value only if the subscribed receiving device is available for service). The example procedure 3500 includes a service availability description that further includes an authorization description, in which case the act 3504 includes restricting publication of data service availability values in response to the authorization description (e.g., In this case, unauthorized devices cannot see the data service). The example act 3504 enables data services in response to an identifier of a subscription requestor (e.g., an endpoint, a flow, a vehicle function, an application, a set of services, and/or an entity associated with any of the foregoing). including the step of restricting the publication of degree values.

The example procedure 3500 includes a service availability description that further includes an authorization description, in which case the act 3510 includes restricting publication of data service values in response to the authorization description (e.g., periodic reception). The example operations 3510 may receive data service values in response to an identifier of a subscription requestor (e.g., an endpoint, a flow, a vehicle function, an application, a set of services, and/or an entity associated with any of the foregoing). Including steps to restrict publication.

The example operations 3502 include interpreting the service availability value and updating a service availability description in response to the service availability value. For example, service availability values can be updated by provider devices (e.g., endpoints, flows, vehicle features, applications, service suites, external devices, etc.) and/or add services to the available services, and and/or may be updated by a policy change that removes the service from the available services. The example operations 3502 enable service availability in response to an authorization description (e.g., verify authorization of an update execution device before updating a service availability description) and/or in response to an identifier of an update execution device. The method further includes restricting updates to the gender description.

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

The 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 a message value, and/or encapsulating a message frame. It may include the step of partially or fully processing. The example operations 3606 include including an encapsulation scheme for the message, including an address description for the message (e.g., converting the address according to the target device receiving the data on a separate network), and/or a sampling rate. (e.g., performing upsampling and/or downsampling on the first network data set).

Referring to FIG. 37, an example methodology 3700 for configuring a CND for monitoring a network of vehicles with a mixed network is shown. The example procedure 3700 includes an act 3702 of interpreting first communication data of a first network onboard the vehicle and a second communication data of a second network onboard the vehicle of a different type than the first network. an act 3704 of interpreting the communication data; an act 3706 of generating network status data by monitoring the first and second communication data; and transmitting the network status data (e.g., storing the data, transmitting the data externally). communicating with a device, service tool, cloud server, etc.) act 3708. The example methodology 3700 further includes an act 3710 of configuring the 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); In this case, the first port provides the first communication data, e.g., provides the first communication data as a message available on the second network, and/or the first port provides the first communication data as a message available on the second network; Provided as a monitor port regarding communication data of 1. The example act 3710 identifies a selected port with a port assignment value (e.g., determined from a policy, a configuration file and/or according to request data and a provider endpoint thereto, and/or supports a service tool, monitor device, etc.). in which the act 3704 supports the identified device (e.g., monitored endpoint, port, flow, etc.) in the second communication data. Including identifying the portion, act 3708 includes transmitting the identified portion of the second communication data through the selected port.

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

Referring to FIG. 38, a procedure 3800 for mirroring ports using CND for a vehicle with a mixed network is shown. The example procedure 3800 includes an act 3802 of interpreting first communication data of a first network at a number of ports of a CND and an act of interpreting a second communication data of a second network (of a different type). 3804 , an act 3806 of transferring the second communication data to the first network (e.g., from CEG to CES) using at least one of the several ports; and an act 3808 of mirroring the second of the two. Further, the example procedure 3800 includes an act 3810 of interpreting a port selection command value (e.g., a receiving port and/or a sending port for mirrored target communication data) and selecting a first of the ports in response to the port selection command value. and/or an act 3812 of allocating the first and/or second. The example act 3810 identifies the allocated port and includes a port allocation command value that identifies the device on the second network, in which case acts 3806 and/or 3808 identify the allocated port and identify the device on the second network. transmitting the assigned portion through the assigned port (e.g., to a second network and/or a mirror port).

Referring to FIG. 39, an example methodology 3900 including CND for a vehicle with a mixed network is shown. The example procedure 3900 includes an act 3902 of interpreting a first network data set having a first network format by a first interface circuit of a centralized network device (CND); an operation 3904 of determining a message value from the first network data set by a conversion circuit of the CND in response to the conversion circuit into a second network data set having a second network format different from the first network format; and an act 3908 of transmitting a second network data set by a second interface circuit of the CND. Additionally, the example methodology 3900 includes an act 3910 of interpreting the configuration command value and an act 3912 of modifying the CND in response to the configuration command value.

Exemplary operations 3912 include interpreting the configuration command value and modifying the CND in response to the configuration command value. Exemplary acts of modifying the CND include determining which of the one or more portions of the first interface circuit, the conversion circuit, and/or the second interface circuit is at least partially connected to the first device and/or the second interface circuit. (e.g., shifting translation and/or interface burdens between various network interface circuits and/or between CEG and/or CES). Exemplary operations 3912 include generating configuration command values external to the vehicle (e.g., from an external device and/or via a policy update) and transmitting the configuration command values toward the vehicle (and/or CND). including.

Referring to FIG. 40, an example methodology 4000 is shown that includes operations that perform test operations, diagnostic operations, and/or vehicle control operations and include a CND to perform these operations. The example procedure 4000 may be performed in addition to the operations for procedure 3900 and/or in whole or in part separately. The example procedure 4000 includes an act 4002 of generating a test command value external to the vehicle, an act 4004 of transmitting the test command value towards a CND, and a device (e.g., one of the first or second device of the procedure 3900). , and/or a third device on the first or second network). Additionally or alternatively, the example procedure 4000 may be performed using diagnostic command values, active assistance command values, and/or vehicle control values (e.g., directing actuators, vehicle functions, etc.). I can do it. In certain embodiments, procedure 4000 remotely configures and/or tests a CND without requiring knowledge of the network topology, endpoint locations, and/or endpoint local addresses of devices on the vehicle from an external device. , provide remote activation of diagnostics, vehicle control functions, etc.

Referring to FIG. 41, an example methodology 4100 for coordinating a network of vehicles with a mixed network is shown. The example procedure 4100 includes an act 4102 of interpreting first communication data of a first network of a vehicle, an act 4104 of interpreting second communication data of a second network of a vehicle, and an act 4104 of interpreting first communication data of a first network of a vehicle. An act of forwarding 4106 to the second network (and/or the second communication data to the first network) and an act of coordinating 4108 the second network are included. The example act 4108 includes constraining the transfer of the first communication data (e.g., limiting the rate, disabling and/or suspending the communication, and/or the device that may send and/or receive the transfer data). (e.g., the step of constraining the The example operations 4108 include determining the saturation rate of the first network and/or the second network in response to the amount of data per unit time, per operational event (e.g., per trip, during certain operating conditions, etc.); and/or implemented based on 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 may include first communicating data and/or according to any prioritization operations and/or groupings (e.g., endpoints, flows, applications, vehicle functions, service groups, etc.) listed throughout this disclosure. or prioritizing a portion of the second communication data for transfer. Exemplary operations 4108 include upsampling, downsampling, encapsulating, and/or processing the transferred message and/or portions thereof (eg, payload, selected message, frame portions, metadata, etc.).

Referring to FIG. 42, an example methodology 4200 for coordinating inter-network communications for a vehicle with mixed networks is shown. The example procedure 4200 includes an act 4202 of interpreting first communication data of a first network onboard the vehicle, an act 4204 of interpreting second communication data of a second network onboard the vehicle. an act of forwarding 4206 the first communication data to the second network (and/or the second communication data to the first network); and coordinating the transfer of the first communication data and/or the second communication data. 4208 . The operations 4208 can coordinate the operations described throughout this disclosure and include the first network, the second network, a transfer device (e.g., CEG, CES, and/or network interface circuitry), memory storage ( e.g. buffer memory and/or short-term memory storage for network communications), including these characteristics, the operating conditions of these and/or the vehicle, and/or any abnormal conditions that exist with respect to these and/or the vehicle. It can be implemented by

Referring to FIG. 43, an example methodology 4300 for supporting CAN status determination using an Ethernet-based monitor is shown. The example procedure 4300 includes an act 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 a vehicle, a conversion circuit. An act of determining a message value from an Ethernet data set 4304 using (e.g., on an Ethernet switch, a CAN gateway, and/or a CEG), encoding the message from the Ethernet-based data set into a message for the CAN-based data set. 4306 . Having described acts 4304, 4306 of proceeding from an Ethernet-based data set to a CAN-based data set, the acts may additionally or alternatively proceed from a CAN-based data set to an Ethernet-based data set. be able to. The example procedure 4300 includes transmitting a CAN data set (e.g., thereby transmitting an Ethernet message to a CAN-based device and/or transmitting a CAN message to an Ethernet device) using a second interface circuit act 4308 further including. Further, the example procedure 4300 includes an act 4310 of interpreting the configuration command value and modifying the conversion circuitry in response to the configuration command value (e.g., message processing, addressing, encapsulation characteristics, upsampling values, downsampling values). , maximum data rate, etc.). Example operations 4310 include receiving configuration command values (eg, as a request, message, policy update, etc.) from an external device. Exemplary operations 4312 include providing configuration commands to an Ethernet switch, CEG, configurable CAN gateway, etc. The example methodology 4300 can 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. Ru. Exemplary operations may utilize any endpoints of a vehicle, vehicle functions, applications, flows, services, etc. Exemplary operations include systems and/or related components such as a vehicle prime mover, a vehicle engine, a vehicle drivetrain, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and/or a vehicle electrical system. can be used.

Referring to FIG. 44, an example methodology 4400 for providing Ethernet monitoring on a vehicle with a mixed network is shown. The example procedure 4400 includes an act 4402 of converting Ethernet communication data to CAN communication data, an act 4404 of converting the CAN communication data to Ethernet communication data, and monitoring the converted CAN communication data and the Ethernet communication data. and an act 4406 of generating status data. Further, the procedure 4400 can be performed on a network by, for example, storing the data, communicating the data to an external device, and/or directing the data to a service tool, a web application, a cloud server, a third party application, etc. An act 4408 of transmitting status data is included.

The example methodology 4400 further includes an act of configuring 4410 the first Ethernet port to interpret the first Ethernet data, and an act of mirroring 4412 the first Ethernet port's communications to the second Ethernet port. In certain embodiments, the first Ethernet port can be a port that provides CAN communication data (eg, from operation 4404) to an Ethernet network. In certain embodiments, act 4408 of transmitting network status data includes act 4412 of mirroring communications of the first Ethernet port to the second Ethernet port. Additionally or alternatively, act 4406 of generating network status data is performed on at least a portion of the data provided in act 4412, and act 4406 of generating network status data is performed within a vehicle, It can be implemented using the following methods and/or combinations thereof.

Referring to FIG. 45, an example procedure 4500 for operating a mixed network system on a vehicle is shown. The example procedure 4500 includes an act 4502 of generating a message value by a first vehicle control device on a first network located within the vehicle and a second vehicle control device on a second network located within the vehicle. an act of transmitting 4504 the message value to the second vehicle control device; and a control action on the vehicle (e.g., moving a sensor and/or actuator, and/or at the second vehicle control device in response to receiving the message value). or collecting specified data). Exemplary and non-limiting vehicle control devices include any sensors, actuators, and/or controllers mounted on a vehicle. Exemplary and non-limiting vehicle control devices include systems such as a vehicle prime mover, a vehicle engine, a vehicle drivetrain, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and/or a vehicle electrical system. and/or related components. In certain embodiments, the first vehicle control device and/or the second vehicle control device are capable of effecting, in whole or in part, the operation of the other one or more of the vehicle control devices. be able to. In certain embodiments, operation 4502 includes generating a message instructing one of the vehicle control devices to take over, in whole or in part, operation of one or more of the other vehicle control devices. . In certain embodiments, these vehicle control devices are located on multiple networks of different types. In certain embodiments, procedure 4500 includes an act 4508 of providing data previously communicated to one of the vehicle control devices to another of the vehicle control devices. Actuation 4508 may be in addition to a previous communication (e.g., both vehicle control devices receive this data) and/or as a replacement for a previous communication (e.g., due to a previous communication failure and/or actuation 4508 (in response to stopping a previous communication when initiated). In certain embodiments, the actuation 4508 is alternative data (e.g., data for a different possible actuation of the replacement control device, even though the replacement control device is, in whole or in part, a substitute for the original control device). data), 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 than the previous communication (e.g., a different resolution, communication speed, units, etc.). In certain embodiments, the actuation 4508 that includes vehicle controller substitution and/or communication changes is in response to a request from a control device (e.g., a separate data request is sent from the control device in response to the actuation change). and/or according to configuration files and/or policies.

The example procedure 4500 includes transmitting message values over one or more intermediate networks (e.g., tunneling from a CAN network on a first network zone through an Ethernet network on a second network zone to a third network). CAN network on the zone) operation 4504. In certain embodiments, the intermediate network may be a distinct type of network compared to the first network and/or the second network. Exemplary and non-limiting operations 4506 include one or more of: obtaining data from a component of the vehicle, activating a component of the vehicle, and/or controlling another vehicle control device. including. The example operations 4506 may utilize any endpoint of the vehicle, vehicle functionality, application, flow, service set, etc. Exemplary operations 4506 include systems and/or related components such as a vehicle prime mover, a vehicle engine, a vehicle drivetrain, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and/or a vehicle electrical system. elements can be used. 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.

Referring to FIG. 46, an example procedure 4600 for operating a mixed network system on a vehicle is shown. The example methodology 4600 includes an act 4602 of generating a message value by a first vehicle control device on a first network of the vehicle and transmitting the message value (and/or or a processed and/or encapsulated version of the message value) over the second network; and an act of interpreting the message value 4606 by an external device. The example procedure 4600 includes testing a first vehicle control device with an external device and/or configuring the first vehicle control device with an external device (e.g., providing a direct command or request, updating a policy). and/or update the configuration file) 4608. The example methodology 4600 includes an act 4609 of configuring a second vehicle control device on a second network with an external device, which may be responsive to acts 4604, 4606, and/or 4608.

Example operations 4604 convert (e.g., CND, CEG, CES and/or network interface circuitry). Exemplary operations 4608 include including the CND (and/or CEG, CES, and/or network interface circuitry) with an external device. The example methodology 4600 may additionally or alternatively include transmitting one or more message values over an intermediate network inserted between a first network and a second network (e.g., , FIG. 4, FIG. 23, FIG. 45, and related description).

The example methodology 4600 includes an act 4610 of generating an external message value by an external device and an act 4612 of transmitting the external message value towards a first network. The operations 4612 include determining a vehicle control device (e.g., a first vehicle control device) and/or e.g. The method may further include interpreting the external message (by another vehicle control device) to perform update actions, etc. to the policy. Exemplary operations 4612 may utilize any endpoint of a vehicle, vehicle functionality, vehicle controller, application, flow, service set, etc. Exemplary operations 4612 include systems and/or related components such as a vehicle prime mover, a vehicle engine, a vehicle drivetrain, a vehicle transmission, a vehicle braking system, a vehicle fuel system, and/or a vehicle electrical system. elements can be used. Exemplary operations 4612 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.

Referring to FIG. 47, an exemplary 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 inserted between a first network zone 5612 and a second network zone 5614. A CND 108 inserted between network zones 5612, 5614 may require physical intervention (e.g., CEG, CES, or other network interface circuitry by which communication between network zones 5612, 5614 is controlled by CND 108 and/or ) and/or logical intervention (e.g., if communication between network zones 5612, 5614 passes through a device controlled by CND 108, and/or CND 108 5614 (e.g., to coordinate passing data values, composition of data values, data rate, upsampling and/or downsampling of data, encapsulation operations, frame inclusion, and/or processing of passing communications) including.

The example system 4700 includes a policy manager circuit 5602 that interprets a policy 5606 that includes an active diagnostic description 4705 and provides diagnostic command values 4712 responsive to the active diagnostic description 4705 to the endpoints of network zones 5612, 5614. The diagnostic execution circuit 4702 is further included. The example system 4700 includes a first network zone 5612 endpoint (endpoint 4708) and a second network zone 5614 endpoint (endpoint 4710). In example system 4700, endpoints 4708, 4710 include devices responsive to diagnostic command values 4712. Exemplary and non-limiting diagnostic command values 4712 include commands to collect one or more data values, commands to operate actuators, and/or commands to operate vehicle functions (e.g., engine speed, power level or perform higher level functions, e.g., regenerative mode, planned test operations, etc.). The example system 4700 is configured to perform active diagnostic testing when endpoints move between networks and/or to perform active diagnostic testing across different vehicles having different network configurations and different distributions of endpoints 4708, 4710. Enables active diagnostic test runs requested by external devices to be successfully performed despite the distribution of endpoints 4708, 4710 across multiple networks of the vehicle, including where command values 4712 are utilized. .

Referring to FIG. 48, example endpoint 4708 includes device control circuitry 4802 that interprets diagnostic command values 4712 and provides actuator command values 4804 in response to diagnostic command values 4712. Exemplary endpoints 4708 include or are connected to actuators 4806 that are responsive to actuator command values 4804 . For example, diagnostic command values 4712 may include commands such as "lock driver's door," "close exhaust gas recirculation valve," and "increase motor temperature to 80 degrees Celsius." Abstraction between the responses of actuator 4806 allows diagnostic command values 4712 to be obtained. Additionally or alternatively, the diagnostic command value 4712 can be associated with a complex or continuous operation, such as a complete test sequence, and thus can be associated with many endpoints 4708, 4710, and /or multiple actuators 4806 across system 4700 may be implied by a single diagnostic command value 4712.

The example system 4700 further includes diagnostic execution circuitry 4702 that determines whether vehicle operating conditions 4720 are consistent with diagnostic command values 4712 prior to providing diagnostic command values 4712 to endpoints 4708, 4710. For example, the diagnostic command value 4712 can include a diagnostic test that adjusts the torque delivery of the vehicle's prime mover, and the associated vehicle operating conditions 4720 include ensuring that the vehicle's gear is in neutral, the vehicle is in the prime mover mode, etc. Parameters such as ensuring that the vehicle is not in the selected test mode and/or ensuring that the vehicle is in the selected test mode may be included. In certain embodiments, vehicle operating conditions 4720 for a given diagnostic command value 4712 may be indicated within the active diagnostic description 4705, and vehicle operating conditions 4720 for performance of the test (e.g., target temperature, specific conditions (e.g., vehicle launch, high-altitude operation, etc.), and/or non-test considerations (e.g., driver or service personnel safety, fuel economy, or emissions, impact on network communication speeds, processing requirements). , and/or memory storage). In certain embodiments, vehicle operating conditions 4720 for a given diagnostic command value 4712 may be enforced by another flow, application, vehicle function, etc. on the vehicle (e.g., a torque command may be (e.g., cannot be adjusted separately from driver commands unless present). The example system 4700 includes a policy 5606 that includes a diagnostic performance condition 4706 , where the diagnostic performance circuit 4702 is responsive to the diagnostic performance condition 4706 to determine whether vehicle operating conditions 4720 match diagnostic command values 4712 . Further decisions will be made.

The example system 4700 includes diagnostic execution circuitry 4702 that further performs diagnostic data collection operations in response to active diagnostic descriptions 4705 and stores diagnostic data sets 4714 responsive to the diagnostic data collection operations. For example, the active diagnostic description 4705 can include a number of data parameters to be collected, vehicle condition conditions to be monitored, and/or parameter thresholds to be determined (eg, temperature greater than the threshold). Stored target diagnostic data set 4714 may include collected data, vehicle condition conditions determined based thereon, or a combination thereof. The collected data may be from endpoints 4708, 4710 that are responsive to diagnostic command values 4712 (e.g., confirmation that the actuator has responded to the command, diagnostic data or fault codes for the responding actuator, etc.) or other than in response to the command. endpoints 4708, 4710 (e.g., observation of temperature, pressure, velocity values, status checks, etc. not directly related to operational endpoints 4708, 4710).

Exemplary diagnostic execution circuitry 4702 performs processing operations on the collected data during diagnostic data collection operations and stores diagnostic data sets 4714 responsive to the processing operations. For example, the stored target diagnostic data set 4714 may include state information, virtual sensor information, bad information (e.g., only storing data related to operation when a threshold is not met), upsampling and/or downsampling the collected data. It may include sampled values and/or any other processing operations listed throughout this disclosure. Exemplary and non-limiting processing operations on the collected data or portions thereof include compressing the collected data, summarizing the collected data, utilizing the collected data to actuate a virtual sensor, and responding to the collected data. determining vehicle operating conditions; determining a diagnostic data set in response to determining vehicle operating parameters; performing an upsampling operation on the collected data; and/or performing a downsampling operation on the collected data. including the steps of implementation.

The example diagnostic execution circuit 4702 further communicates the diagnostic data set 4714 in response to the diagnostic data collection operation to an external device (eg, 5618). The external device that receives diagnostic data set 4714 can be the same or different external device that provides active diagnostic description 4705. The example diagnostic execution circuit 4702 further processes the collected data prior to communicating to an external device, including initial processing to determine a storage target diagnostic data set 4714 and/or a storage target prior to communicating to an external device. Further processing operations on diagnostic data set 4714 may be included. For example, the diagnostic execution circuit 4702 can store a diagnostic data set 4714 and send a portion of the diagnostic data set 4714 (eg, selected parameters, active diagnostic results, etc.) to an external device. The example diagnostic execution circuit 4702 then further processes the diagnostic data set 4714 before communicating it to an external device (e.g., reducing external data communication in response to the data being selected for transmission by the external device). performing selected operations, such as steps) and/or communicating the diagnostic data set 4714 to an external device (e.g., due to the availability of external communications such as a WiFi connection, a connected external device, etc.) in response and/or upon request from the external device for all of the diagnostic data set 4714), and/or communicating further selected portions of the diagnostic data set 4714 (e.g., data requested by the external device). and/or retain the diagnostic data set 4714 and/or a further processed form of the diagnostic data set 4714 stored for a selected period of time, and/or delete the diagnostic data set 4714 after a diagnostic execution operation (e.g., according to the results of active diagnostic tests and/or according to the requirements of external devices). Operation of system 4700 involves active diagnostic activation by external devices (e.g., service tools, service applications, cloud-based applications, fleet service computing devices, and/or third party applications) that engage endpoints on a vehicle over a mixed network. diagnostic operations that do not require knowledge of endpoint locations and/or configurations on the vehicle, can support multiple configurations of the vehicle, and/or can support configuration changes of the vehicle. can be seen providing. In addition or in the alternative, operation of the system 4700 provides planned data transmission that includes transmission data reduction while obtaining strong active diagnostic capabilities; while enabling planned consumption of on-vehicle processing, memory, and inter-network communication resources.

The example system 4700 determines a diagnostic confirmation value 4716 based on the actuator's response to the diagnostic command value 4712 (e.g., whether the actuator performed a commanded function and/or whether the vehicle is active across the group of actuators). The diagnosis verification circuit 4704 (which checks whether active diagnosis according to the diagnosis description 4705 has been performed) is included. The example diagnostic verification circuit 4704 stores the diagnostic confirmation value 4716 (eg, 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 verification circuit 4704 adjusts the storage and/or communication of the diagnostic data set 4714 in response to the diagnostic confirmation value 4716, e.g., ensures that the diagnostic data set 4714 is relevant to performing active diagnostics. do. In certain embodiments, the diagnostic execution circuit 4702 stores all or a portion of the diagnostic data set 4714 as a rolling buffer of data and stores all or a portion of the diagnostic data set 4714 in response to the diagnostic validation circuit 4704 providing the diagnostic confirmation value 4716. 4714 can be saved (e.g., allowing a diagnostic to have a time value or actuator position as part of the diagnostic run, allowing the diagnostic to be fully determined when a timer or other accumulation state is completed) ).

The example active diagnostic description 4705 includes a target device description 4718 (e.g., refueling actuator, engine controller, door actuator, mirror positioning actuator, etc.), which supports endpoints in any network zone 5612. , 5614. 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 in response to the target device description 4718; A diagnostic command value 4712 responsive to the network address value 4722 is provided to the end point. 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 can include a local network address for the component for which the standardized description is intended. The associated configuration table is accessible. Additionally or alternatively, the target device description 4718 may include a description that matches the baseline product (e.g., the 2020LX version of a given vehicle), a description of the original version of the vehicle (e.g., the vehicle was configured after manufacturing) and/or a description that matches an earlier version of the vehicle (e.g., when the vehicle includes a point in time). In certain embodiments, the configuration table or other information utilized by the configuration circuit 5604 to determine the network address value 4722 is configured in one or more configuration files maintained by the network interface circuit, by the policy management circuit. The configuration file may be a maintained configuration file, a configuration file maintained by a CND, and/or a configuration file maintained as part of policy 5606.

The example active diagnostic description 4705 includes a target device description 4718 (e.g., refueling actuator, engine controller, door actuator, mirror positioning actuator) that identifies that the endpoint is on one network zone (e.g., first network zone 5612). etc.), and configuration circuitry 5604 determines that the endpoint is on another network zone (eg, second network zone 5614) in response to target device description 4718. For example, the configuration circuit 5604 determines that the target device description 4718 indicates an incorrect or absent device, and/or the external device provides the target device description 4718 with a previous different and/or standardized configuration. It may be further determined that the configuration circuit 5604 utilizes the local configuration file to determine the correct network address value and/or Determine your network zone. In certain embodiments, the configuration circuit 5604 utilizes other information from the target device description 4718, such as parameter names, intended functionality, etc., to determine the appropriate network address value and/or network zone for this endpoint. do. Similarly, the configuration circuit 5604 may also include a target that indicates an incorrect address, such as another address on the first network zone, when the correct address is one address on the first network zone, in addition to the wrong network zone. Device description 1718 can be corrected.

Operation of configuration circuit 5604 facilitates active diagnostic descriptions (e.g., external devices do not require system-specific information regarding endpoint location and network distribution), when vehicle endpoints and/or local communication devices are mobile and /or allows for adaptation of diagnostic runs when upgraded, and/or allows for an abstraction layer between external devices and vehicle configuration. Simplification and/or abstraction of active diagnostic definitions from the vehicle network configuration reduces the cost of active diagnostic development and product introduction, and increases the user base requiring active diagnostic development (e.g., vehicle configuration information and/or data partitions). (with enhanced protection of sensitive information such as can be increased.

Referring to FIG. 49, an example 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 may be a first network type, such as a CAN bus, and the second advanced network zone 4904 may be a second network type, such as an Ethernet network. Can be done. In certain embodiments, the second high-function network zone 4904 can be of the same type as the first legacy network zone 4902, but with higher functionality, such as a high-speed CAN bus, a faster Ethernet network, etc. It can also be a version of In certain embodiments, a system 4900 such as that shown in FIG. It can be present when a component is added to a vehicle, and the like.

The example system 4900 includes a CND 108 inserted between a first legacy network zone 4902 and a second advanced network zone 4904, where the CND 108 interprets a policy 5606 that includes an external communication value 4906. A policy management circuit 5602 and an external communications control responsive to an external communications value 4906 to coordinate communications between an external device 5618 and an endpoint of the first legacy network zone 4902 and/or an endpoint of the second enhanced network zone 4904. circuit 4908. For example, to reduce traffic generated by communications to and from external devices 5618 on first legacy network zone 4902 and/or due to protection needs of endpoints on 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 security protocols associated with the first legacy network zone 4902 External communication between endpoints of the first legacy network zone 4902 may be restricted (if more restrictive than what is available in the first legacy network zone 4902). In another example, if added by a device and/or entity that may have been recently added to the vehicle (and thus does not have a long known usage history, security pre-screening, and/or vehicle operational impact data) devices on the first legacy network zone 4902 that are not as tightly controlled as the provider of the devices on the first legacy network zone 4902 (e.g., may have been provided by a third party, involve recently developed vehicle functionality and/or External transmissions from the vehicle (e.g., via the vehicle's transceiver external communications between endpoints of the second intelligent network zone 4904 (e.g., those utilizing a particular data provider) can be restricted to reduce If the higher capability device above can have the ability to generate higher data rates). Although the reasons presented for limiting external traffic between endpoints on various networks and external devices are non-limiting and provided for illustrative purposes, external communication control circuitry 4908 may Communication between the endpoints of the zone and any external devices may be coordinated for any reason.

The example system 4900 includes active diagnostic descriptions, e.g., diagnostic operations and/or data collection performed as diagnostic operations, commands to, and collection from any endpoints on any network zone of the vehicle. external communication values 4906, which may include data communicated with and/or communications with these endpoints. The example system 4900 includes active test descriptions, such as test actuations (e.g., testing any endpoints, actuators, sensors, flows, applications, vehicle functions, and/or vehicle controllers on a vehicle) and External communications values 4906 may include instructions to any endpoints on the network zone, data collected from these endpoints, and/or communications with these endpoints. The example system 4900 may include data request values (e.g., data parameter collection from any endpoint and/or including processing of the data parameters), and/or vehicle command values (e.g., any data attached to any endpoint). external communication values 4906 including commands such as actuators, displays, and controllers). Exemplary and non-limiting external devices 5618 include service tools, manufacturer tools, merchant tools, and/or cloud-based tools.

Exemplary external communication values 4906 include a target device description including identification information (e.g., network zone, local address, sensor name, actuator name, data parameter name, etc.) of the target endpoint, in this case external communication control circuit 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 shown in the target device description. In certain embodiments, external communication control circuitry 4908 includes configuration circuitry 5604 (see, e.g., FIG. 56, FIG. 47, and related discussion) for determining the proper identification information for the target endpoint; can be used. Exemplary external communication values 4906 do not include identification information of the target endpoint, and external communication control circuitry 4908 controls external communication values 4906 (again, FIGS. (see ) to provide proper identification information for the target endpoint. System 4900 operates without specific knowledge of endpoint locations, parameter names, local addresses, etc. to perform active diagnostics, testing, and data collection, and external device 5618 operates across several vehicle configurations. You can see that it is possible. Vehicle configuration may change due to changes in the vehicle after servicing, replacement of components (e.g., endpoints), upgrades of components and/or executable instructions stored on computer-readable media, changes over multiple model years, and or may represent changes to the vehicle due to campaigns, upgrades, and/or remanufacturing.

Referring to FIG. 50, an example procedure 5000 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5000 includes an act 5002 of interpreting a policy that includes an active diagnostic description, an act 5004 of providing a diagnostic command value to an endpoint in response to an active diagnostic condition, and an act 5006 of commanding an actuator in response to the diagnostic command value. include.

Referring to FIG. 51, an example procedure 5100 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5100 includes an act 5102 of interpreting a policy that includes an active diagnostic description and a diagnostic performance condition, such that the vehicle operating condition is a diagnostic performance condition and/or a diagnostic command value (e.g., determined from the active diagnostic description). and an act 5104 of determining whether there is a match. In response to the determination of YES in act 5104, procedure 5100 includes act 5004 of providing the endpoint with a diagnostic command value responsive to the active diagnostic condition, and act 5006 commanding the actuator in response to the diagnostic command value. including.

Referring to FIG. 52, an example procedure 5200 for commanding an actuator in response to a diagnostic command value is shown. The example procedure 5200 includes an act 5002 of interpreting a policy that includes an active diagnostic description and an act 5202 of performing a diagnostic data collection operation in response to the active diagnostic description. Additionally, the example procedure 5200 includes an act 5004 of providing a diagnostic command value to an endpoint in response to an active diagnostic condition, and an act 5006 of commanding an actuator in response to the diagnostic command value.

Referring to FIG. 53, an example procedure 5202 for performing diagnostic data collection operations is schematically depicted. The example procedure 5202 includes an act 5302 of processing the collected data (e.g., processing payload and/or frame information of a message of the collected data), an act 5304 of storing the processed data in the collected data, and an act 5304 of storing the processed data in the collected data. an act 5306 of communicating at least a portion of the data to an external device.

Referring to FIG. 54, an example procedure 5400 for storing and/or communicating diagnostic confirmation values is schematically depicted. The example procedure 5400 includes an act 5002 of interpreting a policy that includes an active diagnostic description, an act 5004 of providing a diagnostic command value to an endpoint in response to an active diagnostic condition, and an act 5006 of commanding an actuator in response to the diagnostic command value. including. Further, the example methodology 5400 includes an act 5402 of determining a diagnostic confirmation value and an act 5404 of storing and/or communicating the diagnostic confirmation value to one or more external devices.

Referring to FIG. 55, an example procedure 5500 for commanding an actuator in response to a diagnostic command value is schematically depicted. In addition to the acts listed with respect to FIG. 50 and earlier, the example procedure 5500 includes an act 5502 of determining whether the target device description indicates a network address value for a target endpoint for the commanded actuator (e.g., a target If the device description does not point to a network address value or points to an invalid network address value, operation 5502 determines NO). In response to operation 5502 determining YES, procedure 5500 proceeds to operation 5004. In response to act 5502 determining YES, procedure 5500 includes act 5504 of providing or adjusting a network address value for the target endpoint, and then continues to act 5004.

Referring to FIG. 56, an exemplary 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 a vehicle, or as described throughout this disclosure. The example systems herein recite specific arrangements of, for example, converged network devices (CNDs) 108, circuits, controllers, or other components. Although these arrangements are provided for clarity of this description, these components may be distributed, combined, partitioned, and/or arranged to form the systems described herein. and may have distinctly different relationships than those drawn for implementing the procedure.

A circuit, controller, processor, or other device described herein is configured to functionally perform the operations described herein and includes computer components, such as a processor, memory, and/or communication components. Can contain elements. Additionally or alternatively, such a device may include logic circuitry, hardware configured to perform one or more functions of the device, any type of sensor, actuator, and/or Can include a display. A given circuit, controller, processor, or other such device may be distributed and/or grouped in whole or in part with other such devices.

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

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 may differ 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 schemes, acknowledgment types, requirements, or capabilities, cast availability, e.g., unicast, multicast, and broadcast), network standard type (e.g., Controller Area Network (CAN), Media Oriented System Transport (MOST) network, Local Interconnect Network (LIN), FlexRay network, Time-Triggered Protocol (TTP) network, low voltage Differential Signal Transfer (LVDS) networks, Audio Video Bridging (AVB) enabled networks, customized versions of any one or more of these, and/or proprietary versions of any one or more of these. ) are considering the difference between one of the networks. An exemplary network zone includes an electrical signal zone (e.g., a corresponding network interface circuit interprets the electrical signal value as a communication, and/or an endpoint of the electrical signal zone, e.g., a sensed parameter value, a diagnostic a sensor that provides a certain electrical value indicative of a value, etc., and/or an actuator that moves to a selected position and/or applies a selected force in response to a certain electrical value; and/or a network) where the actuator may additionally or alternatively provide feedback and/or diagnostic information on the electrical signal zone. The electrical signal for the electrical signal zone may be of any type including at least voltage values, frequency values, current values, and/or configured pulse width modulation (PWM) values, such as duty cycles, amplitudes, selective periods, etc. It can be done.

The example system 5600 includes a policy management circuit 5602 that interprets a policy 5606 that includes a network regulation description (not shown), and at least one network interface circuit (e.g., a first and a configuration circuit 5604 including a first network interface circuit 5608 supporting a network zone 5612 and/or a second network interface circuit 5610 supporting a second network zone 5610. For example, policy 5606 may be provided by external device 5618 and/or may be previously stored (e.g., during manufacturing, assembly, and/or during a previous update from external device 5618); In this case, the policy 5606 may include the ability of the selected device on the vehicle 102 to utilize the network zones 5612, 5614, to communicate between zones, and/or to communicate with an external device 5618. Contains a network coordination description with an indication.

The example system 5600 includes a first network interface circuit 5608 provided as part of a CEG where the first network zone 5612 is a CAN bus network and the second network zone 5610 is provided as an Ethernet network. CES includes a second network interface circuit 5610 provided as part of the CES. 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 to the second network interface circuit 5610. 5614 at a selected port of the Ethernet network, thereby enabling inter-network communications between the first network zone 5612 and the second network zone 5614. In this example, communication from the first network zone 5612 to the external device 5618 is provided through the second network zone 5614 (e.g., the external device 5618 is coupled to the second network zone 5614 and/or (e.g., when external device 5618 is coupled directly to first network zone 5612 or a CAN bus).

The example system 5600 is configured as a virtual local area network (VLAN) that is logically separated from the second network zone 5614 but located on hardware that is at least partially shared with the second network zone 5614. Includes a first network zone 5612. In this example, the first network interface circuit 5608 and the second network interface circuit 5610 may be operated as elements of a network switch or router, and in response to the policy 5606, the first network interface circuit 5608 and the second network interface circuit 5610 Controls communications between two network zone 5614 endpoints.

The devices on the vehicle 102 that are conditioned by the policy include one or more of the following: endpoints of network zones, flows for communication devices (e.g., endpoints or applications), and applications for communication devices (e.g., endpoints). Not limited to these. For example, a first network zone 5612 endpoint (e.g., a backup camera on vehicle 102) may request or conduct communications on the vehicle's network, but may be associated with more than one application or flow (e.g., (a first operating condition may be associated with a first flow relating to reversing the vehicle; a second operating condition may be associated with a second flow relating to security actuation of the vehicle), and thus the communication of the backup camera on the vehicle 102 may be associated with a first flow relating to reversing the vehicle; , can have different adjustment parameters depending on the flow associated with the movement operation. In certain embodiments, an endpoint is associated with more than one application or flow and is coordinated according to the highest priority of the associated applications or flows (e.g., requesting immediate communication to be coordinated). (to reduce communication requirements such as determining which applications or flows require immediate communication, and/or to reduce processing time to determine 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 applications or flows requiring immediate communication.

The device may be referred to herein as a local communication device that is on the vehicle 102 and is conditioned by policy. Local communication devices may include network zone endpoints, applications, flows, vehicle functions (e.g. power management, cabin comfort, traction control, etc.), sensor devices, services, and/or vehicle controllers (e.g. engine controller). , transmission controllers, anti-lock braking system (ABS) controllers, advanced driver assistance systems (ADAS) controllers, etc.). A given component, such as an end point of a network zone, may for example be the first local communication device during one operating condition and the other depending on the vehicle operating conditions (e.g. stopped, propelled, parked, etc.). The first local communication device may be a second local communication device during an operating condition and/or the first local communication device may be a second local communication device for a first purpose (e.g., for a brake controller to perform active traction control operation); It can be seen that the brake controller can be a second local communication device for purposes such as providing stored data for diagnostic operations. Additionally, the distribution of communication devices between applications, flows, controllers, vehicle functions, etc. may be due to specific system organization plans, design choices made by the manufacturer or other entity having design and/or configuration control of the system, etc. It can also be seen that it depends on For example, traction control may be provided by an integrated vehicle controller for a given system (e.g., which may handle traction control as a vehicle controller for network coordination purposes), or by a distributed controller for another system (e.g., which may handle traction control as a vehicle controller for network coordination purposes). traction control as a vehicle function) and/or a logically grouped set of actuations to another system (e.g., any hardware organization including the organization described above). traction control can be handled as an application or flow for network coordination purposes). One skilled in the art, having the benefit of the present disclosure and having the information normally available when considering a particular system, can readily determine the organizational scheme and network coordination for the local communication devices of the system. The organizational scheme for local communication devices includes the inclusion and/or association of endpoints in network zones and/or communication with one or more of specific endpoints of the system, vehicle controllers, vehicle functions, applications, and/or flows. (including communication of sources or destinations to endpoints).

Certain considerations for determining an organizational scheme include the number, type, functionality, and interconnection bandwidth of the system's network zones, the available size and/or granularity for the system's policies, and the implementation of the system's policies. the processing power available to expected changes in upcoming model years and/or available or anticipated levels of consumer and/or third party vehicle customization), the number and distribution of sensors and/or actuators across the system, and into network zones. Connectivity of sensors and/or actuators (e.g. aggregation into controllers and/or aggregation using smart sensors/actuators with the ability to interface directly with network zones), multi-purpose communication elements on the system (e.g. multiple presence, number, and distribution of multipurpose data elements (e.g., sensors, actuators, controllers, and/or data values that provide information to vehicle functions, flows, and/or applications) on the system; the presence, number, and distribution of sensors, actuators, controllers, and/or data values) that provide redundant performance to support network aspects (e.g., communication over network zones, data rate of external communication and/or aggregation of data communicated, inter-network communication, etc.) ) including, but not limited to, expected utilization rates.

The example policy management circuit 5602 receives policy communications 5616 from an external device 5618 and stores the policy 5606 (e.g., in a memory location accessible to the policy management circuit 5602 and/or The policy 5606 is interpreted by performing operations such as distributing it across several memory locations and/or updating the stored policy 5606. In certain embodiments, policy management circuitry 5602 can perform, for example, updating the number of configuration files utilized by interface circuitry 5608, 5610, and high-level description of policy communications 5616 by network coordination aspects of system 5600. policy communications 5616 (e.g., when the endpoint is moved without notification to the external device 5618, and/or system-specific designations (e.g., the name of the local parameter value); or ID, flow name or ID, application name or ID, etc.) with elements of policy description 5620, policy 5606 is configured for use by network coordination aspects of system 5600.

The example system 5600 connects the policy management circuit 5602 to the policy management circuit 5602 through at least one of a first network zone 5612 or a second network zone 5614, e.g., a CAN bus port, an OBD port, an Ethernet port, a proprietary port, or a network zone. includes an external device 5618 communicatively coupled using another direct coupling. 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.

Exemplary system 5600 includes policy management circuitry 5602 that validates policy 5606 communicated by policy communication 5616 before performing storage and/or updating thereof. For example, policy management circuit 5602 may require authentication of external device 5618 and/or determination of permissions associated with external device 5618 before implementing changes to policy 5606. In certain embodiments, policy management circuit 5602 determines the permissions associated with external device 5618, the entity utilizing external device 5618, the application or flow utilizing external device 5618, before implementing changes to policy 5606. etc. can be determined. In certain embodiments, policy management circuitry 5602 is unable to enforce policy 5606 if policy communication 5616 contains policy 5606 that is greater than the privileges associated with external device 5618 (e.g., , the policy communication 5616 may be rejected if the step to execute the policy 5606 is considered to be greater than the capabilities of the system 5600, such as network zone bandwidth, external communication limitations, memory storage limitations, etc.). In certain embodiments, the policy management circuit 5602 may be unable to fully enforce the policy 5606 if the policy communication contains a policy 5606 that is greater than the privileges associated with the external device 5618. Policy communication 5616 may be partially implemented in some cases. For example, policy management circuitry 5602 may implement authorized portions of policy communications 5616 and/or portions of policy communications 5616 that have functionality that system 5600 performs. In certain embodiments, the policy management circuit 5602 routes policy communications according to priorities, such as associated endpoints, flows, applications, and vehicle capabilities of the policy communications 5616, for example, when full implementation is greater than the capabilities of the system. 5616 (e.g., enforcing higher priority aspects until a limit is reached) and/or maximizing the enforcement value of policy communication 5616 (e.g., enforcing a given aspect for each aspect). Associating certain values according to associated priority, importance, and benefit descriptions so that, for example, satisfying a group of policy aspects of slightly lower priority satisfies only a single policy aspect of higher priority. (if it is considered to be greater than the value).

Example policy management circuit 5602 provides policy notification 5620 to external device 5618 in response to validating policy 5606. Exemplary policy notification 5620 includes confirmation that policy 5606 has been updated and/or stored pursuant to policy communication 5616. Example policy notification 5620 includes a notification that policy 5606 was not enforced (eg, if external device 5618 does not have authorization to enforce policy communication 5616). The example policy notification 5620 includes a reason for rejecting the policy communication 5616 (eg, lack of authorization, lack of functionality, etc.). The example policy notification 5620 includes a description of one or more aspects of partial implementation of the policy communication 5616, e.g., which aspects of the policy communication 5616 were implemented, rejected, and/or the reasons for the partial implementation. In certain embodiments, the policy management circuit 5602 either in place of and/or in addition to the policy notification 5620 to the first external device 5618 Notification 5620 can be provided to a separate external device (not shown). In certain embodiments, policy notifications 5620 to separate external devices can have the same information or different information. For example, the policy management circuit 5602 may provide a simple policy notification 5620 (e.g., a denial of the policy communication 5616) to the requesting external device 5618 and a more detailed policy notification 5620 (e.g., the authorization that prevented implementation of the policy communication 5616). , capacity that prevented implementation of policy communication 5616, and/or details regarding partial implementation of policy communication 5616) may be provided to separate external devices. In certain embodiments, policy management circuitry 5602 may provide more detailed policy communications 5616 to requesting external device 5618 and simpler policy communications 5616 to separate external devices.

In certain embodiments, policy notification 5620 provides a prompt to externally enable an authorized external device, user, entity, etc. to provide permission to allow updates to policy 5606 in response to policy communication 5616. The method may include providing a user interface of the device. In yet another example, the prompt to the user interface of the external device may be directed to the vehicle owner, vehicle operator, vehicle manufacturer, vehicle administrator (e.g., network administrator, fleet owner, fleet service operator, vehicle regulatory authority). compliance personnel, etc.).

Without being limited to any other aspects of the present disclosure, example aspects of policy 5606 include data collection parameters (e.g., data available for at least one network zone of the vehicle, e.g., data from any sensors, actuators, controllers, and/or endpoints that are at least selectively coupled to the zone and/or in communication with the endpoints of the networked zone), data collection permissions (e.g., sampling rate or communication speed, permissions to provide data values to the network zone, permissions to request data values from the network zone, resolution values for the data, delay permissions for the data, storage permissions for the data, e.g., authorized data storage amount, data Revocation criteria and stale data handling parameters, e.g. where the amount of storage allowed is limited due to lack of functionality to be enforced on stale data and/or to communicate stored data externally. or compression and/or summarization operations performed when competing storage priorities interfere with available storage planning), service publication permissions (e.g., for some local communication devices, external applications, etc.) Authorization to publish service availability and/or available services, such as, for example, provided data parameters, available actuators, etc., which may include a planned authorization to publish but not to others. service subscription permission values (e.g., public services that are visible to the associated local communication device, services that are available to the associated local communication device); and/or permission to subscribe to services for the associated local communication device), and/or external communication permission values (e.g. data rates, related parameters, possible external addresses, possible APNs, aggregated data communication permission, etc.). Policies 5606 may include any of the above for local communication devices (e.g., endpoints, controllers, vehicle functions, flows, applications, sensor devices, etc.), external devices (e.g., specific devices or device categories, entities, and/or applications). Contains one or more of the following. In certain embodiments, a given flow, application, or vehicle functionality may include aspects related to the local communication device and other aspects related to the external device (e.g., converting the local communication device to a cloud-based application or a web-based application). (route prediction application used in combination with other external applications).

Referring to FIG. 57, an example methodology 5700 for coordinating communications between different types of networks on a vehicle is shown. The example procedure 5700 includes an act 5702 of interpreting a policy that includes a network coordination description, and an act 5704 of coordinating communication between a first network endpoint and a second network endpoint in response to the network coordination description. include.

Referring to FIG. 58, an example methodology 5800 for coordinating communications between different types of networks on a vehicle is shown. The example procedure 5800 includes an act of interpreting 5702 a policy that includes a network coordination description and an act of receiving 5802 a policy communication from an external device. Step 5800 determines whether the policy has been verified, e.g., whether external devices are authorized to update the policy, whether the system has the ability to enforce according to the policy, whether the policy has any security Acts 5804 include determining whether standards have been violated, whether policy enforcement is considered to be greater than data storage limits or communication limits, and the like. In response to act 5804 indicating YES, procedure 5800 includes an act 5806 of storing and/or updating a policy and, in response to the network coordination description, between the first network endpoint and the second network endpoint. and an act 5704 of coordinating communications of. In response to act 5804 indicating NO, procedure 5800 includes act 5808 of providing a notification to the external device (and/or to other external devices) and providing notification to the first network endpoint in response to the network coordination description. and a second network endpoint (e.g., utilizing a previous policy, a default policy, etc.).

Referring to FIG. 59, an example methodology 5900 for coordinating communications between different types of networks on a vehicle is shown. The example procedure 5900 includes an act of interpreting 5702 a policy that includes a network coordination description and an act of receiving 5802 a policy communication from an external device. Step 5900 determines whether the policy has been verified, e.g., whether external devices are authorized to update the policy, whether the system has the ability to enforce according to the policy, whether the policy has any security Acts 5804 include determining whether standards have been violated, whether policy enforcement is considered to be greater than data storage limits or communication limits, and the like. In response to act 5804 indicating YES, procedure 5900 includes act 5902 of updating a local configuration file of one or more of the network interface circuit, CEG, CES, and/or gateway interface circuit. In response to act 5804 indicating NO, procedure 5900 optionally includes act 5808 of providing a notification to the external device (and/or to other external devices). Procedure 5900 includes an act 5904 of coordinating intra-network communications, inter-network communications, and/or external communications using network interface circuitry, CEG, CES, and/or gateway interface circuitry (e.g., whether updated or not). (regardless of).

Although procedures 5700, 5800, and 5900 have been described with respect to coordinating communications between networks on a vehicle, they may additionally or alternatively coordinate communications between one or more networks on a vehicle and off-vehicle communications ( For example, the network may be adapted to coordinate communications between the network and external communication portals and/or external devices.

Referring to FIG. 60, an example system 6000 is shown for coordinating network communications on a vehicle using an externally configured CND. The example system 6000 includes a vehicle 102 having a first network zone 6002 and a second network zone 6004 that are different types of network zones, such as in a vehicle with a mixed network. The example system 6000 includes a CND 108 that is inserted (physically and/or logically) between network zones 6002, 6004 and has a policy management circuit 6006 that interprets a policy 6014 communicated to the CND 108 from an external device 6003. (For example, external device 6003 provides policy communication 6020 when CND 108 determines policy 6014 in response to policy communication 6020). The example system 6000 includes configuration circuitry 6008 that includes network interface circuits (eg, first network interface circuit 6010 and second network interface circuit 6012) in response to policy 6014. System 6000 includes network interface circuits 6010, 6012 that coordinate communications between endpoints of first network zone 6002 and second network zone 6004, eg, as configured by configuration circuitry 6008. Coordination actions may be related to inter-network communications (e.g., between network zones), intra-network communications (e.g., between devices on a given network), or other communications (e.g., to external devices, service tools, user devices, etc.). communication). Any adjustment operation described throughout this disclosure is contemplated for system 6000. The example depicted in FIG. 60 includes policy communication 6020 having aspects such as inter-network coordination 6022 parameters, intra-network coordination 6024 parameters, policy-related permissions and/or authorizations 6026, and/or policy-related data collection parameters 6028. include. The example aspects of policy communication 6020 and the corresponding implementation of these aspects within policy 6014 on a vehicle are non-limiting examples provided for illustrative purposes. A given embodiment may include additional policy aspects and/or may exclude one or more of the depicted aspects.

The example system 6000 includes an external device 6003 that is a cloud application (e.g., running on a cloud server or other computing device in at least intermittently communicating with the vehicle), a web-based tool, a combination thereof, and and/or have a portion of the external device 6003 be one of these, with other portions provided through other implementations (eg, service tools, fleet tools, driver mobility devices, etc.).

The example external device 6003 includes a policy development interface 6015 that receives policy input values 6032 from a number of users (e.g., through a user input device 6030), and places the policy input values 6032 into a policy 6014 (and/or the policy). a policy formulation engine 6016 that compiles (into one or more aspects of policy communication 6020 that is utilized to provide to CND 108) a policy enforcement engine that communicates policy 6014 (and/or policy communication 6020) to CND 108; 6018. The example policy development interface 6015 interacts with a user device 6030 to receive policy input values 6032 and operate, for example, a GUI with the user device 6030 and an interactive application such as a web-based tool, cloud application, mobile application, etc. is activated to receive the policy input value 6032. In certain embodiments, the policy development interface 6015 receives a configuration file (eg, an XML file, a standard format file, etc.) as a policy input value 6032 from the user device 6030. In certain embodiments, receiving the policy input value 6032 includes determining whether the policy input value 6032 is legal (e.g., formatting, permissions associated with the user device and/or associated entity, policy input values). policy inputs 6032 into multiple parts (e.g., data collection regarding secondary policies, network usage permissions, external vehicle communication). The policy input value 6032 or a portion thereof is parsed into metadata (e.g., timestamp, policy version, associated application, etc.). (e.g., users, user roles, associated entities, user device identifiers, etc.) and/or prioritizing among policy input values 6032 (e.g., whether policy input values 6032 are compatible). any aspect of the policy input value, such as the data type or associated vehicle functionality, when not included and/or cannot be included at all, e.g. when considered larger than the aggregate policy size limit; and and/or any association with a policy input value 6032 such as an associated entity).

The example system 6000 includes a policy interaction engine 6019 that generates policy interaction code 6034, such as header files, parameter definitions, and/or API declarations. Policy interaction engine 6019 facilitates user-friendly development of policies and/or portions thereof by users, applications, and/or tools, allowing users to advantageously interact with and utilize aspects of policies that they are authorized to develop. Select possible parameters, functions, control commands, etc., allowing the user to minimize vehicle-specific knowledge requirements for developing policies and/or aspects thereof.

The example system 6000 includes data collection definitions (e.g., data parameters to be collected, and/or data storage, such as, e.g., processing to be performed, data formats for individual data elements, file types for data to be stored). Data parameters, including any data collection parameter set indicated throughout this disclosure, including information such as data format, communication parameters, e.g., data rate, timeline, stale data handling, and/or data expiration. ). An exemplary data collection definition includes at least one local communication device (e.g., an endpoint, flow, application, network zone, vehicle function, service set, etc., as described throughout this disclosure) that supports at least one data collection parameter. include. The example system 6000 allows a user to provide identifiers, addresses, and The method further includes a user inputting a port (e.g., identifying a local communication device that is a source for the collected data and/or identifying a destination for the collected data). The example system 6000 includes a CND 108 that utilizes data collection definitions to perform data collection operations, thereby collecting data from vehicles according to user-entered parameters regarding the source and/or destination of the generated data.

The example system 6000 may be implemented instead of utilizing user-defined portions (e.g., where addresses or other information are intentionally hidden from the user for security purposes, and/or where the user of policy input values is (to facilitate ease of implementation of input) and/or in addition to utilizing user-defined parts (e.g. to correct user-defined parts that may have incorrect values). (e.g., to convert user-defined portions that may be utilizing legacy addressing values for endpoints). In certain embodiments, CND 108 configures within policy 6014 to translate addresses, e.g., if the endpoint of the vehicle moves (e.g., between network zones and/or to a different address), etc. Acts of providing all or a portion of the data collection definition may be performed utilizing the transformation information provided and available to the CND 108. In certain embodiments, the policy formulation engine 6016 may include, for example, to mask addresses from user devices, to enable reference to data parameters that comply with industry norms, simplified descriptions, etc.; All of the data collection definitions where the predetermined burden of performing the operations to provide, update, and/or correct the data collection definitions is split between the CND 108 and the policy formulation engine 6016. Alternatively, the act of providing a portion can be performed. For example, the CND 108 may perform certain operations that provide, update, and/or correct data collection definitions (e.g., local vehicle-specific operations such as local address translation), and the policy formulation engine 6016 may perform other operations that provide, update, and/or correct data collection definitions (e.g., off-vehicle operations that provide planned information availability and/or functionality to various users, user devices, applications, entities, etc.). Server-side operations such as data destination locality) can be implemented.

Referring to FIG. 69, an example visualization configured to functionally perform operations depicting data flows on a vehicle and/or provide visualization of a vehicle network and aspects such as network utilization, CND, endpoints, etc. A management controller 6912 is shown. The exemplary visualization management controller 6912 may be utilized with any system herein and/or to implement one or more aspects of the operations herein. be able to. The visibility management controller 6912 can be distributed across one or more vehicle controllers, CNDs, and/or external devices, and/or can be provided on a single one thereof. Aspects of the visualization management controller 6912 located on the vehicle and/or outside the vehicle are expected to access (and/or have the ability to access vehicle network data) characteristics of the system, vehicle network data. ) entities (e.g., controllers, applications, flows, external devices, third-party applications, etc.), communication plans (e.g., schemes for communicating network data and/or visualization data from vehicles and/or cloud storage locations), and / or depending on the processing plan (e.g. the scheme for processing the monitored data into visualization data, the type of processing performed, and the number of distinct types of processing performed for different clients of the visualization data) It may be different. The visibility management controller 6912 is configured to monitor the vehicle network (e.g., to diagnose problems on one or more networks, to monitor communications from local communication devices, and/or to detect anomalies on the vehicle. (for diagnosing side issues that may be presented by network utilization and/or data flow).

The example visualization management controller 6912 may control vehicle communication data 6908 (e.g., data flows over network zones, data flows between network zones, data flows through a CND or other coordinating component, and/or specific endpoints, flows, The vehicle communication circuit 6902 interprets data flows related to services, vehicle controllers, vehicle functions, applications, etc.). Exemplary vehicle communication data 6908 includes communications between multiple endpoints of a vehicle's network zones (e.g., on the same or different network zones) and/or multiple local communication devices (e.g., on the same or different network zones). network and/or distributed across more than one network zone). The example visualization management controller 6912 includes a visualization circuit 6904 that generates the visualization data 6910 (e.g., see FIGS. 61-68 and related discussion) and a visualization circuit 6904 that generates the visualization data 6910, e.g., from an external device, a user device (e.g., a service tools, network monitoring tools, third party applications, and/or applications utilized by users that monitor the vehicle's network, and/or other aspects of the vehicle regarding the vehicle's network and/or data flow). display interface circuit 6906. The example visualization management controller 6912 includes vehicle communication circuitry 6902 located in whole or in part on the vehicle (e.g., on the CND, on the vehicle controller, and/or on the network interface circuitry), where the vehicle communication Data 6908 is provided to ports in the network zone (eg, monitor ports, mirror ports, and/or ports otherwise accessible to external devices). The example visualization management controller 6912 includes visualization circuitry located on an external device, where the display interface circuitry 6906 provides visualization data 6910 to a user device communicatively coupled to the external device. Without being limited to any other aspect of the present disclosure, example visualization data 6910 includes a graphical representation of at least a portion of communications between local communication devices of a vehicle, a graphical representation of at least a portion of communications passing through a CND. a graphical flow representation of at least a portion of the communication coordinated by at least one of the first network interface circuit or the second network interface circuit, and/or the communication between the first network zone and the second network zone; including one or more graphical flow representations of at least a portion of incoming and outgoing communications. Exemplary and non-limiting graphical flow representations include data tables depicting data flows and/or any aspects of data flows described throughout this disclosure.

Referring to FIG. 61, illustrated is an example apparatus 6100 for providing a network overview for one or more networks of a vehicle having a mixed network. The exemplary apparatus 6100 can be used with any of the vehicles described throughout this disclosure, and aspects of the apparatus 6100 can be implemented on the vehicle, on an external device in at least selective communication with the vehicle, on a cloud, etc. It can be located on a server and/or on a web application.

The example apparatus 6100 includes vehicle communication circuitry 6102 that interprets vehicle communication data 6116, which can be data collected from and/or provided to the vehicle. Additionally, example apparatus 6100 includes visualization circuitry 6104 that generates visualization data 6118 responsive to vehicle communication data 6116. Exemplary visualization data 6118 includes a first network identifier (eg, a network zone, endpoint, or other network identifier for corresponding data) and a second network identifier. Example visualization data 6118 may include network identifiers supporting each of at least two distinct network zones of the vehicle and/or each of at least two distinct endpoints of the vehicle. Exemplary network identifiers include Ethernet-based protocols and/or CAN-based protocols. Another example network identifier includes one or more of a cellular-based protocol, a WiFi-based protocol, and/or a Bluetooth-based protocol.

The example device 6100 further includes a display interface circuit 6106 that transmits visualization data 6118, provides visualization data 6122 stored on an electronic display 6112, and/or provides visualization data 6118. Transmission of visualization data 6118 includes the steps of transmitting visualization data 6118 from the vehicle to a tool, transmitting visualization data 6118 from the vehicle to a cloud server, and transmitting visualization data 6118 from the vehicle to a display device (e.g., electronic display 6112 , such as vehicle displays, service tools, external computer devices, such as driver devices, service devices, manufacturer devices, fleet owner or service devices, vehicle communications manager devices, and/or third party devices). transmitting the visualization data 6118 from the cloud server to the tool; transmitting the visualization data 6118 from the cloud server to the display device; and/or transmitting the visualization data 6118 from the first cloud server. Send to a second cloud server (e.g., enable distributed storage criteria among cloud servers, including data anonymization, data aggregation, and partitioning of data aspects for storage target visualization data 6122) Any one or more operations selected from operations such as steps may be included. In certain embodiments, the transmission of visualization data 6118 includes storing visualization data 6118 in on-vehicle storage (e.g., visualization stored for subsequent access, access request, and/or subsequent transmission to a location off-vehicle). dedicated memory space available for the data 6122) and/or storage coupled thereto (e.g., on the vehicle, on a mobile device such as the driver's mobile phone, and/or on a mobile device such as a WiFi or Bluetooth connection). a USB device coupled to a computing device with which the computer is in near field communication. Additionally or alternatively, transmitting the visualization data 6118 may include storing the visualization data 6118 on the vehicle's shared storage, storing the visualization data 6118 on the vehicle's shared storage, and transmitting the visualization data 6118 to the stored visualization data 6122. selectively transmitting the visualization data 6118 to the external device, transmitting the visualization data 6118 to the secure cloud storage, and/or transmitting the visualization data 6118 to the secure cloud storage and transmitting the visualization data 6118 to the stored visualization data 6122. The method may include any one or more operations selected from the following: providing selected access to a monitoring tool, an external application, a service tool, and/or a user device.

Exemplary device 6100 includes an electronic display 6112 that interprets and displays visualization data 6118. The example electronic display 6112 accesses and displays at least a portion of the stored visualization data 6122 and/or processed visualization elements determined from the visualization data 6118 and/or the stored visualization data 6122. Exemplary visualization data 6118 includes topology data corresponding to the network topology of the first network and/or the second network (eg, depicting the networks and/or selective endpoints connected to each thereof). Topology data may include a visual presentation, table listing, or other visualization thereof.

The example visualization circuit 6104 is further structured to include a portion of the metadata of the vehicle communication data 6116 within the visualization data 6118. Exemplary and non-limiting metadata for vehicle communication data 6116 includes source addresses, destination addresses, timestamps, vehicle operating or state conditions, fault code information, destinations, flows, applications, and/or status regarding vehicle functionality. Contains data such as parameters. In certain further embodiments, the metadata of the vehicle communication data 6116 includes information regarding the trajectory of the vehicle communication data 6116 through the vehicle network, such as frame data about the original communication (e.g., if the communication was encapsulated and frame data from the communication on the first network 6108 when passed from the second network 6110 to the vehicle communication circuit 6102), the payload of the vehicle communication data 6116 and/or processing information regarding the frame (e.g., the payload of the communication and/or (e.g., a description of the processing operations, upsampling and/or downsampling, etc.) performed on the frame and allowing for the inverse calculation of the processing. In certain embodiments, the metadata includes predetermined values, e.g., a first data value for a first processing operation (e.g., filtering, changing resolution, etc.), a second data value for a second processing operation, etc. The data values can communicate processing operations (or other operations) according to the values (eg, designated bits) of selected portions of vehicle communication data 6116.

The example apparatus 6100 includes data filtering values 6120 (e.g., selection of certain endpoints and/or local communication devices, selection of certain network zones, communications that meet specified criteria, downsampling descriptions for selected communications, etc.). , endpoints with associated failure values, communications regarding abnormal conditions such as flows, vehicle functions, and/or applications, and/or communications regarding endpoints with packet loss, high or low communication rate expectations). Includes circuit 6114. Exemplary and non-limiting data filtering values 6120 include network address association, vehicle control device association, vehicle system association, network protocol type, endpoint identifier, data type, application association, and/or flow association. Exemplary and non-limiting data filtering values 6120 may be applied to systems such as engine systems, steering systems, braking systems, fuel systems, prime mover systems, anti-lock braking systems, traction control systems, and/or drive transfer control systems. Contains references. Still other exemplary and non-limiting data filtering values 6120 include references to systems such as security systems, lighting systems, safety systems, environmental control systems, ADAS, and/or infotainment systems.

Exemplary apparatus 6100 includes visualization circuitry 6104 that filters vehicle communication data 6116 to generate visualization data 6118 based at least in part on data filtering values 6120. In certain embodiments, data filtering values 6120 are communicated from external device 1618 and/or electronic display 6112, external tool 6114, and/or user device, e.g., vehicle owner or operator, service provider. through a user interface (e.g., by display interface circuit 6106) and/or with a cloud-based or web-based application operated on the device of a personnel, manufacturer, fleet owner, fleet service personnel, or vehicle communications manager. It can be provided within a policy 1606 that is received through the interaction.

Referring to FIG. 63, an example user interface for retrieving and filtering vehicle communication data 6116 is shown. Example user interfaces may be implemented on external devices, web applications, cloud-based applications, external tools, etc. In the example described in FIG. allows you to choose. In this example, the filter selection branches e.g. include only selected endpoints, flows, applications, etc. (selection branches on the right) that narrow down from the endpoints that are monitored according to the filtering criteria (e.g. selection branches on the left). enable. In the example shown in Figure 63, the monitored parameters can be further downsampled (option at the bottom). In the example described in FIG. 63, a timeout for selected mirroring can be set (eg, if monitoring is implemented using port mirroring). The example user interface depicted in FIG. 63 illustrates certain aspects of the network monitoring and filtering operations described herein and is not limited to the present disclosure.

The example device 6100 includes visualization data 6118 including traffic monitor visualizations. For example, a traffic monitor visualization shows vehicle systems, applications, flows, vehicle controllers, vehicle functions, endpoints (e.g., incoming and/or outgoing traffic to the endpoints) on one of the first network or the second network. , a selected one of the first network or the second network, or a port of one of the first network or the second network. Exemplary visualization data 6118 includes, for example, a port counter visualization that displays messaging traffic corresponding to one port (physical port or logical port) of a network zone. Exemplary visualization data 6118 includes, for example, a visualization of an endpoint data flow monitor displaying messaging traffic corresponding to one endpoint of a network zone.

Referring to FIG. 64, example visualization data 6118 is shown including a traffic monitor visualization. The example depicted in FIG. 64 depicts network traffic (eg, messages, bits, etc.) for a first endpoint 6402 and a second endpoint 6404. The example described in FIG. 64 is a non-limiting example, and traffic monitors can be depicted in any manner, e.g., per network, per port, all traffic for applications, all traffic for flows, all traffic for vehicle functions. It can be organized according to any grouping, such as all traffic, all traffic for a group of services.

The example apparatus 6100 includes an endpoint on one of a first network or a second network, a vehicle system, an application, a flow, a vehicle controller, a vehicle function, a selected network zone, and/or a selection of one of the network zones. Contains visualization data including network activity profiles provided for one or more of the ports.

Referring to FIG. 65, example visualization data 6118 is shown including a network activity profile. The example depicted in FIG. 65 depicts network bandwidth utilization for a selected network zone using several utilization plots 6502, 6504, 6506, 6508, each related to an endpoint of the selected network zone. ing. Referring to FIG. 66, example visualization data 6118 is shown including a network activity profile for a selected network zone. The example described in FIG. 65 shows all activity related to network zones in the top row, network bandwidth utilization related to specific devices (e.g., ISL0, ISL1) in the middle row, and related to vehicle controllers (e.g., head-up display and head unit) in the bottom row. The network bandwidth utilization for the vehicle controller further depicts the utilization for some specific devices that have been broken out (eg, various cameras in this example). The examples set forth in FIGS. 65 and 66 are non-limiting, and network activity profile data can be determined and displayed in any manner, including by endpoint, flow, application, vehicle function, vehicle controller, etc. Grouping and/or subgrouping can occur in any manner.

The example vehicle communication circuit 6102 communicates to the vehicle communication circuit 6102 the steps of interpreting vehicle communication data 6116 from a policy 1606 stored on a memory disposed on the vehicle and communicatively coupled to the vehicle communication circuit 6102. receiving vehicle communication data 6116 from a service tool communicatively coupled to the vehicle communication circuit 6102; receiving vehicle communication data 6116 from an application communicatively coupled to the vehicle communication circuit 6102; The vehicle communication data 6116 is interpreted by performing one or more operations, such as receiving the vehicle communication data 6116 from a monitoring tool that has been installed.

In certain embodiments, retrieving vehicle communication data 6116 including traffic monitoring, network activity, and/or messages corresponding to an endpoint of the network zone and/or a port of the network zone from the first port of the network zone. and monitoring the second port of the network zone to determine vehicle communication data 6116. For example, a first port of the second network zone 6110 may support a monitored endpoint, in which case the act of retrieving vehicle communication data 6116 may be performed on the first port of the second network zone 6110. to a second port of the second network zone 6110 (e.g., if a monitoring tool such as vehicle communication circuitry 6102 and/or external tool 6114 is communicatively coupled to the second port); 2 of the network zone 6110 to determine vehicle communication data 6116.

Referring to FIG. 67, example visualization data 6118 is shown including data flows between selected network participants (eg, endpoints, flows, applications, vehicle controllers, etc.). The example depicted in Figure 67 shows the data flow between selected endpoints, in this example "EP1" (e.g., an endpoint such as a head unit) and other endpoints (e.g., in this example an ADAS-related endpoint). It depicts the data flows associated with components, such as the parking controller (EP3, EP5, EP10). The example described in FIG. 67 allows monitoring of the network to determine whether expected data flows are occurring, whether abnormal data flows are occurring, and so on. Referring to FIG. 68, exemplary visualization data showing total network activity for a selected network zone (top row) and data path tracing from the selected endpoint to other endpoints in the system (data path at the bottom row). 6118 is shown. This example provides, for example, the selection of the time to be utilized for the data path tracing indication in the bottom row (indication in the top row), the selection of the target endpoint (e.g., EP1 on the left), and/or the transmission, reception, or A user interface element may be provided that allows selection of which of both of these to draw. In certain embodiments, visualization data 6118 can be provided as a user interface that provides a user with component selection and has associated data flows shown, for example. Visualizations such as those shown in FIGS. 67 and 68 can confirm expected operation and diagnose problems (e.g., degraded component operation, diagnose network problems, and/or It can be seen that the detection of abnormal operating conditions, such as communication between communicating components, can be utilized. Additionally or alternatively, visualization such as that shown in Figure 67 can be used to visualize applications, flows, vehicle functions, etc. on the vehicle controller to improve network topology design, hardware selection, and/or protocol selection. It can be used to aggregate (eg, reduce network traffic requirements) and/or to identify potential redundant or unnecessary network communications.

Referring to FIG. 62, an example local address table 6200 is shown that schematically illustrates configuration information consistent with various embodiments of the present disclosure. The example local address table 6200 may be part of a policy 1606 and/or a configuration file (eg, accessible in whole or in part by an interface circuit and/or a configuration circuit). Local address table 6200 may be provided as a data structure in a memory location accessible to interface circuitry, configuration circuitry, and/or other implementation components described throughout this disclosure. Local address table 6200 may be provided as a distributed data structure, portions of which are provided as data structures in memory locations accessible to implementing components. The exemplary local address table 6200 is shown to provide an embodiment of the types of local address information that may be utilized to implement aspects of the present disclosure; The details of the organization of the data structures implementing address table 6200 can be configured according to the implemented embodiment. Exemplary local address table 6200 includes endpoint identifiers 6202, which can be local identifiers of endpoints present in the system. In yet another example, a non-local endpoint identifier (not shown) may be included that allows, for example, an external device to refer to the endpoint using industry standard terminology or other selected terminology. The example local address table 6200 includes, for example, a network zone identifier 6204 that indicates which network zone the endpoint is considered part of. Additionally, example local address table 6200 includes local address values 6206 that indicate, for example, how each endpoint is addressed on the appropriate network zone. In certain embodiments, example local address value 6206 may be a TCP/IP address, port number, or other identifier. In certain embodiments, a local address value 6206 is included within a message to indicate the intended destination (or source) of the message to or from a destination, e.g., on a logical bus architecture such as a CAN bus. Can contain message identifiers such as values. Exemplary local address table 6200 includes external address values 6208, which can include addresses utilized by external devices to identify endpoints, for example.

Utilization of the external address value 6208 allows an external device to extract knowledge of the endpoint, including local addressing and/or associated network zone, from operations that utilize and/or collect data from the associated endpoint. . Including further information in the local address table 6200, such as additional external address values (e.g., allowing multiple external addresses to be associated with a given endpoint of the system), and/or one or two We see that the inclusion of additional non-local endpoint identifiers above (e.g., allowing multiple industry norms, proprietary designations, unofficial designations, etc. to be successfully associated with a given endpoint of a system) is possible. be able to. In certain embodiments, one or more of the external address 6208 and/or the non-local endpoint identifier can be further associated with a version (e.g., interface version, vehicle model description, etc.) and may change within the vehicle. occurs (e.g., the endpoint moves between network zones and/or addresses) or a change occurs outside the vehicle (e.g., the system is no longer applicable to a particular vehicle for an updated vehicle configuration). When an external application (not an external application has been updated), the implementation component using the local address table 6200 interprets data commands and/or requests from external applications, algorithms, etc. to determine the desired endpoints of these data commands and and/or enable proper association with the request.

It can further be seen that the use of the local address table 6200 allows for multiple addressing support for a vehicle endpoint, for example providing both IPv4 and IPv6 addressing for a vehicle endpoint. In certain embodiments, the local address table 6200 can be extended, or alternatively, separate data structures can be maintained for endpoints and applications, flows, vehicle functions, vehicle controllers, APNs, external data routing. Enables association with routes, network zone trajectories, etc. Local address table 6200 can be utilized in network address translation (NAT) operations. Thus, a given application, such as "route management", can be associated with specific endpoints of a vehicle, and these associations may be associated with movement of the endpoints (e.g. from one network zone to another). (to a network zone) can persist from start to finish. Utilization of the local address table 6200 and/or extended or alternative data structures described herein may be used to control priorities, permissions, subscription management (for both service publishing and service subscriptions), and/or Provides for the configuration of any other communication coordination activities shown herein.

In certain embodiments, the local address table 6200 may be extended, or alternatively, a separate data structure may be maintained to store addresses of external devices by destination, application, flow, vehicle function, and/or vehicle. Allows you to configure according to your controller. For example, a given vehicle function can be allowed access to a given external resource (e.g., a routing function that accesses external resources and has maps, traffic reports, etc.) and provides access to external resources. The associated external address is associated with the vehicle function. In this example, it is possible that other vehicle functions are not allowed access to this given external resource, and instead the associated external address is associated with the vehicle function (and/or these other vehicle functions depending on the implementation) such that a default address, protected space, null communication, or other selected behavior is implemented when requesting access to the vehicle function. association is lost). Therefore, https://www. google. The first application of the vehicle requesting access to an external resource such as A second application on the vehicle requesting access to the same external resource may display an access denied indication, a default external resource indication (e.g., indicating that it is a cloud-based resource within the protected space and that the requested resource is not allowed), or Other selected responses from the system may be received. Accordingly, the local address table 6200 and/or an extended or alternative version thereof can be utilized as a local DNS and/or an external DNS. In certain embodiments, for example, access to an external resource is requested and the external DNS does not have an address for this resource and the requestor (e.g., endpoint, application, flow, vehicle function, and/or vehicle controller) An external DNS (such as one on a cloud server or from an internet provider) that is external to the vehicle and provides an external address can be accessed if the external DNS is denied access to this external resource. In certain embodiments, an external DNS on the vehicle may be updated based on addresses retrieved from an external DNS located outside the vehicle.

Referring to FIG. 70, an example procedure 7000 for transmitting visualization data is shown. The example methodology 7000 includes an act 7002 of interpreting vehicle communication data, an act 7004 of generating visualization data in response to the vehicle communication data, and an act 7006 of transmitting visualization data.

Referring to FIG. 71, an example procedure 7100 for transmitting visualization data is shown. The example procedure 7100 includes an act 7002 of interpreting vehicle communication data, an act 7102 of interpreting a data filtering value, and an act 7104 of filtering at least a portion of the vehicle communication data based at least in part on the data filtering value. . Additionally, the example methodology 7100 includes an act of generating 7004 visualization data in response to the vehicle communication data and an act of transmitting 8006 the visualization data.

Referring to FIG. 77, illustrated is an example methodology 7700 for transmitting visualization data to an external device and/or a user device. The example procedure 7700 includes an act 7702 of interpreting a policy from an external device and an act 7704 of configuring a network interface circuit in response to the policy. The example methodology 7700 includes an act 7706 of coordinating communications on the vehicle (inter-network and/or intra-network communications) and an act 7708 of determining source and/or destination definitions for data collection. The example procedure 7700 includes an act 7710 of determining visualization data responsive to vehicle communication data (e.g., collected in response to policy and source/destination definitions for collected data) and transmitting the visualization data (e.g., external devices, user devices, data storage, applications, etc.).

Referring to FIG. 78, illustrated is an example procedure 7702 for interpreting a policy to configure coordination of inter-network and/or intra-network communications. The example procedure 7702 includes an act 7802 of generating a policy interaction code, an act 7804 of receiving a policy input value responsive to the policy interaction code, and an act 7806 of generating a policy responsive to the received input value. Further, the example procedure 7702 includes an act of communicating 7808 the generated policy to the CND using an external device.

Referring to FIG. 72, an example system 7200 is shown that includes a vehicle 102 having a first network zone 5612 and a second network zone 5614. Network zones 5614 are of different types. The example depicted in FIG. 72 includes a CND 108 inserted between network zones 5612, 5614. The example CND 108 includes policy management circuitry 5602 that interprets a policy 5606 that includes a network coordination description, and configuration circuitry 5604 that includes a first network interface circuit 5608 responsive to the network coordination description, in this case a first A network interface circuit 5608 coordinates communication between the first network zone 5612 endpoint and the second network zone 5614 endpoint. Additionally or alternatively, configuration circuitry 5604 includes gatekeeper interface circuitry 7202 that coordinates communications between endpoints of at least one of network zones 5612, 5614 and external communication portals and/or external devices 5618. Configure in response to network coordination descriptions. The exemplary first network interface circuit 5608 includes a CEG, in which case the first network zone 5612 is not a primary network (e.g., the first network zone 5612 is a CAN network and the second network zone 5614 is an Ethernet network), a first network interface circuit 5608 is communicatively coupled to a port of second network zone 5614 to send and receive communications passed between network zones 5612, 5614.

Referring to FIG. 73, an example network coordination description 7304 includes a data request authorization description 7306 that includes data values 7310 for data requestors 7308 (eg, each endpoint on one of the network zones 5612, 5614). The example first network interface circuit 5608 coordinates communications between the first network zone 5612 endpoint and the second network zone 5614 endpoint in response to the data request authorization description 7306, e.g. Restricting data requesters 7308 to authorized data values 7310 and/or preventing associated data requesters 7308 from accessing unauthorized data values 7310. In certain embodiments, the first network interface circuit 5608 is further configured to initiate communications between endpoints of the first network zone 5612 (e.g., both on the first network zone 5612) in response to the data request authorization description 7306. ) from the first end point to the second end point.

The example system 7200 further includes configuration circuitry 5604 that includes a second network interface circuit 5610 responsive to the network coordination description, where the second network interface circuit 5610 is configured to coordinating communications between; Referring again to FIG. 73, the example second network interface circuit 5610 facilitates communication between the second network zone 5614 endpoint and the first network zone 5612 endpoint in response to the data request grant description 7306. For example, restricting the associated data requester 7308 to authorized data values 7310 and/or preventing the associated data requester 7308 from accessing unauthorized data values 7310. In certain embodiments, the second network interface circuit 5610 is further configured to initiate communication between endpoints of the second network zone 5614 (e.g., both on the second network zone 5614) in response to the data request authorization description 7306. ) from the first end point to the second end point.

The example system 7200 further includes configuration circuitry 5604 including a gatekeeper interface circuit 7202 responsive to the network coordination description 7304, where the gatekeeper interface circuit 7202 interfaces between the first network zone 5612 and the second network zone. Coordinating communications between both endpoints of zone 5614 and external device 5618. Exemplary external device 5618 may be coupled to first network zone 5612, second network zone 5614, or both. Additionally or alternatively, external device 5618 can be coupled to a transceiver (not shown) of vehicle 102, which can be a cellular, WiFi, and/or Bluetooth transceiver. In certain embodiments, a transceiver can be communicatively coupled to a network zone, e.g., a port on one of the network zones. In certain embodiments, the first network zone 5612 is a non-primary network zone, the second network zone 5614 is a primary network zone, and the transceiver is communicatively connected to the second network zone 5614. be combined. In yet another exemplary embodiment, the second network zone 5614 is an Ethernet network, and the transceiver communicates with the second network interface circuit 5610 through a port of a CES that includes the second network interface circuit 5610. It is coupled to a second network zone 5614.

Exemplary and non-limiting external devices 5618 include one or more of a cloud server-based application, a web-based application, and/or a mobile device application. Referring again to FIG. 73, the example data request permission description 7306 includes a data access permission 7314 associated with each of a number of external audible devices 7312. External notifications 7312 include identified external devices 5618, external applications, external flows, external entities (eg, service personnel, manufacturers, owners, operators, etc.), external addresses, and the like. Exemplary and non-limiting data access permissions 7314 include permissions to communicate with specific endpoints, flows, applications, vehicle functions, network zones, vehicle controllers, and the like. In certain embodiments, the data access permissions 7314 may be distinct for outgoing and incoming communications, e.g., a given external audible device 7312 may transmit data to a first endpoint on a vehicle. Although it may not have permission to request, the first endpoint on the vehicle may have permission to send data to this given external annunciator 7312. The example data request authorization description 7306 includes an external device, an external audible device, an endpoint, a flow related to an external device and/or an external audible device, a vehicle function related to an endpoint, an external device, and/or an external audible device, and/or an endpoint, Includes data access permissions associated with one or more of the applications related to the external device and/or external alarm. Exemplary and non-limiting data access permissions 7314 include the ability to request, send, and/or publish data, the ability to request, send, and/or publish specific data values, and/or the ability to request, send, and/or publish data to external including one or more of communication bandwidth limitations (e.g., data rate, aggregate data amount per unit time, and/or sharing of available bandwidth). The example system 7200 includes a gate that coordinates communications between the endpoints of the network zones 5612, 5614 and the external device 5618 (and/or the external alarm 7312) in response to the data request authorization description 7306 and/or the data access authorization 7314. Further includes a keeper interface circuit 7202.

Further, the example gatekeeper interface circuit 7202 may be configured to coordinate communications with an external device 5618 (and/or an external notifier 7312) in response to a flow for coordinated communication (e.g., the priority of the associated flow, the associated adjusting permissions based on the role of the flow and/or current operating conditions, etc.), adjusting permissions in response to data types for the adjusted communication (e.g., increasing or decreasing the priority of certain data types). restricting certain data types to certain communication conditions, such as the availability of high-speed data communications; classifying data according to criteria such as age of the data; and granting permissions accordingly. adjusting the data rate, bandwidth, and/or aggregate data value in response to the data service provider regarding the adjusted communication; responsively coordinating vehicle functions for coordinated communication (e.g., prioritizing certain vehicle functions) and/or being capable of communicating with external devices 5618 (and/or external alarms 7312); One or more of the steps of adjusting in response to the connection type of the bond (eg, enabling high communication speeds when high speed and/or inexpensive data connections are available) are further performed.

The example system 7200 receives a policy update that includes a change to the network coordination description 7304 (e.g., from the policy management circuit 5602), and in response to the change to the network coordination description 7304, the first network interface circuit 5608, the first 2 includes a configuration circuit 5604 that updates the configuration of the gatekeeper interface circuit 7202 and/or the gatekeeper interface circuit 7202. In yet another example, the policy management circuit 5602 interprets the authorization associated with the policy update based on, for example, the authorization of the external device 5618 and/or the external notifier 7312 that provides the policy update. The example policy management circuit 5602 determines that the authorization indicates that the requesting unit (e.g., external device 5618 and/or external notifier 7312) is not authorized to make changes to the network coordination description of the policy update. Suppress policy updates in whole or in part in response. In certain embodiments, policy management circuitry 5602 may additionally or alternatively be responsive to requesting units and/or other external devices 5618 to suppress or partially suppress policy updates. Alternatively, one or more policy notifications 5620 can be provided to external notification device 7312 (see, eg, FIG. 56 and related discussion). Exemplary and non-limiting requesting units include an entity related to a policy update, an application related to a policy update, a flow related to a policy update, a vehicle function related to a policy update, an identifier of an external device communicating a policy update, and/or an external device related to a policy update. Contains one or more of the identifiers of the notification device.

Referring again to FIG. 72, the example policy management circuit 5602 interprets a policy 5606 that includes a network usage permission description 7404 (see FIG. 74). The example network authorization description 7404 includes an external data access description 7406, where the configuration circuit 5604 further configures the gatekeeper interface circuit 7202 in response to the external data access description 7406; Gatekeeper interface circuit 7202 coordinates communication with external device 5618 in response to external data access description 7406 . Exemplary external data access descriptions 7406 may include, for example, an identified external device 5618, external application, external flow, external entity (e.g., service provider, manufacturer, owner, operator, etc.), external address, etc. Contains external access permissions 7414 associated with notifier 7412. In certain embodiments, the external notifier 7412 includes one or more local communication devices that require external communication, such as a flow of a vehicle, an application, a network zone of the vehicle, an endpoint of a network zone, and the like. For example, the example gatekeeper interface circuit 7202 coordinates external communications based on the flow association of the communicating one of the first network zone and/or second network zone endpoints (e.g., (restricting to communications permitted according to access permissions 7414 and/or allowing external communications not excluded by external access permissions 7414). The example gatekeeper interface circuit 7202 coordinates external communications based on application associations of communication devices (e.g., external devices 5618 and/or endpoints), e.g., limits external communications to those permitted according to external access permissions 7414. and/or allow external communications not excluded by external access permission 7414. The example gatekeeper interface circuit 7202 provides external communication based on the communication device's network zone association (e.g., the network zone or source zone for the endpoint requesting the external communication, and/or the network zone or destination zone that is the target of the external communication). The communications may be adjusted, eg, limiting external communications to communications permitted according to external access permissions 7414 and/or allowing external communications that are not excluded by external access permissions 7414. In certain embodiments, the first network zone and the second network zone may be separate virtual local area networks of the vehicle and may have separate external access permissions 7414.

The example policy 5606 includes an external data quantity description (not shown), where the configuration circuit 5604 includes a gatekeeper interface circuit 7202 responsive to the external data quantity description. Exemplary external data volume descriptions include data limits for the application, where the gatekeeper interface circuit further regulates external communications based on the association of the communication device with the application. Applications may be vehicle operation-related applications (e.g., applications running on the vehicle and/or applications running on an external device in an interactive situation that can communicate with the vehicle) or non-vehicle operation-related applications (e.g., infotainment applications). driver applications, web browsing that utilizes the vehicle's network zone, third party applications that communicate with the vehicle, etc.). The exemplary external data volume description includes a data limit for an endpoint of one of the network zones, and the gatekeeper interface circuit coordinates the communication based on the source endpoint or destination endpoint of the coordinated communication. The exemplary external data volume description includes a data limit for the flow, and the gatekeeper interface circuit adjusts the external communication based on the association of the communication device with the flow.

Exemplary and non-limiting data limits include the amount of communication data associated with the selected time period (e.g., MB per hour, GB per month, etc.), the amount of communication data related to the selected vehicle operating conditions. (e.g., MB per trip, data rate during idle operation, data rate during rated operation, data rate during rapid transient operation, etc.), communication data corresponding to the data provider for applications, endpoints, and/or flows. bandwidth sharing of a transceiver utilized for communication; bandwidth capacity of a transceiver utilized for communication; bandwidth sharing of a transceiver channel (e.g., if a transceiver includes more than one channel, the bandwidth sharing is subject to limitations regarding the channels that provide external communication for applications, endpoints, and/or flows) and/or the bandwidth capacity of the transceiver's channels (e.g., if the transceiver supports more than one channel). or where bandwidth capacity is limited with respect to channels providing external communications for applications, endpoints, and/or flows).

Referring to FIG. 75, an example network usage description 7504 supports a network usage description 7502 that supports network zones 7504 and local communication devices such as endpoints, flows, vehicle functions, sensor devices, and/or applications. communication device description 7506. In this example, gatekeeper interface circuit 7202 further coordinates the external communication based on network usage description 7502 and the communication device associated with the coordinated communication (eg, corresponding to communication device description 7506). The example network usage description 7502 includes priorities 7508 for communication devices to coordinate external communications, associated flows 7510, associated vehicle functions 7512, associated applications 7514, and/or associated conditions or events 7516 (e.g., Triggering events for implementing aspects of policy 5606, vehicle conditions or other conditions that exist to enable implementation of aspects of policy 5606, and/or adjusting or suppressing aspects of policy 5606, if present. vehicle conditions or other conditions). The network usage description 7502 includes the bandwidth of the network zone 7504 available for use to support external communications, the data rate of the network zone 7504 available for use to support external communications, the network zone 7504 bandwidth limits (e.g., external communications can be suppressed or reduced if these are considered to result in a general overage) and/or network zone 7504 data rate limits (e.g., External communications may be suppressed, reduced, or delayed if they are considered to result in a general overload. In certain embodiments, the priority 7508 or information regarding external communications can be compared to the priority of on-vehicle communications utilizing the network zone, and external communications can be prioritized over on-vehicle communications, and external communications can be prioritized over on-vehicle communications. On-vehicle communications may be suppressed, reduced, or delayed until communications are provided. In certain embodiments, service requirements (e.g., QoS parameters) for endpoints, flows, applications, vehicle functions, etc. (e.g., local communication devices) on the vehicle may be considered in determining external communication permissions; External communications can be allowed while service requirements can be met.

Referring to FIG. 76, an example methodology 7600 for coordinating off-vehicle communications is shown. The example procedure 7600 includes an act 7602 of interpreting a policy that includes a network authorization description and/or an external data access description; an act 7604 of configuring a network interface circuit in response to the network authorization description; and an act 7606 of coordinating communications within and/or between networks. The example methodology 7600 includes an act 7608 of configuring a gatekeeper interface circuit responsive to an external data access description, and an act 7610 of coordinating off-vehicle communications using the gatekeeper interface circuit.

Referring to FIG. 79, an example system for controlling inter-network, intra-network, and/or off-vehicle communications utilizing a planned policy scheme is illustrated. The example system includes at least one network (first network zone 7902 and second network zone 7904 in the example set forth in FIG. 79), an external data routing description, and/or an external data service description. The vehicle 102 includes a policy management circuit 7906 that interprets a policy 7908 that includes external data communication parameters, such as an external data service description. The example system includes gatekeeper interface circuitry 7920 responsive to policy 7908 and configuration circuitry 7910 that coordinates communications between endpoints of network zones 7902 , 7904 and external communication portal 7916 . External communication portal 7916 is selectively coupled to external device 7918. External communication portals 7916 include external communication portals 7916 as described herein, including at least one or more of the examples set forth with respect to FIG. 41 and related description. In the example depicted in FIG. 79, a gatekeeper interface circuit 7920 is shown coupled to an external communication portal 7916. However, gatekeeper interface circuit 7920 may in any manner provide, for example, selected communications and/or selected processing, encapsulation, data file formats, communication protocols, authorization, and/or the present invention. Communications can be coordinated by further configuring network interface circuits 7912, 7914 to enable communications with any other coordination descriptions described throughout the disclosure. In the example shown in FIG. 79, a policy management circuit 7906, a configuration circuit 7910, and network interface circuits 7912 and 7914 arranged on the CND 108 are shown. As described elsewhere herein, the CND 108 can provide instructions to or otherwise coordinate the components, and the illustrated components (and/or the CND 108) The above CND 108 may be dispersed in any other location, wholly or partially separate from the CND .

Referring to FIG. 80, example policy 7908 includes one or more of secondary policy values 8006, primary policy values 8004, and/or default policy values 8002. The example configuration circuit 7910 defaults to the If, in response to policy value 8002, secondary policy value 8006 does not exist (and/or is not valid), then in response to primary policy value 8004, secondary policy value 8006 exists (and is valid). If so, use it to include a gatekeeper interface circuit 7920. The example configuration circuit 7910 is responsive to default policy value 8002 if primary policy value 8004 and/or secondary policy value 8006 is not present, and to primary policy value 8004 if secondary policy value 8006 is not present. In response, if the secondary policy value 8006 exists, it is used to include the network interface circuits 7912 and 7914. The example configuration circuit 7910 applies the policies, if any, in the order described (e.g., uses secondary policy value 8006, if present, and ignores any remaining policy values 8004, 8002). . The example configuration circuit 7910 applies more than one policy value if there is a match and/or match between the policy values (e.g., applies secondary policy value 8006 and also applies two of the primary policy values 8004). Apply the part that does not conflict with the next policy value 8006). In the example depicted in FIG. 80, the default policy value 8002 is a permanent storage policy (thus, e.g. policy). In certain embodiments, the primary policy value 8004 and/or the secondary policy value 8006 are easily updated in real time, e.g., stored as a data file (e.g., in a selected memory location, in a selected OS and/or stored with selected header information, metadata, etc. identifying each policy value as a primary policy value 8004 or a secondary policy value 8006); Contains policy values stored as part of calibration sets, trim sets, etc.

An example primary policy 8004 is a tool supplied policy, such as manufacturer tools, OEM tools, service tools, etc. In certain embodiments, the secondary policy values 8006 are downloaded policy values, e.g., policy values received through external communication portals from external devices, and policy values from web-based tools, cloud applications, etc. . The enumerated examples are non-limiting; any of the policy values can be received from any external communication portal. An exemplary implementation is provided upon installation of the CND 108 or associated control components (e.g., an initial image file applied to the controller including executable portions of the CND 108, policy management circuitry 7906, etc.), e.g., the entire command configuration. CND 108 includes default policy values 8002 that are generally not updated except as part of updating executable instructions provided to CND 108 and/or portions thereof. The example implementation includes a primary policy value 8004 provided during manufacturing, assembly, or other initial pre-mission service or assembly operations on the vehicle. Exemplary implementations may be provided as downloaded operations and/or during service operations, trimming operations, and/or application configuration operations (e.g., by an OEM, body manufacturer, or the like). Contains the next policy value 8006. The planned use of policy values 8002, 8004, 8006 provides minimally functional (and/or least risk) enforcement of the policy and communicates with the outside world, e.g. Sufficient functionality is provided to a device in the vehicle to download and/or act upon a replacement policy, such as policy value 8006. The planned use of policy values allows various stakeholders in manufacturing, remanufacturing, reconfiguration, service, sale or transfer, remission, or other vehicle-related operations to meet policy requirements (e.g., local communication devices policy updates; Ease of implementation allows ease of connectivity for third parties, owners/operators, fleet owners, and the like with interfaces to adjust policy values and resulting communication coordination actions. The planned use of policy values 8002, 8004, 8006 allows for ease of policy updates, verification, and enforcement. Deliberate use of policy values 8002, 8004, 8006 allows for policy re-initiation with only a small impact on the vehicle's mission (e.g., without controller reset activation, main executable instruction file adjustment, etc.). Adjusting configuration and/or communication coordination responses in real time, e.g., by geography (e.g., location of the vehicle), jurisdiction (e.g., location within the jurisdiction of the vehicle), and/or utilizing direct control of the vehicle. Allows the policy to be adjusted in response to adjustment characteristics such as activation in the event of possible incapacity (e.g., after an accident, towing event, sale, or other transfer). In certain embodiments, the planned policy values 8002, 8004, 8006 may be applied by one of several devices at different times, e.g., a first device applies the default policy value 8002; A primary policy value 8004 may be applied by a second device and a secondary policy value 8006 may be applied by a third device. In certain embodiments, a given external device applies more than one of the intentional policy values 8002, 8004, 8006 and/or the intentional policy values 8002, 8004, A later version of one of 8006 may be applied at a later point in time compared to application of an earlier version. In certain embodiments, there can be more than one version of a given policy value (e.g., secondary policy value 8006), depending on operating conditions (e.g., vehicle operating conditions, geography, jurisdiction, abnormal conditions). , and/or fault code status), a selection of these versions is utilized. In certain embodiments, a given policy value 8006 may include more than one version of a policy aspect, e.g., various data collections regarding a given local communication device, controller, flow, application, endpoint, etc. A version of the policy aspect is selected that provides the action and is responsive to the action condition.

Referring to FIG. 81, an example procedure 8100 for coordinating a network on a vehicle is shown. The example procedure 8100 includes an act 8102 of utilizing a secondary policy value, a primary policy value, and a default policy value, if present, in that order. Further, the example methodology 8100 further includes an act 8104 of interpreting the policy according to the utilized policy value, if the policy includes a network adjustment description, and an act 8106 of configuring the network interface circuitry in response to the policy. Further, the example methodology 8100 includes an act 8108 of activating the network interface circuit to coordinate the vehicle's network.

An example system includes a CND located within a vehicle and defined at least in part by an Ethernet switch (eg, CES) and/or a CAN gateway. The example CND encapsulates at least a portion of a CAN-based message from a CAN-based network within an Ethernet-based message, and/or encapsulates at least a portion of an Ethernet-based message from an Ethernet-based network within a CAN message. Encapsulate. The exemplary system includes configuration circuitry located within the vehicle to modify the CND in response to configuration command values from a service device external to the vehicle. Component circuitry may be located (in whole or in part) on the CES and/or CEG. The exemplary CES includes several ports on an Ethernet-based network, where the configuration circuitry connects a first of these several ports to a first of these several ports. (e.g., a monitor tool, service tool, other external device provides monitoring of the first port, and/or operation of the CND mirrors data on the first port). ). The example configuration circuit modifies CND by adjusting which ports are the first port (eg, monitor port) and/or the second port (eg, mirror port).

In additional or alternative examples (see, e.g., FIGS. 45-55 and related descriptions), the system configures CAN message generation circuitry to communicate over an Ethernet-based network and/or a CAN-based network. a service device (e.g., any external device described throughout this disclosure), in which case the CAN message generation circuit generates a CAN message, and the CAN message generation circuitry generates a CAN message from a device on board the vehicle (e.g., a local communication device) ) to send this CAN message. Exemplary CAN message generation circuits can send CAN messages regardless of service device connectivity, e.g., when the connection is to an Ethernet-based network, The keeper interface circuit and/or network interface circuit encapsulates and passes CAN messages across the Ethernet-based network, and de-encapsulates the messages as CAN messages on the CAN-based network.

In additional or alternative examples (see, e.g., FIGS. 45-55 and related descriptions), the system includes a service device that configures a test circuit that communicates over an Ethernet-based network and/or a CAN-based network. , in which case the test circuitry is such that the test devices are distributed across more than one network on the vehicle with respect to each other (e.g., a first device on an Ethernet-based network and a second device on a CAN-based network). generate one or more command values (to the device).

The exemplary system includes a first network zone of the vehicle having a first number of interconnections and a second network zone of the vehicle having a second number of interconnections. The example system further includes a centralized network device (CND) inserted between the first network zone and the second network zone, where the CND has an endpoint of the first network zone and a second network zone. configured to coordinate communications between endpoints of a network zone.

Certain further aspects of example systems are described below, any one or more of which may be incorporated within certain embodiments. The example system includes a first network zone positioned at a first risk exposure profile and a second network zone positioned at a second risk exposure profile, wherein the first network zone is positioned at a first risk exposure profile. The profile and the secondary risk exposure profile are distinctly different. Exemplary and non-limiting differences between these risk exposure profiles include one or more of the following: geometric distinctions, environmental distinctions, failure mode distinctions, dominant risk type distinctions, and/or dominant disturbance distinctions. include. An example system includes a distributed CND between a first portion located at a first location within the vehicle and a second portion located at a second location within the vehicle. In certain embodiments, the first portion of the CND coordinates communication between the first network zone endpoint and the second network zone endpoint, and in certain further embodiments, the system coordinates the communication between the first network zone endpoint and the second network zone endpoint. including a network redundant circuit for selectively providing control commands, wherein the second portion of the CND coordinates at least a portion of the communication between the first network zone endpoint and the second network zone endpoint. Selectively adjust in response to control commands.

An example system includes a CND with a configurable edge gateway (CEG), where communications between a first network zone endpoint and a second network zone endpoint are routed through the CEG. Additionally, the example system includes a CND with an Ethernet switch, where the first network zone includes an Ethernet network, and where the communication between the second network zone endpoint and the first network zone endpoint is Routed through an Ethernet switch. Additionally, the example system includes a CEG configured to provide communication between the first network zone endpoint and the second network zone endpoint to a port of the Ethernet switch. Exemplary and non-limiting network types for the second network zone include a Controller Area Network (CAN), a Media Oriented System Transport (MOST) network, a Local Interconnect Network (LIN), a FlexRay network, a Time-Triggered Protocol ( TTP) network, Low Voltage Differential Signal Transfer (LVDS) network, Audio Video Bridging (AVB) enabled network, customized versions of any one or more of these, and/or any one of these. or one or more of two or more proprietary versions. The example system includes a third network zone, where the CEG controls communication between the first network zone endpoint and the third network zone endpoint between the first network zone and the second network zone. A port of an Ethernet switch may be provided, which may be a shared port with zone communication, or may be a separate port.

The example system includes a CEG configured to encapsulate communications from a second network zone into Ethernet communications and provide the encapsulated communications to a port of an Ethernet switch. Encapsulated communications are communications that are provided as a payload of a communication, a processed payload of a communication, a portion of a frame of a communication, a processed portion of a frame of a communication, a whole frame of a communication, and/or a processed portion of a communication. including one or more of the total frames of the communication having one or more parts of the frame. In certain embodiments, the second network zone includes an electrical signal zone. The example CEG further performs analog/digital processing of communications with the second network zone and/or signal processing operations of communications with the second network zone. The example system is configured to generate a processed payload by performing one or more of payload unit modification, payload bit depth modification, payload normalization, and/or payload time shifting. Contains CEG. The example system includes one or more of the following: adjusting a timestamp of a communication, providing a timestamp of a communication, adjusting a source indicator of a communication, and/or adjusting a destination indicator of a communication. a CEG configured to generate a processed portion of a frame of communication by performing a CEG;

The example system includes a second network having a bus topology and/or a first network having a topology such as a serial topology, mesh topology, hub topology, ring topology, and/or star topology. The example system includes a first network that includes a first virtual local area network (VLAN) and a second network that includes a second VLAN.

An exemplary system includes a CND provided as a first portion at a first location of the vehicle and a second portion provided at a second location of the vehicle. The example system further includes a first portion of the CND positioned in the first risk exposure profile and a second portion of the CND positioned in the second risk exposure profile, where the first portion of the CND is positioned in the first risk exposure profile. The risk exposure profile of the first and second risk exposure profiles are clearly different. Exemplary and non-limiting differences between these risk exposure profiles include one or more of the following: geometric distinctions, environmental distinctions, failure mode distinctions, dominant risk type distinctions, and/or dominant disturbance distinctions. include.

The example system includes an external transmitter communicatively coupled to the CND and configured to communicate at least intermittently with an external device. The example system includes a CND configured to coordinate communications between a first network zone endpoint and an external device and between a second network zone endpoint and an external device.

An example system includes a first vehicle controller on a first network zone, a second vehicle controller on a second network zone, and a network redundant circuit that selectively provides coordinated control commands; In this case, the CND is further configured to adjust the step of coordinating communications between the first network zone and the second network zone in response to the coordination control command. Exemplary and non-limiting regulatory control commands include one of the following: an abnormal condition corresponding to the first vehicle controller, loss of a data element regarding the first vehicle controller, and/or loss of control function of the first vehicle controller. or two or more. Exemplary and non-limiting adjustments to coordinating communications include providing a first vehicle controller with a replacement data element, providing a second vehicle controller with a data element corresponding to a lost control function, and and/or include one or more acts such as providing data values normally available on a first network zone to a second network zone. Exemplary adjustments to regulating communication include suppressing communication of data values normally available on the first network zone in response to a loss control function of the first vehicle controller. The example system includes providing data values typically available on the first network zone to the second network zone as processed data values to the second vehicle controller. Loss of control functionality includes total or partial loss of control functionality normally performed by the first vehicle controller, loss of communication with the endpoint of the first network zone, loss of functionality of the first vehicle controller, and and/or loss of communication with the first vehicle controller.

The example system further includes a first vehicle controller positioned at a first risk exposure profile and a second vehicle controller positioned at a second risk exposure profile, where the first risk The exposure profile and the secondary risk exposure profile are distinctly different. Exemplary and non-limiting differences between these risk exposure profiles include one or more of the following: geometric distinctions, environmental distinctions, failure mode distinctions, dominant risk type distinctions, and/or dominant disturbance distinctions. include.

Certain alternative and/or additional coordination control commands may include: an abnormal condition corresponding to the first network zone, 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. Exemplary and non-limiting adjustments to coordinating communications include: routing at least one communication from a first network zone to a second network zone; at least one communication from the first network zone; shifting the at least one endpoint from the first network zone to the second network zone; shifting associated communications with the at least one endpoint from the first network zone to the second network zone; and/or shifting and/or repeating the associated communication with the at least one endpoint from the second network zone to the first network zone. Including the above.

An example system includes a vehicle controller on a first network zone and a CND at least partially colocated therewith.

The exemplary system includes non-transitory computer-readable instructions configured to perform at least a portion of the operations of coordinating communications when executed by a process of the vehicle controller, the first of the CNDs collocated with the vehicle controller. Contains parts.

An example system includes a first portion of a CND colocated with a vehicle controller and including an Ethernet switch, where a first network zone includes an Ethernet network, and an end point of a second network zone and a first Communications between the endpoints of the network zone are routed through an Ethernet switch that is located within the housing and/or on the same board as the vehicle controller.

The exemplary system includes a first portion of a CND that includes a configurable edge gateway (CEG) colocated with a vehicle controller, where the CND is located between a first network zone endpoint and a second network zone endpoint. communications are routed through the CEG, which is located in a housing with the vehicle controller and/or located on the same board as the vehicle controller.

The example system includes a second vehicle controller on a second network zone, where the CND has a first portion colocated with the vehicle controller and a second portion colocated with the second vehicle controller. including the part. The first portion and the second portion of the CND each perform at least a portion of the operation of coordinating communications when performed by an Ethernet switch, a configurable edge gateway (CEG), and/or a respective vehicle controller process. The non-transitory computer-readable instructions may include one or more of the non-transitory computer-readable instructions configured to execute the instructions. Each of the first and second portions of the CND is disposed in a housing with a respective vehicle controller and/or disposed on the same substrate as the respective vehicle controller.

The example system has a first network zone and a second network zone of a different type, and a centralized network device (CND) is inserted between the first network zone and the second network zone. a vehicle; a policy management circuit structured to interpret a policy including a network coordination description; and a configuration circuit structured to configure at least one network interface circuit in response to the policy; at least one network interface circuit structured to coordinate communications between the network zone endpoint and the second network zone endpoint.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a policy management circuit that receives a policy communication from an external device and interprets the policy by performing one of storing the policy or updating the stored policy in response to the policy communication. the external device is communicatively coupled to the policy management circuit through at least one of a wireless network connection or a cellular network connection, the policy management circuit storing the policy; or further structured to validate the policy prior to performing one of the steps of updating the stored policy, the policy management circuitry providing a notification to the external device in response to validating the policy. the policy includes at least one data collection parameter; and/or the policy supports at least one endpoint of the first network zone or the second network zone. The feature includes a permission value, and the permission value includes at least one permission value selected from a plurality of values consisting of a data collection permission value, a service publication permission value, a service periodic reception permission value, or an external communication permission value. including.

The example method includes interpreting a policy that includes a network coordination description and, in response to the network coordination description, coordinating communications between a first network zone endpoint of the vehicle and a second network zone endpoint of the vehicle. and the second network zone is of a different type than the first network zone.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes receiving a policy communication from an external device, performing one of storing a policy or updating a policy in response to the policy communication, storing the policy or updating the policy. providing a notification to an external device in response to verifying that the policy cannot be applied; verifying that the policy cannot be applied; determines that the policy violates security standards of previously stored policies or policy communications; determines that the policy cannot be enforced; or determines that the policy cannot be enforced due to network communication limitations; determining that the policy cannot be enforced due to data storage limitations; or determining that the policy cannot be enforced due to external communication limitations. adjusting the external communications of the endpoints of each of the first network zone and the second network zone in response to the policy; updating a local configuration file of the configurable Ethernet switch in response to one of the policy enforcement or the policy update; updating a local configuration file of the configurable edge gateway in response to one of enforcing the policy or updating the policy, between the first endpoint of the first network zone and the second endpoint of the second network zone; and/or the first endpoint of the first network zone and the first endpoint of the first network zone include performing one of an upsampling operation or a downsampling operation on the communication. Coordinating the communication between the two endpoints includes performing one of an upsampling operation or a downsampling operation on the communication.

An example system includes a first network zone of a vehicle that includes a first plurality of interconnected endpoints, a second network zone of the vehicle that includes a second plurality of interconnected endpoints, and a first network zone of the vehicle that includes a first plurality of interconnected endpoints. and a centralized network device (CND) inserted between the first network zone endpoint and the second network zone and configured to coordinate communications between the first network zone endpoint and the second network zone endpoint.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a first network zone positioned at a first risk exposure profile, a second network zone positioned at a second risk exposure profile, and a second network zone positioned at a first risk exposure profile and a second risk exposure profile. the first risk exposure profile and the second risk exposure profile are distinctly different; the distinction between the first risk exposure profile and the second risk exposure profile includes a geometric distinction; the distinction between the first risk exposure profile and the second risk exposure profile includes an environmental distinction; the distinction between the first risk exposure profile and the second risk exposure profile includes a failure mode distinction; the distinction between the exposure profiles includes a dominant risk type distinction; the distinction between the first risk exposure profile and the second risk exposure profile includes a dominant disturbance distinction; and a second portion located at a second location within the vehicle, the first portion of the CND is distributed between a first portion located at a location within the vehicle and a second portion located at a second location within the vehicle. and/or the second portion of the CND is configured to coordinate communications between the endpoint of the first network zone and the endpoint of the second network zone in response to a coordination control command. and a network redundancy circuit configured to selectively regulate at least a portion of the communication between the endpoints of the network and the second network zone and configured to selectively provide coordination control commands.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a CND including a configurable edge gateway (CEG), wherein communications between the first network zone endpoint and the second network zone are routed through the CEG, and the CND further includes an Ethernet switch. , the first network zone includes an Ethernet network, and the communication between the endpoints of the second network zone and the endpoints of the first network zone is routed through an Ethernet switch; a controller area network (CAN), a media oriented system transport ( MOST network, local interconnect network (LIN), FlexRay network, time-triggered protocol (TTP) network, low-voltage differential signaling (LVDS) network, and audio-video bridging (AVB)-enabled network. the CEG is configured to provide communication between the first network zone endpoint and the third network zone endpoint to the port of the Ethernet switch; The third network zone, CEG, is arranged between 1) the end of the first network zone and the end of the second network zone, and 2) the end of the first network zone and the end of the third network zone. The third network zone, CEG, is configured to provide communications between the first network zone endpoint and the third network zone endpoint to the second port of the Ethernet switch. the CEG is configured to encapsulate communications from the second network zone into Ethernet communications and provide the encapsulated communications to a port of the Ethernet switch; the CEG is further configured to encapsulate a payload of the communication from the second network zone, the CEG encapsulate the processed payload of the communication from the second network zone. the CEG is further configured to encapsulate at least a portion of a frame of communication from the second network zone, the at least a portion of the frame including a payload of the communication. the CEG is further configured to encapsulate the processed at least a portion of a frame of the communication from the second network zone, and/or the processed at least a portion of the frame is a payload of the communication. or one of the processed payloads of the communication. The example system may be configured such that the second network zone is a controller area network (CAN), a media oriented system transport (MOST) network, a local interconnect network (LIN), a FlexRay network, a time-triggered protocol (TTP) network, a the second network zone comprises a network type selected from a plurality of network types consisting of a voltage differential signal transfer (LVDS) network and an audio video bridging (AVB) capable network; the second network zone includes an electrical signal zone, the CEG performs analog/digital (A/D) processing of communications with the second network zone; the CEG is further configured to perform signal processing for communication with the second network zone; the CEG is further configured to perform signal processing for communication with the second network zone; The CEG is further configured to generate a processed payload by performing at least one of normalizing the payload and time-shifting the payload, the CEG adjusting a timestamp of the communication; generating the processed at least a portion of the frame of the communication by performing at least one of providing a timestamp, adjusting a source indicator of the communication, and adjusting a destination indicator of the communication; configured, and/or the CND further includes a second CEG, the second CEG transmitting the communication between the first network zone endpoint and the third network zone endpoint to a second network zone of the Ethernet switch. This third network zone is configured to serve ports of the network.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The exemplary system is characterized in that the second network includes a bus topology, the first network has a topology selected from a plurality of topologies consisting of a serial topology, a mesh topology, a hub topology, a ring topology, and a star topology. the first network includes a virtual local area network (VLAN) and the second network includes a second VLAN, the first portion of the CND is positioned in the first risk exposure profile; and a second portion of the CND is positioned at a second risk exposure profile, the first risk exposure profile and the second risk exposure profile being distinctly different; the distinction between the risk exposure profiles of the first risk exposure profile includes a geometric distinction; the distinction between the first risk exposure profile and the second risk exposure profile includes an environmental distinction; the first risk exposure profile and the second risk exposure profile includes a failure mode distinction; the distinction between the first risk exposure profile and the second risk exposure profile includes a dominant risk type distinction; and/or The distinction between the first risk exposure profile and the second risk exposure profile includes a dominant disturbance distinction. The example system includes an external transmitter communicatively coupled to the CND and configured to communicate at least intermittently with the external device; and configured to coordinate communications between two network zone endpoints and an external device.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a first vehicle controller on a first network zone, a second vehicle controller on a second network zone, and a CND that, in response to a coordinated control command, connects an endpoint of the first network zone and a second vehicle controller on a second network zone. a network redundancy circuit further configured to coordinate a step of coordinating communications between endpoints of two network zones and structured to selectively provide a coordination control command; an abnormal condition corresponding to the vehicle controller, the abnormal condition comprising loss of a data element, and the adjusted communication coordination step comprising providing a replacement data element to the first vehicle controller; the abnormal condition; includes a lost control function of the first vehicle controller, and the adjusted communication coordination step includes providing a data element corresponding to the control function of the first vehicle controller to the second vehicle controller; The loss control function comprises a partial or complete loss of control function, the loss control function utilizes data values provided by the endpoints on the first network zone, and the adjusted communication coordination phase providing the data value to the second vehicle controller, the step of coordinating the communication comprising the step of processing the data value from the endpoint on the second network zone into a processed data value; providing the processed data values to the first vehicle controller, a loss control function utilizing the processed data values, and a conditioned communication coordination step providing the processed data values to the second vehicle controller. the first vehicle controller is positioned in the first risk exposure profile, the first vehicle controller is positioned in the first risk exposure profile, and the first vehicle controller is positioned in the first risk exposure profile; is positioned in a second risk exposure profile, and the first risk exposure profile is distinctly different from the second risk exposure profile; the distinction includes at least one of a geometric distinction, an environmental distinction, a failure mode distinction, a dominant risk type distinction, and/or a dominant disturbance distinction, the coordination control command corresponding to a first network zone; and/or the abnormal condition includes 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 limit of the first network zone. In yet another example, the system includes the coordinated communication coordination step comprising: routing at least one communication from the first network zone to the second network zone; includes repeating the at least one communication from the first network zone to the second network zone, the conditioned communication coordination step repeating the at least one endpoint from the first network zone to the second network zone. wherein the adjusted communication coordination step comprises shifting or repeating the associated communication with the at least one endpoint from the first network zone to the second network zone; and/or the adjusted communications coordination step further comprises one of shifting or repeating communications associated with the at least one endpoint from the second network zone to the first network zone. Contains the characteristic of containing.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system is on a first network zone and a vehicle controller with which the CND is at least partially collocated, the CND performing at least a portion of the operations of coordinating communications when executed by a processor of the vehicle controller. the CND includes a first portion colocated with the vehicle controller including non-transitory computer readable instructions configured to configure the CND to include a first portion colocated with the vehicle controller including an Ethernet switch; the network zone includes an Ethernet network, communication between the second network zone endpoint and the first network zone endpoint is routed through an Ethernet switch, the Ethernet switch being disposed in the housing with the vehicle controller. the CND includes a first portion co-located with the vehicle controller; the CND includes a configurable edge gateway (CEG); Communication between the endpoint of the first network zone and the second network zone is routed through the CEG, the CEG being located in the housing with the vehicle controller, the CEG being on the same board as the vehicle controller. a second vehicle on a second network zone, wherein the CND includes a first portion colocated with the vehicle controller and further includes a second portion colocated with the second vehicle controller; The controller and/or the CND is communicatively configured to coordinate communications between the first network zone endpoint and the external device and between the second network zone endpoint and the external device. an external transmitter coupled and configured to at least intermittently communicate with the external device.

The example apparatus is configured to interpret vehicle data structured to interpret a service availability description that includes an availability data value from a first endpoint device on one of a first network or a second network of the vehicle. a service definition circuit and a vehicle structured to publish data service availability values responsive to service availability descriptions and generate data service value descriptions responsive to periodic reception requests for data service availability values; a data service management circuit that coordinates communication between the first network and the second network, generates a data service value responsive to the data service value description and the data value from the first endpoint device; a converged network device (CND) structured to publish data service values responsive to a data service.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus has a feature in which the CND is further structured to coordinate communications between an endpoint device on the first network and an endpoint device on the second network, the CND is further configured to coordinate communications between an endpoint device on the first network and an endpoint device on the second network; CND further structured to publish the data service value by providing network communications containing the generated data service value to a plurality of subscriber endpoint devices on one of the network or a second network; is further structured to provide network communications to a subscribed endpoint device by providing a data service value to a service broker, the vehicle data service management circuit comprising: a first network endpoint and a second network endpoint device; further structured to receive a periodic reception request from an endpoint on the network of the vehicle, the vehicle data service management circuit receiving at least one of the plurality of periodic reception requests from a service device external to the vehicle. wherein the service availability description further includes an authorization description, and the vehicle data service management circuit restricts publication of the data service availability value in response to the authorization description. The vehicle data service management circuit is further structured as follows: an end point identifier of the periodic reception request source, an application identifier of the periodic reception request source, a flow identifier of the periodic reception request source, a user identifier of the periodic reception request source, and further structured to restrict publication of a data service availability value in response to at least one of the subscription requestor's entity identifiers, the service availability description further comprising an authorization description; The vehicle data service management circuit is further structured to limit publication of the data service value in response to the authorization description, the vehicle data service management circuit further comprising: an end point identifier of the periodic reception request source; data in response to at least one of an application identifier of the periodic reception request source, a flow identifier of the periodic reception request source, a user identifier of the periodic reception request source, a service group identifier of the periodic reception request source, and/or an entity identifier of the periodic reception request source. further structured to limit publication of service values; the vehicle data service definition circuit interprets the service availability value and updates the service availability description in response to the service availability value; The service availability value further includes an authorization description, and the vehicle data service definition circuit is further structured to limit updating of the service availability description in response to the authorization description. The vehicle data service management circuit includes 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 and/or the vehicle data service definition circuitry further structured to limit updating of the service availability description in response to at least one of the identifier and the entity identifier of the service availability value provider. further structured to receive service availability values from a data collection management device external to the vehicle.

An example method includes interpreting a service availability description that includes an availability data value from a first endpoint device on one of a first network or a second network of a vehicle; publishing a data service availability value in response to a data service availability value; generating a data service value description in response to a periodic reception request for a data service availability value; The method includes generating a data service value responsive to the data value and publishing the data service value responsive to the data service value description.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The example method includes the step of publishing the data service value includes providing the data service value to a second endpoint device on the other of the first network or the second network, each of the publishing the data service value by providing 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; receiving a periodic reception request from an endpoint device and an endpoint device on a second network; receiving at least one of a plurality of periodic reception requests from a service device external to the vehicle; service availability; Where the description further includes an authorization description, the method further includes the step of restricting publication of the data service availability value in response to the authorization description, in response to the subscription requester's identifier. restricting publication of the data service availability value in response to the authorization description, where the service availability description further includes an authorization description; further comprising: restricting disclosure of the data service value in response to the identifier of the periodic reception request source; interpreting the service availability value; and writing a service availability description in response to the service availability value. updating the service availability description; if the service availability value further includes an authorization description, restricting the update of the service availability description in response to the authorization description; The method includes limiting the updating of the availability description and/or receiving service availability values from a data collection management device external to the vehicle.

An example system includes a vehicle having a first network and a second network, a first device on the first network, and a first device inserted between the first network and the second network. and a centralized network device (CND) structured to facilitate communication between the first network and the second network, the first network being of a different type than the second network. .

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a second device on a second network and structured to communicate with the first device through the CND, communicatively coupled to the CND and structured to adjust the configuration of the CND. characterized in that at least one of the first network and/or the second network is a controller area network (CAN)-based network; at least one of the networks is an Ethernet-based network, the Ethernet-based network includes a data bus architecture, the first network is a controller area network (CAN)-based network, and the second network is an Ethernet-based network. The CND includes a configurable edge gateway (CEG) structured to access a CAN-based network, an Ethernet switch structured to access an Ethernet-based network, and a CND configured to access a CAN-based network. provides a message to the Ethernet switch in response to a corresponding message on the CAN-based network, the CEG includes an encapsulated CAN message based on the corresponding message on the CAN-based network. the CEG is positioned in the first housing; the Ethernet switch is positioned in the second housing; the CEG is positioned on the first substrate; the Ethernet switch is positioned on the second board, and/or the first network zone is connected to a controller area network (CAN), media oriented system transport (MOST) network, local interconnect network (LIN) ), a FlexRay network, a Time Triggered Protocol (TTP) network, a Low Voltage Differential Signal Transfer (LVDS) network, and an Audio Video Bridging (AVB) capable network. Includes the feature of including network type. The example system includes a second network that includes an Ethernet-based network, and a CND that includes a configurable edge gateway (CEG) configured to access the first network and a configurable edge gateway (CEG) configured to access the first network. a structured Ethernet switch; the CEG provides a message to the Ethernet switch in response to a corresponding message on the first network; The CND is structured to provide an Ethernet message to an Ethernet switch as an Ethernet message containing an encapsulated message based on a message that is structured to manage access to an Ethernet-based network. the first device is a vehicle control device; the vehicle further comprises a wireless gateway device structured to facilitate communication between the CND and a third network remote from the vehicle; further characterized in that the CND is further inserted between the electrical actuator and the second network and further structured to provide an electrical command to the electrical actuator in response to a command value on the second network. The CND is further structured to convert a command value on the second network into an electrical command for the electrical actuator, the CND is further inserted between the electrical sensor and the second network, further structured to provide a sensed value responsive to the electrical response of the sensor on the second network; and/or the CND processes the electrical response and provides a sensed value based on the processed electrical response. The invention also includes the feature of being further structured to provide.

The example apparatus includes a first network interface circuit structured to interpret a first network data set having a first network format; and a first network data set configured to determine a message value from the first network data set; a conversion circuit structured to encode the message value into a second network data set having a network format of 2; and a second network structured to transmit the second network data set. the first network format and the second network format are vehicle data formats, and the first network format is different from the second network format.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus configures the first network interface circuit, the conversion circuit, and/or the first network interface circuit in response to a configuration command value from a device external to the vehicle that includes the first network interface circuit and the second network interface circuit. a configuration circuit structured to configure a network interface circuit of 2, a configuration command value is on the vehicle, a sampling rate value, a payload processing value, and/or a message value and an encapsulation description therefor; or one or more of the target devices for message values from the first network data set including the receiving device, the first network format and/or the second network format is a Controller Area Network (CAN) )-based, the first network format and/or the second network format are Ethernet-based, one of the first network format or the second network format is based on a controller area network ( CAN) based, the other of the first network format or the second network format being Ethernet based, the first network interface circuit and/or the second network interface circuit configured; the first network interface circuit and/or the second network interface circuit are integrated into an Ethernet switch; and/or the first network interface circuit, the conversion circuit. , and/or the second network interface circuit is compliant with Motor Industry Software Reliability Association standards and/or Automotive Open System Architecture standards. It includes the characteristic of

An example method includes interpreting a first network data set having a first network format, and determining a message value from the first network data set in response to interpreting the first network data set. encoding the message value in a second network data set having a second network format; and transmitting the second network data set, the second network data set having a first network format and a second the network format is a vehicle data format, and the first network format is different from the second network format.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes a first network interface circuit that interprets a first network data set, determines a message value from the first network data set, and encodes the message value in a second data set. a conversion circuit; a second network interface circuit for transmitting a second network data set; configuring the circuit and/or the conversion circuit based at least in part on the configuration command values, the first network format and/or the second network format being controller area network (CAN) based; characterized in that the first network format and/or the second network format are Ethernet-based; the first network format or the second network format is Controller Area Network (CAN)-based; the other of the network format and the second network format is Ethernet-based; and the step of encoding the message value within the second network data set includes encapsulating the message value. generating a first network data set by a first device on the vehicle; and/or interpreting a second network data set by a second device on the vehicle; configuring based on the command value includes an encapsulation scheme for the message value from the first network data set, including an address description for the message value from the first network data set, the first network data and/or including at least one operation on the data values of the message values from the first network data set.

An example system includes a vehicle having a first network and a second network of a different type, a first network located within the vehicle and structured to facilitate communication over the first network. a second device located within the vehicle and structured to facilitate communication over the second network; a second device located within the vehicle and configured to facilitate communication over the second network; a converged network device (CND) structured to facilitate communication between the first network and the second network.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. An exemplary system includes a configuration circuit positioned within a vehicle and configured to modify a CND in response to a configuration command value from a service device external to the vehicle; and/or located in a second device, the first device being an Ethernet switch having a plurality of ports on the first network, and the configuration circuit connecting a first port of the plurality to a first port of the plurality of ports. further structured to mirror the second port of the CND, the configuration circuitry being configured to mirror which of the one or more portions of the CND the further structured to modify the CND by selectively configuring the device as defined by the device, communicating on the first network and/or the second network; a service device, a first network and/or a test circuit configured to generate one or more test command values for testing a fourth device on a second network and a fourth device on a second network; a controller area network (CAN) message generation circuit structured to communicate over a second network, generate a CAN message, and transmit the CAN message toward a third device onboard the vehicle; characterized in that the first and/or second network is a Controller Area Network (CAN)-based network; characterized in that the first and/or second network is an Ethernet-based network; the device is a configurable edge gateway (CEG); the first device is an Ethernet switch; and/or the first device is a configurable edge gateway (CEG) and the second device is an Ethernet switch. Includes the feature of being a switch.

The example apparatus includes a first network interface circuit structured to interpret a first network data set having a first network format; and a first network data set configured to determine a message value from the first network data set; a conversion circuit structured to encode the message value into a second network data set having a network format of 2; and a second network structured to transmit the second network data set. a first device and/or a second device comprising an interface circuit, the first network interface circuit, the conversion circuit, and the second network interface circuit being structured such that the first network interface circuit, the conversion circuit, and the second network interface circuit are both integrated into a vehicle. and includes the feature that the first network format is different from the second network format.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus is configured to modify the first network interface circuit, the translation circuit, and/or the second network interface circuit in response to configuration command values defined by the first device and/or the second device. a component circuit structured in such a manner that which of the one or more portions of the first network interface circuit, the conversion circuit, and/or the second network interface circuit is connected to the first device and/or the first network format and/or the second network format being controller area network (CAN) based; characterized in that the first network format and/or the second network format are Ethernet-based; the first network format or the second network format is controller area network (CAN)-based; the other of the first network format and the second network format is Ethernet-based; the first device is a configurable edge gateway (CEG); the first device is an Ethernet switch. and/or the first device is a configurable edge gateway (CEG) and the second device is an Ethernet switch.

An example method includes interpreting a first network data set having a first network format by a first interface circuit of a centralized network device (CND) and responsive to interpreting the first network data set. determining message values from the first network data set by a conversion circuit of the CND; and converting the message values into a second network data set having a second network format different from the first network format. and transmitting a second network data set by a second interface circuit of the CND, the CND being at least partially defined by the first device and/or the second device. , the first device and/or the second device are located inside the vehicle.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes interpreting a configuration command value and modifying a CND in response to the configuration command value, wherein modifying the CND is performed on a first interface circuit, a conversion circuit, and/or a second interface circuit. generating the configuration command external to the vehicle; , transmitting this configuration command value towards a CND, generating a test command value external to the vehicle and transmitting this test command value towards a CND to a third network on the first network or the second network. performing a test procedure involving a device in response to a test command; the first network format and/or the second network format being controller area network (CAN) based; the first network format or the second network format is controller area network (CAN) based; the other of the two network formats is Ethernet-based, the first device is a configurable edge gateway (CEG), the first device is an Ethernet switch, and/or The first device is a configurable edge gateway (CEG) and the second device is an Ethernet switch.

An example system includes a vehicle having a first network and a second network of a different type; a vehicle having a first network and a second network of a different type; a first network and a second network; generating network status data by monitoring communications of one or more devices on the first and/or second network, and transmitting the network status data to a sensor device external to the vehicle. includes a converged network device (CND) structured to transmit to and from the network.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system is further configured such that the CND includes a plurality of ports on the first network and is configured to mirror at least a first port of the plurality with at least a second port of the plurality. structured, the CND includes a plurality of ports on a first network and assigns a first device of the plurality of devices on the second network to one port of the plurality; further structured to transmit network status data to a sensor device on the first network through at least one port of the plurality, the second network having a bus topology; has a star topology, the CND is further structured to modify the network status data, the CND selectively modifies the network status data in response to a data selection command value; or including in the network status data data corresponding to at least one device identified by the data selection command value on the second network, selectively modifying the network status data in response to the data selection command value; including in the network status data data corresponding to one or more systems of the vehicle identified by the selected command value; selectively modifying the network status data in response to the data selection command value; wherein the network status data is further structured to include data corresponding to at least one protocol identified by the network status data, the identified protocol including one of a controller area network (CAN) or an on-vehicle diagnostic (OBD). the first network and/or the second network are controller area network (CAN) based; the first and/or the second network are Ethernet based; and/or the first network or the second network is controller area network (CAN) based and the other of the first network and the second network is Ethernet based.

The apparatus includes a first network interface circuit structured to interpret first communication data of a first network mounted on the vehicle and a first network interface circuit mounted on the vehicle and of a different type than the first network. a second network interface circuit structured to interpret second communications data of a second network and generate network status data by monitoring the interpreted first and/or second communications; and a network status circuit structured to transmit network status data, the first and/or second network interface circuit being further structured to transmit network status data.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The exemplary apparatus is configured such that the first network interface circuit has a plurality of ports, and the apparatus configures at least a first port of the plurality to mirror at least a second port of the plurality. further comprising a configuration circuit structured such that the first network interface circuit has a plurality of ports, and the apparatus has a selected port of the plurality of ports and a device on the second network. interpreting a port assignment command value that identifies both of the second communication data, identifying a portion of the second communication data that corresponds to the identified device, and transmitting the identified portion of the second communication data through the selected port. comprising a configuration circuit structured to modify the network status data, the configuration circuit selectively modifying the network status data in response to a data selection command value; further structured to include in the network status data data corresponding to at least one device identified by the data selection command value, the configuration circuit selectively selecting the network status data in response to the data selection command value; and further structured to include in the network status data data corresponding to one or more systems of the vehicle identified by the data selection command, the configuration circuitry comprising: further structured to selectively modify the network status data in response to include data corresponding to at least one protocol identified by the data selection command value in the network status data; , the first and/or second communication data has a format based on a controller area network (CAN) protocol; and/or the second communication data has a format based on an Ethernet protocol; and/or the first communication data or the second communication data has a format based on a Controller Area Network (CAN) protocol; The other of the first and second communication data has a format based on an Ethernet protocol.

An example method includes the steps of: interpreting first communication data of a first network onboard a vehicle; and second communication data of a second network onboard the vehicle that is of a different type than the first network. generating network status data by monitoring the interpreted first and second communication data; and transmitting the network status data.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes configuring a first port of a plurality of ports located within a vehicle interior to mirror a second port of the plurality, and interpreting the first communication data. interpreting a port assignment value that identifies both a port selected from a plurality of ports arranged inside the vehicle and a device on a second network, and further interpreting the first communication data; identifying a portion of the second communication data that corresponds to the identified device and transmitting the identified portion of the second communication data through the selected port; modifying the network status data; the step of modifying the network status data is responsive to the selection command value and includes the step of including in the network status data data corresponding to the at least one device identified by the data selection command value, the step of modifying the network status data comprising: including in the network status data data responsive to the selected command value and corresponding to one or more systems of the vehicle identified by the data selection command value, the step of modifying the network status data comprising: and including in the network status data data corresponding to at least one protocol identified by the data selection command, wherein the identified protocol is connected to a controller area network (CAN) or a controller area network (CAN). the first and/or second communication data have a format based on a controller area network (CAN) protocol; , the first communication data or the second communication data has a format based on the Controller Area Network (CAN) protocol, and/or the first communication data or the second communication data has a format based on the Controller Area Network (CAN) protocol; The other one has a format based on the Ethernet protocol.

An example system includes a vehicle having a first network and a second network of a different type, and a plurality of ports on the first network inserted between the first network and the second network. a centralized network device (CND), the CND facilitating communication between the first network and the second network, the first port of the plurality of ports communicating with the second port of the plurality of networks; mirror.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system allows the CND to determine which of the plurality of ports is the first port based at least in part on a port selection command value from a sensor device external to the vehicle; characterized in that the first port of the plurality mirrors the third port of the plurality. Features: a sensor device external to the vehicle and structured to monitor one or more devices on the first and/or second network by communicatively coupling with the first port; assigns a first device of the plurality of devices on the second network to a first assigned port of the plurality of ports and identifies communication data supporting the first device on the second network. wherein the CND is further structured to transmit identified communication data supporting the first device over the first network through the first assigned port; assigning a second device of the devices to a second assigned port of the plurality of ports; identifying communication data supporting the second device on the second network to support the second device; the CND is further structured to send the second device of the plurality of devices on the second network over the first network through the second assigned port; identifying communication data supporting a second device on a second network and transmitting the identified communication data supporting the second device onto the first network through the first assigned port; the CND further includes an Ethernet switch configuring the plurality of ports; the first network is Ethernet-based; the second network is area network (CAN) based and/or the first network is Ethernet based and the second network is controller area network (CAN) based.

An example apparatus includes: a first network interface circuit having a plurality of ports structured to interpret first communication data of a first network onboard the vehicle; a second network interface circuit structured to interpret second communication data of a second network that is of a different type than the network; and a second network interface circuit structured to interpret second communication data of a second network for transmission over the first network. a conversion circuit structured to transfer data to a first network interface circuit through at least one port of the plurality of ports, the first port of the plurality of ports being connected to a second network interface circuit of the plurality of mirror ports.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example device interprets the port selection command value and determines which port of the plurality of ports is a first port and/or which port of the plurality of ports is a second port. a configuration circuit structured to assign in response to a port selection command value, interpreting the port assignment command value and identifying both a port of the plurality of assigned ports and a device on a second network; a configuration circuit structured to identify a portion of the second communication data corresponding to the assigned device and transmit the identified portion of the second communication data through the assigned port, the first communication data being Ethernet-based; the second communication data is controller area network (CAN) based; and/or the first communication data is Ethernet based and the second communication data is controller area network (CAN) based. It includes the feature of being area network (CAN) based.

An example method includes interpreting first communication data of a first network onboard a vehicle by a plurality of ports of a centralized network device (CND); interpreting the second communication data of the second network of type by the CND; forwarding the second communication data by the CND to the first network through the plurality of ports; mirroring the port through a second port of the plurality.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The example method interprets a port selection command value and determines which port of the plurality of ports is a first port and/or which port of the plurality of ports is a second port. assigning in response to the port selection command value, interpreting the port assignment command value that identifies both the assigned port of the plurality of ports and a device on the second network; and transmitting the identified portion of the second communication data through the assigned port, the first network being Ethernet-based; and/or the first network is Ethernet based and the second network is Controller Area Network (CAN) based.

An example system is inserted between a vehicle having a first network and a second network of a different type, and facilitates communication on the second network; a centralized network device (CND) structured to coordinate a second network.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system is characterized in that the CND is further structured to constrain the amount of communication data that is allowed to pass from the first network to the second network, the constraint being at least partially in a period of time. the constraint is based on the saturation rate of the second network; the constraint is based on the maximum bandwidth of one of the first network or the second network; wherein the CND is further structured to constrain the amount of communication data that is allowed to pass to the first network; wherein the CND is further structured to constrain access of one or more first devices on the second network to one or more second devices on the first network. wherein the CND is further structured to prioritize portions of communication data to and from the first network and the second network; characterized in that the CND is further structured to downsample devices on the second network with respect to the first network; the at least one device having a transmission frequency based at least in part on attributes of the first network and/or devices thereon; the first network is Ethernet-based, the second network is Controller Area Network (CAN)-based, and/or the first network is Ethernet-based; and includes the feature that the second network is controller area network (CAN) based.

The apparatus includes a first network interface circuit structured to interpret first communication data of a first network mounted on the vehicle and a first network interface circuit mounted on the vehicle and of a different type than the first network. a second network interface circuit structured to interpret second communication data of a second network; and a second network interface configured to direct the first communication data for transmission over the second network. coordinating the second network interface circuit with a conversion circuit structured to transfer the second communication data to the first network interface circuit for transmission over the first network; and an adjustment circuit structured as follows.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus has the feature that the regulating circuit is further structured to constrain the amount of the first communication data transferred to the second network interface circuit, the constraint being based at least in part on a time period. The constraint is based on a saturation rate of the second network, and the regulation circuit is further structured to constrain the amount of second communication data transferred to the first network interface circuit. , the conditioning circuit corresponds to a device on the first network and encodes one or more portions of the first communication data for transmission to the one or more devices on the second network. further structured to constrain transmission by the second network interface circuit of the controller, the regulating circuit corresponding to a device on the second network to one or more devices on the second network; characterized in that the conditioning circuit is further structured to constrain transmission by the first network interface circuit of one or more portions of the encoded second communication data for transmission of the first and second communication data. and/or the second communication data is further structured to prioritize portions of the communication data; the first communication data is Ethernet-based; ) based and/or the first communication data is Ethernet based and the second communication data is Controller Area Network (CAN) based.

An example method includes the steps of: interpreting first communication data of a first network onboard a vehicle; interpreting second communication data of a second network onboard a vehicle; The method includes forwarding the communication data to the second network and/or the second communication data to the first network, and adjusting the second network.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The example method includes constraining the transfer of the first communication data to the second network, the constraining step being based at least in part on a time period, the constraining step further comprising a saturation rate of the second network. the constraining step is further based at least in part on a maximum bandwidth of the second network; the adjusting step is based at least in part on a maximum bandwidth of the second network; the adjusting step includes restricting access of the one or more devices on the second network to the one or more devices on the first network; the adjusting step includes prioritizing a portion of the first and/or second communication data; the adjusting step includes prioritizing a portion of the first and/or second communication data; the adjusting step includes upsampling at least a portion of the first communication data; the first network is Ethernet-based; two networks are Controller Area Network (CAN) based and/or the first network is Ethernet based and the second network is Controller Area Network (CAN) based; Contains features.

An example system is inserted between a vehicle having a first network and a second network and between the first network and the second network to facilitate communication between the first network and the second network. and a centralized network device (CND) structured to coordinate, the first network being of a different type than the second network.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system is characterized in that the CND is further structured to constrain the amount of communication data that is allowed to flow into and out of the first network and the second network, the constraint being configured for a period of time. the amount of data communicated is from the first network to the second network and is less than the saturation rate of the second network; the constraint is at least partially based on the first or second network; a CND restricting one or more devices on the other of the first and second networks from accessing one or more second devices on the other of the first and second networks; wherein the CND is further structured to prioritize portions of communication data to and from the first network and the second network; further structured to downsample at least a portion of the data; the first network being Ethernet-based; and the second network being Controller Area Network (CAN)-based. , and/or the first network is Ethernet-based and the second network is Controller Area Network (CAN)-based.

The example apparatus includes a first network interface circuit structured to interpret first communication data of a first network on board the vehicle and a first network interface circuit on board the vehicle that is different from the first network. a second network interface circuit structured to interpret second communication data of a second network, the first communication data being transmitted over the second network; a conversion circuit structured to transfer the second communication data to the network interface circuit and/or transfer the second communication data to the first network interface circuit for transmission over the first network; and/or a regulating circuit structured to regulate the first and/or second communication data transfer stage.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus is characterized in that the adjustment circuit is further structured to constrain the amount of first and/or second communication data that is allowed to be transferred by the conversion circuit, the constraint being at least for a period of time. the quantity is of the first communication data from the first network interface circuit to the second network interface circuit and is less than the saturation rate of the second network; the constraint; is a downsampling operation of the communication from the first network interface circuit to the second network interface circuit; constraining one or more portions of the encoded first communication data for transmission to two or more devices, and/or corresponding to a device on the second network; The conditioning circuit is further structured to constrain one or more portions of the encoded second communication data for transmission to the one or more devices, the second communication data is further structured to prioritize a portion of the communication data; the first communication data is Ethernet-based; the second communication data is Controller Area Network (CAN)-based; and/or the first communication data is Ethernet-based and the second communication data is Controller Area Network (CAN)-based.

An example method includes the steps of: interpreting first communication data of a first network onboard a vehicle; interpreting second communication data of a second network onboard a vehicle; forwarding the communication data to a second network and/or the second communication data to the first network; and coordinating the transfer of the first communication data and/or the second communication data. .

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The example method includes constraining the step of transmitting the first communication data to the second network and/or the step of transmitting the second communication data to the first network, wherein the constraining step includes at least a portion of the time period. characterized in that the constraining step is further based at least in part on the saturation rate of the first and/or second network; wherein the regulating step includes restricting the device from accessing the one or more devices on the other of the first and second networks, the regulating step the adjusting step includes downsampling at least a portion of the first communication data; the first network is Ethernet-based; the network is controller area network (CAN) based, and/or the first network is Ethernet based and the second network is controller area network (CAN) based. including.

An exemplary system includes a vehicle having an Ethernet-based network and a Controller Area Network (CAN)-based network, and a system configured to be located within the vehicle, connected to the CAN-based network, and configured to control operation of components of the vehicle. A structured CAN vehicle control device and an Ethernet vehicle control device located within the vehicle interior and structured to be connected to an Ethernet-based network and in electrical communication with the CAN vehicle control device and located within the vehicle interior. an Ethernet switch connected to an Ethernet-based network, the Ethernet switch having a plurality of physical ports, at least one of which forms part of a physical network path between the Ethernet switch and the Ethernet vehicle control device; a CAN gateway located in the vehicle and connected to the CAN-based network and the Ethernet switch; and defined at least in part by the Ethernet switch and/or the CAN gateway, for data messages between the Ethernet-based network and the CAN-based network. and a network convergence circuit structured to facilitate electronic communication between an Ethernet vehicle control device and a CAN vehicle control device by converting and forwarding.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a first of a plurality of features wherein the network centralized circuit is selectively configurable through configuration command values transmitted over an Ethernet-based network from a service device external to the vehicle. The physical port selectively mirrors a second physical port of the plurality in response to a configuration command value, wherein the configuration circuitry determines which of the one or more portions of the CND is an Ethernet switch and and/or configured to modify the CND by selectively configuring the CAN gateway, the service device communicates over an Ethernet-based network, and the CAN vehicle control device. and/or the vehicle components include a test circuit structured to generate a test command value that determines the vehicle engine, the vehicle transmission, the vehicle braking system, the vehicle fuel system, and/or the vehicle component. Related to electrical systems.

An example apparatus includes an Ethernet switch having a first network interface circuit that includes a plurality of physical ports each structured to interpret Ethernet-based network data and determine a message value from the Ethernet-based network data. and a CAN gateway having a conversion circuit structured to encode the message value into controller area network (CAN) data and a second network interface circuit structured to transmit the CAN data. 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, and the Ethernet switch and the CAN gateway are both within the vehicle. and structured so as to be incorporated.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus is defined by an Ethernet switch and/or a CAN gateway and is structured to modify the first network interface circuit, the conversion circuit, and/or the second network interface circuit in response to configuration command values. a configuration circuit configured to selectively configure a first physical port of the plurality to selectively mirror a second physical port of the plurality in response to a configuration command value; and/or the configuration circuit is further configured to selectively configure which of the one or more portions of the conversion circuit is defined by the Ethernet switch and/or the CAN gateway. Contains the characteristic of being structured.

An example method includes interpreting an Ethernet-based data set by one or more physical ports of a first interface circuit of an Ethernet switch located within the vehicle interior, an Ethernet switch located within the vehicle interior; or determining a message value from an Ethernet data set by a conversion circuit located on a Controller Area Network (CAN) gateway; and transmitting this CAN data set through a second interface circuit of the CAN gateway.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes interpreting a configuration command value and modifying the conversion circuit in response to the configuration command value, the step of modifying the conversion circuit determining which of the one or more portions of the conversion circuit is connected to an Ethernet network. generating a configuration command value external to the vehicle and transmitting the configuration command value towards an Ethernet switch; , generates a test command external to the vehicle and sends this test command towards an Ethernet switch to respond to the test command in a test procedure involving devices on a CAN-based network connected to a CAN gateway. transmitting the CAN-based data set by a second interface circuit of the CAN gateway on a CAN-based network located within the vehicle, the vehicle control device controlling a component of the vehicle; transmitting a CAN-based data set to a vehicle, the Ethernet-based data set being generated by a vehicle control device located on an Ethernet-based network located within the vehicle and controlling a component of the vehicle; and/or upsampling the CAN-based data set.

An exemplary system includes a vehicle having an Ethernet-based network and a controller area network (CAN)-based network and an Ethernet switch located within the vehicle and structured to facilitate communication over the Ethernet-based network. a CAN gateway located within the vehicle and structured to facilitate communication on a CAN-based network; and a CAN gateway located within the vehicle and defined at least in part by an Ethernet switch and/or a CAN gateway. encapsulating at least a portion of the CAN-based message from the CAN-based network within the Ethernet-based message; and further encapsulating at least a portion of the Ethernet-based message from the Ethernet-based network within the CAN message. Converged network devices (CNDs) structured in

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. An exemplary system includes a configuration circuit located within a vehicle and configured to modify a CND in response to a configuration command value from a service device external to the vehicle, the configuration circuit comprising an Ethernet switch and/or or located in a CAN gateway, wherein the Ethernet switch has a plurality of ports on an Ethernet-based network, and the configuration circuit connects a first port of the plurality to a second port of the plurality. further structured to mirror the CND, the configuration circuit selectively configuring which of the one or more portions of the CND is defined by the Ethernet switch and/or the CAN gateway; communicating over an Ethernet-based network and/or a CAN-based network, the first device on the Ethernet-based network and the CAN-based network further comprising a service device constituting a test circuit structured to generate one or more test command values for testing a second device on each other and/or an Ethernet-based and/or CAN-based network. and a service device configured to communicate with the CAN message generation circuit and configured to generate a CAN message and transmit the CAN message to a device onboard the vehicle.

The example apparatus includes a first network interface circuit structured to interpret a first set of Ethernet data and transmit a second set of Ethernet data; and a first controller area network (CAN) set of data. a second network interface circuit structured to interpret and transmit a second CAN data set; and a second network interface circuit structured to determine a first message value from the first Ethernet data set and transmit the first message value to the CAN a conversion circuit structured to encapsulate within a data set and to determine a second message value from the second CAN data set to encapsulate the second message value within the second Ethernet data set; and the first network interface circuit, the conversion circuit, and the second network interface circuit are both defined by an Ethernet switch and/or a CAN gateway structured to be integrated into the vehicle. .

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The example apparatus is defined by an Ethernet switch and/or a CAN gateway and is structured to modify the first network interface circuit, the conversion circuit, and/or the second network interface circuit in response to configuration command values. which of the one or more parts of the first network interface circuit, the conversion circuit, and/or the second network interface circuit is defined by the Ethernet switch and/or the CAN gateway; wherein the first network interface circuit is defined by the Ethernet switch and the second network interface circuit is defined by the CAN gateway; the conversion circuit is further structured to selectively configure the CAN gateway; and/or the conversion circuit is defined by an Ethernet switch.

An example method includes interpreting a first Ethernet data set by a first interface circuit of a centralized network device (CND) and converting a first message value from the first Ethernet data set by a conversion circuit of the CND. encapsulating the first message value within a first controller area network (CAN) data set by a conversion circuit; and transmitting the first CAN data set by a second interface circuit of the CND. interpreting the second CAN data set by the second interface circuit; determining a second message value from the second CAN data set by the conversion circuit; encapsulating the value within a second Ethernet data set; and transmitting the second Ethernet data set by the first interface circuit; defined at least in part by the gateway.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes interpreting a configuration command value and modifying a CND in response to the configuration command value, wherein modifying the CND is performed on a first interface circuit, a conversion circuit, and/or a second interface circuit. generating configuration command values external to the vehicle; Sending this configuration command value towards the CND includes generating a test command value external to the vehicle and transmitting this test command value towards the CND to a device on an Ethernet-based network and/or a CAN-based network. carrying out a test procedure in response to the test command value, the first network interface circuit being defined by an Ethernet switch and the second network interface circuit being defined by a CAN gateway, the conversion circuit being defined by a CAN gateway; and/or the conversion circuit is defined by an Ethernet switch.

The exemplary system includes a vehicle having an Ethernet-based network and a Controller Area Network (CAN)-based network, and a vehicle having an Ethernet-based network and a Controller Area Network (CAN)-based network, which communicates through the CND to and/or from devices on the Ethernet-based network and/or the CAN-based network. inserted between an Ethernet-based network and a CAN-based network structured to monitor and generate network status data and transmit this network status data towards sensor devices external to the vehicle. a centralized network device (CND), network status data including the bandwidth through the CND, the number of messages in a communication through the CND received and/or transmitted by one of the one or more devices; or based at least in part on the number of communication errors.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a CND including a plurality of ports on an Ethernet-based network and configured to mirror at least a first port of the plurality of ports of the plurality of ports. A further structured feature is provided in which the CND includes a plurality of ports on an Ethernet-based network; the Ethernet-based network having a bus topology; the Ethernet-based network having a bus topology; A feature in which the CND is further structured to modify network status data, wherein the CND selectively modifies network status data in response to a data selection command value; The network status data is further structured to include data corresponding to at least one device identified by the selection command value, the CND selectively modifying the network status data in response to the data selection command value. and the CND is further structured to include data corresponding to one or more systems of the vehicle identified by the data selection command value in the network status data; The network status data is further structured to selectively modify the status data to include data corresponding to at least one protocol identified by the data selection command value, the protocols being TCP, UDP, and AVB. and/or the network status data supports multicast network traffic and/or broadcast network traffic.

An example apparatus includes a first network interface circuit structured to interpret and transmit Ethernet communication data and a second network structured to interpret and transmit Controller Area Network (CAN) communication data. an interface circuit, a conversion circuit inserted between the first network interface circuit and the second network interface circuit and structured to convert Ethernet communication data to CAN communication data and vice versa; a network status circuit structured to generate network status data by monitoring communication data and CAN communication data, wherein the network status data is configured to generate network status data by monitoring the communication data and the CAN communication data, the network status data being configured to generate network status data by monitoring the communication data and the CAN communication data; The method is based at least in part on the number of messages in the addressed Ethernet communication data and/or CAN communication data and/or the number of communication errors.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. The exemplary apparatus is configured such that the first network interface circuit has a plurality of ports, and the apparatus configures at least a first port of the plurality to mirror at least a second port of the plurality. further comprising a configuration circuit structured to modify the network status data, the configuration circuit selectively modifying the network status data in response to the data selection command value. , further structured to include in the network status data data corresponding to at least one device identified by the data selection command value, the configuration circuitry selecting the network status data in response to the data selection command value. further structured to include in the network status data data corresponding to one or more systems of the vehicle identified by the data selection command; and/or the protocol is further structured to selectively modify the network status data in response to include data corresponding to the at least one protocol identified by the data selection command value in the network status data; , TCP, UDP, and AVB.

An example method includes converting first Ethernet communication data to first controller area network (CAN) communication data within a vehicle; and converting second CAN communication data to second Ethernet communication data within the vehicle. generating network status data by monitoring the first and second Ethernet communication data and CAN communication data; and transmitting the network status data.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes configuring a first Ethernet port of a plurality of ports located within a vehicle interior, interpreting the first Ethernet communication data to mirror a second port of the plurality. and/or modifying network status data.

An example method includes generating a message value by a first vehicle control device on a first network located within the vehicle; and transmitting the message value to a second vehicle control device on the second network, and performing a control action on the vehicle at the second vehicle control device in response to receiving the message value.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The exemplary method includes the feature that the first vehicle control device and/or the second vehicle control device are sensors, controllers, and/or actuators, the first vehicle control device and/or the second vehicle control device corresponds to a vehicle engine system, a vehicle fuel system, a vehicle infotainment system, a vehicle environmental system, a vehicle safety system, a vehicle security system, a controller, and/or an actuator; is a Controller Area Network (CAN)-based network; the second network is an Ethernet-based network; the first network is a Controller Area Network (CAN)-based network; is an Ethernet-based network; the first network is an Ethernet-based network; the second network is a Controller Area Network (CAN)-based network; the first network is an Ethernet-based network; , the second network being a controller area network (CAN) based network; transmitting the message value over an intermediate network inserted between the first network and the second network; The intermediate network is of a different type than the first network; The intermediate network is of a different type than the second network; The intermediate network is of a different type than the first network; The intermediate network is of a different type than the second network; characterized in that the first and second networks are controller area network (CAN)-based networks and the intermediate network is an Ethernet-based network; the first and second networks are of different types; based network and the intermediate network is a controller area network based network, wherein the control actuation involves obtaining data from a component of the vehicle, activating a component of the vehicle, and/or the intermediate network being a controller area network based network; and/or the vehicle control operation comprises controlling a control device, such as a vehicle fuel system, a vehicle infotainment system, a vehicle environmental system, a vehicle safety system, and/or a vehicle security system. This includes the feature of supporting many systems.

An example method includes generating a message value by a first vehicle control device on a first network located within the vehicle; 2 to an external device external to the vehicle; and interpreting the message value by the external device.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. An example method includes testing a first vehicle control device with an external device, configuring the first vehicle control device with the external device, configuring a second vehicle control device on a second network with the external device. configuring the second vehicle control device is responsive to interpreting a message value generated by the first vehicle control device, inserted between the first network and the second network; converting the message value from a first format supporting a first network to a second format supporting a second network by a centralized network device (CND) configured to configure the CND by an external device; the first network is a controller area network (CAN) based network; the second network is an Ethernet based network; the first network is a controller area network (CAN) based network; the second network is an Ethernet-based network; the first network is an Ethernet-based network; the second network is a Controller Area Network (CAN)-based network; The network is an Ethernet-based network and the second network is a Controller Area Network (CAN)-based network, the message value is transmitted over an intermediate network inserted between the first network and the second network. the intermediate network is of a different type than the first network and/or the second network; the first and second networks are controller area network (CAN) based networks; the network is an Ethernet-based network; the first and second networks are Ethernet-based networks; and the intermediate network is a Controller Area Network (CAN)-based network; generating and transmitting this external message value toward a first network; interpreting the external message value by a first vehicle control device; the external message value supporting a system of the vehicle; and/or or generating an external message value by an external device and transmitting this external message value towards a centralized network device (CND) inserted between the first network and the second network; including the step of interpreting the

An example system includes a vehicle having a first network zone and a second network zone of a different type, and a policy management circuit structured to interpret a policy including an active diagnostic description, responsive to the active diagnostic description. between the first network zone and the second network zone; An inserted central network device (CND) and the feature that the endpoint includes a device responsive to diagnostic command values.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. The example system includes a device control circuit structured to interpret a diagnostic command value and provide an actuator command value responsive to the diagnostic command value, and an actuator responsive to the actuator command value, the diagnostic execution circuit , the policy further includes a diagnostic execution condition, the policy further comprising a diagnostic execution condition, the policy further comprising: determining whether the vehicle operating conditions are consistent with the diagnostic command value prior to providing the diagnostic command value; further structured to determine whether vehicle operating conditions are consistent with diagnostic command values responsive to the diagnostic execution conditions, the diagnostic execution circuitry performing diagnostic data collection operations responsive to the active diagnostic descriptions; The diagnostic execution circuitry is further structured to store a set of diagnostic data responsive to the diagnostic data collection operation, the diagnostic execution circuitry further structured to store a set of diagnostic data responsive to the diagnostic data collection operation. further structured to perform a processing operation on the collected data and store a diagnostic data set responsive to the processing operation; and/or the processing operation comprises compressing the collected data; activating a virtual sensor using the collected data; determining a diagnostic data set responsive to the virtual sensor; determining vehicle operating condition parameters responsive to the collected data; responsive to the vehicle operating condition parameters. and/or performing a downsampling operation on the collected data. . The example system is characterized in that the diagnostic execution circuitry is further structured to communicate a set of diagnostic data to an external device in response to the diagnostic data collection operation, wherein the diagnostic execution circuitry is configured to communicate a set of diagnostic data to an external device in response to the diagnostic data collection operation; further structured to perform a processing operation on the collected data and to communicate a diagnostic data set responsive to the processing operation to an external device; and/or the processing operation compresses the collected data; activating a virtual sensor using the collected data; determining a diagnostic data set in response to the virtual sensor; determining vehicle operating condition parameters in response to the collected data; comprising at least one operation such as determining a responsive diagnostic data set, performing an upsampling operation on the collected data, and/or performing a downsampling operation on the collected data. include. The example system provides diagnostic validation structured to determine a diagnostic confirmation value based on an actuator's response to a diagnostic command value and perform one of the steps of storing the diagnostic confirmation value or communicating the diagnostic confirmation value to an external device. If the circuit, active diagnostic description includes a target device description that does not identify whether the endpoint resides on a first network zone or a second network zone, the system further comprising a configuration circuit structured to determine a network address value for the endpoint, and wherein the diagnostic execution circuit is further structured to provide a diagnostic command value to the endpoint responsive to the network address value. , and/or the active diagnostic description includes a target device description that includes identification information that the endpoint is on a first network zone, the system responds to the target device description so that the endpoint is located on a second network zone. The method further includes a configuration circuit structured to determine that the zone is located on the zone.

An example method includes the steps of: interpreting a policy that includes an active diagnostic description; and providing diagnostic command values to one endpoint of a first network zone or a second network zone of a vehicle in response to the active diagnostic description. , the second network zone being of a different type than the first network zone, and commanding the actuator in response to the diagnostic confirmation value.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. The example method further includes determining whether the vehicle operating conditions are consistent with the diagnostic command values prior to providing the diagnostic command values, the policy further comprising a diagnostic performance condition, and the vehicle operating conditions responsive to the diagnostic performance conditions. performing a diagnostic data collection operation responsive to the active diagnostic description; storing a diagnostic data set responsive to the diagnostic data collection operation; The collection operation includes processing the collected data and storing a diagnostic data set responsive to this processing. Exemplary operations for processing the collected data include compressing the collected data, summarizing the collected data, utilizing the collected data to operate a virtual sensor, determining a diagnostic data set responsive to the virtual sensor, determining vehicle operating condition parameters responsive to the collected data; determining a diagnostic data set responsive to the vehicle operating condition parameters; performing an upsampling operation on the collected data; and/or on the collected data. and performing a downsampling operation. The example method includes the diagnostic execution circuitry being further structured to communicate a diagnostic data set to an external device in response to a diagnostic data collection operation, wherein the diagnostic data collection operation processes the collected data; a step of communicating the diagnostic data set responsive to the processing to an external device; a step of determining a diagnostic confirmation value based on the response of the actuator to the diagnostic command value; and a step of storing the diagnostic confirmation value or communicating it to the external device. performing, the active diagnostic description comprising a target device description that does not identify whether the endpoint resides on a first network zone or a second network zone; determining a network address value for the endpoint and providing a diagnostic command value to the endpoint in response to the network address value, and/or the active diagnostic description identifying that the endpoint is on the first network zone. including a target device description, the method further includes determining, in response to the target device description, that the endpoint is on the second zone.

An example system includes a vehicle having a first legacy network zone and a second highly functional network zone, a policy inserted between the first legacy network zone and the second highly functional network zone that includes an external communication value. a centralized network device (CND) comprising a policy management circuit structured to interpret an external device in response to an external communication value and an endpoint of one of the first legacy network zone or the second advanced network zone; an external communication control circuit structured to coordinate communications between the external communication control circuitry;

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system includes: the external communication value includes an active diagnostic description; the external communication value includes an active test description; the external communication value includes at least one of a data request value or a vehicle command value. the first legacy network zone includes a controller area network (CAN) bus network; the second high-performance network zone includes an Ethernet network; the external device includes service tools, manufacturer tools, sales the external communication value includes a target device description including identification information that the endpoint resides on the first legacy network zone; the circuit is further structured to determine that the endpoint resides on the second sophisticated network zone in response to the target device description; the external device is communicatively connected to the first legacy network zone; the external device is communicatively coupled to the second intelligent network zone; the external communication value includes one of a coupled service tool or a manufacturing tool; a target device description including an identification of being on a zone, the external communication control circuitry being further structured to determine that the endpoint is on a first legacy network zone; and/or The external device is communicatively coupled to the second enhanced network zone.

An example method includes the steps of: interpreting a policy that includes an external communication value; and connecting an external device to an endpoint of one of a first legacy network zone of a vehicle or a second enhanced network zone of a vehicle in response to the external communication value. and coordinating communications between.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes the external communication value including an active test description, wherein coordinating the communication includes performing an active diagnosis responsive to the active diagnostic description, and wherein the external communication value includes an active test description. and the step of coordinating the communication includes the step of conducting an active test responsive to the active test description; the step of coordinating the communication includes collecting data values in response to an external communication value; or communicating an external communication value from an external device, including at least one of the steps of providing a vehicle control command in response to the external communication value; determining a target device description including identification information of being on a second legacy network zone, and determining in response to the target device description that the endpoint is on a second advanced network zone; determining a target device description including identification information that the endpoint resides on the second advanced network zone in response to the communication value; including the step of determining that the

An example system includes a vehicle having a first network zone and a second network zone, a policy management circuit that includes a network coordination description and is structured to interpret a policy that includes a default policy value, an external data routing a configuration circuit structured to configure at least one network interface circuit in response to a description and an external data service description, coordinating communication between a first network zone endpoint and a second network zone endpoint; and a centralized network device (CND) inserted between a first network zone and a second network zone.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system includes the configuration circuit, wherein the policy includes a primary policy value, and the configuration circuit is further structured to configure at least one network interface circuit in response to the primary policy value. further structured to determine whether a primary policy value is present and utilize the primary policy value as the policy in place of the default policy value in response to determining that the primary policy value is present. wherein the policy further includes a secondary policy value, and the configuration circuitry is further structured to configure the at least one network interface circuit in response to the secondary policy value, the configuration circuitry further comprising: determining whether a secondary policy value is present, and in response to determining that a secondary policy value is present, using the secondary policy value as a policy in place of either the default policy value or the primary policy value; further structured to apply the secondary policy value as a policy and apply consistent portions of the primary policy value to further portions of the policy. the default policy value includes a permanently stored policy and the primary policy value includes a tool-supplied policy; wherein the second external device is selected from a device such as a service tool, a manufacturing tool, a web-based application, and/or a cloud-based application; the default policy value includes a permanent storage policy; the primary policy value includes a tool-supplied policy; and the secondary policy value includes a post-manufacturing policy; The policy management circuit is further structured to interpret a tool-supplied policy from the second external device, the policy management circuit further configured to interpret a post-manufacturing policy from the second external device. wherein the policy management circuitry is further structured to interpret the post-manufacturing policy from the third external device, the configuration circuitry configured to interpret each of the primary policy value and the secondary policy value. is further structured to determine whether a policy exists (and/or is valid) and utilizes a secondary policy value, a primary policy value, or a default policy value in that order. , the policy management circuit is further structured to interpret the primary policy value from the second external device in response to the default policy value, and/or the policy management circuit is configured to interpret the primary policy value or The method further includes the feature being further structured to interpret a secondary policy value from the second external device in response to at least one of the default policy values.

An example system includes a vehicle having a first network zone and a second network zone of a different type, a centralized network device (CND) inserted between the first network zone and the second network zone. a policy management circuit structured to interpret a policy communicated from an external device to the CND, the policy management circuit including a network coordination description, and structured to configure the at least one network interface circuit in response to the policy; and at least one network interface circuit structured to coordinate communications between a first network zone endpoint and a second network zone endpoint.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system includes an external device including one of a cloud application or a web-based tool, a policy development interface structured to receive policy input from a plurality of users; , a policy formulation engine structured to compile policy input values into a policy, and a policy enforcement engine structured to communicate the policy to the CND; at least one data collection definition, each including at least one local communication device supporting data collection parameters; and at least one of a source definition or a destination definition for each data collection definition; each of the one or more includes at least one of a source identifier, a destination identifier, a source address, a destination address, a source port, and/or a destination port, such that the CND performs data collection operations responsive to the data collection definition. the CND includes at least one of a source definition or a destination definition for at least one of the at least one data collection definition; determining at least one of a source definition or a destination definition for at least one of the data collection definitions. Yet another example system provides communication between a first endpoint on a first network zone and a second endpoint on a second network zone, a first endpoint on the first network zone, and a first endpoint on the first network zone. communication between a second endpoint on a network zone of the vehicle, a first local communication device of the vehicle and a second local communication device of the vehicle, and/or a first network zone and a second network zone. a vehicle communication circuit structured to interpret vehicle communication data including at least one communication data, such as a communication between; a system structured to generate visualization data in response to the vehicle communication data; and a display interface circuit structured to transmit the visualization data, wherein the vehicle communication circuit is disposed on the external device, and the CND transmits the vehicle communication data onto the network zone of the vehicle. the external device is configured to receive communication data at the port on the network zone of the vehicle, the visualization circuit is disposed on the external device, the display interface circuit is configured to transmitting visualization data toward a user device communicatively coupled to an external device; the first network zone includes a controller area network (CAN); and the second network zone includes an Ethernet network zone. , and/or the external device includes a policy formulation engine structured to generate the policy as at least one configuration file having a selected configuration format. Exemplary visualization data includes a graphical flow representation of at least a portion of communications between local communication devices of a vehicle, a graphical flow representation of at least a portion of communications passing through a CND, at least one of a first network interface circuit or a second network interface circuit. one or more of a graphical flow representation of at least a portion of communications coordinated by a first network zone and a second network zone; include. An example system includes a policy interaction engine structured to generate a policy interaction code, and a policy development system configured to receive policy input values from a plurality of users in response to the policy interaction code. an interface, a policy formulation engine structured to generate a policy responsive to received policy input values, and a policy enforcement engine structured to communicate the policy to the CND. Exemplary policy interaction code includes one or more of header files, parameter definitions, and/or application programming interface (API) declarations.

An example method includes interpreting a policy for a vehicle from an external device, configuring at least one network interface circuit in response to the policy, and utilizing the configured at least one network interface circuit. coordinating communications between a first network zone endpoint of the vehicle and a second network zone endpoint of the vehicle.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes receiving policy input values from a plurality of users and compiling the policy input values into a policy inserted between a first network zone and a second network zone, the policy input values being inserted between a first network zone and a second network zone; communicating the policy to a centralized network device (CND) including at least one network interface circuit, the policy including at least one data collection definition, and the method further comprising performing a data collection operation responsive to the data collection definition. automatically determining at least one of a source definition or a destination definition for at least one of the at least one data collection definition, the first destination on the first network zone and the second destination on the second network zone; communication between a first endpoint on a first network zone and a second endpoint on the first network zone, a first local communication device of the vehicle and a second endpoint of the vehicle; interpreting vehicle communication data including at least one communication data, such as communication between two local communication devices and/or communication between a first network zone and a second network zone, and responding to the vehicle communication data; generating visualization data and transmitting the visualization data to a display device; generating a policy interaction code; receiving a policy input value in response to the policy interaction code; and generating a policy in response to the received policy input value. and/or generating the policy interaction code includes generating a header file for the policy, generating parameter definitions for the policy, and/or a cloud application or a web-based tool. The method includes performing at least one operation selected from a plurality of operations, such as generating an application programming interface (API) declaration for a user device to interact with an external device.

An example system includes a vehicle having a first network zone and a second network zone of a different type, a centralized network device (CND) inserted between the first network zone and the second network zone. a policy management circuit structured to interpret a policy including a network coordination description; a configuration circuit structured to configure at least one network interface circuit in response to the policy; and at least one network interface circuit structured to coordinate communications between a network zone endpoint and a second network zone endpoint.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system provides policy management circuitry that receives a policy communication from an external device and performs one of storing a policy or updating a stored policy in response to the policy communication. the external device is communicatively coupled to the policy management circuit through at least one of the first network zone or the second network zone; , communicatively coupled to the policy management circuit through at least one of a wireless network connection or a cellular network connection, the policy management circuit performing one of the steps of storing the policy or updating the stored policy. the policy management circuitry is further structured to provide notification to the external device in response to validating the policy; , and/or the policy includes a permission value supporting at least one endpoint of the first network zone or the second network zone, the permission value being a data collection permission value. , a service publication permission value, a service regular reception permission value, or an external communication permission value.

The example method includes interpreting a policy that includes a network coordination description and, in response to the network coordination description, coordinating communications between a first network zone endpoint of the vehicle and a second network zone endpoint of the vehicle. and the second network zone is of a different type than the first network zone.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes receiving a policy communication from an external device and performing one of storing a policy or updating a policy in response to the policy communication, storing a policy or updating a policy. verifying the policy prior to implementing one of the updating steps; providing a notification to the external device in response to verifying that the policy cannot be applied; and providing a notification to the first network in response to the policy; coordinating external communications of endpoints of each of the zone and the second network zone, responsive to the policy, adjusting the communication between the first endpoint of the first network zone and the second endpoint of the first network; updating a local configuration file of the configurable Ethernet switch in response to one of the policy enforcement or the policy update; and local configuration of the configurable edge gateway in response to one of the policy enforcement or the policy update. updating the file; and coordinating the communication between the first endpoint of the first network zone and the second endpoint of the second network zone, the step of performing one of an upsampling operation or a downsampling operation on the communication. and/or coordinating the communication between the first endpoint of the first network zone and the second endpoint of the first network zone, the step comprising performing an upsampling operation on the communication or The method includes performing one of the downsampling operations. Exemplary operations of verifying that a policy cannot be applied include: determining that the policy violates security standards of previously stored policies or policy communications; determining that the policy cannot be enforced; determining that the policy cannot be enforced; determining that the policy cannot be enforced due to communication limitations, determining that the policy cannot be enforced due to data storage limitations, and/or implementing the policy due to external communication limitations; including one or more of a plurality of actions consisting of determining that it is not possible to do so.

An example system includes a vehicle having a first network zone and a second network zone of a different type, and a centralized network device (CND) inserted between the first network zone and the second network zone. a policy management circuit structured to interpret a policy that includes an active diagnostic description, and in response to the active diagnostic description, transmit a diagnostic command value to an endpoint of one of the first network zone or the second network zone; and the CND including a diagnostic execution circuit structured to provide a diagnostic command, and the endpoint includes a device responsive to the diagnostic command value.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system includes a device control circuit structured to interpret a diagnostic command value and provide an actuator command value responsive to the diagnostic command value, and an actuator responsive to the actuator command value, the system The execution circuit is further structured to determine whether vehicle operating conditions are consistent with the diagnostic command values before providing the diagnostic command values, the policy further includes diagnostic execution conditions, and the policy further includes diagnostic execution conditions. The circuit is further structured to determine whether the vehicle operating conditions are consistent with diagnostic command values responsive to the diagnostic execution conditions, the diagnostic execution circuit operative to collect diagnostic data in response to the active diagnostic description. wherein the diagnostic execution circuitry is further structured to store a diagnostic data set responsive to the diagnostic data collection operation; further structured to perform a processing operation on the collected data and store a diagnostic data set responsive to the processing operation; the diagnostic execution circuit is further structured to communicate the set of data to an external device, the diagnostic execution circuitry performing processing operations on the collected data in the diagnostic data collection operation and generating the diagnostic data set responsive to the processing operation; further structured to communicate to an external device, the step of determining a diagnostic confirmation value based on the actuator's response to the diagnostic command value and storing or communicating the diagnostic confirmation value to the external device. a diagnostic verification circuit structured to perform one of the following: the active diagnostic description includes a target device description that does not identify whether the endpoint resides on a first network zone or a second network zone; The system further includes configuration circuitry structured to determine a network address value for the endpoint responsive to the target device description, and the diagnostic execution circuit further provides a diagnostic command value to the endpoint responsive to the network address value. and/or the active diagnostic description includes a target device description that includes identification information that the endpoint resides on the first network zone, and the system is configured to respond to the target device description. and further comprising configuration circuitry structured to determine that the endpoint is on the second zone. Exemplary processing operations include compressing collected data, summarizing collected data, utilizing collected data to operate a virtual sensor, determining a diagnostic data set in response to a virtual sensor, and responding to collected data. determining a diagnostic data set responsive to the vehicle operating condition parameters; performing an upsampling operation on the collected data; and performing a downsampling operation on the collected data. including one or more of the steps.

An example method includes the steps of: interpreting a policy that includes an active diagnostic description; and providing diagnostic command values to one endpoint of a first network zone or a second network zone of a vehicle in response to the active diagnostic description. , the second network zone being of a different type than the first network zone, and commanding the actuator in response to the diagnostic confirmation value.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes determining whether vehicle operating conditions are consistent with the diagnostic command values prior to providing the diagnostic command values, the policy further comprising a diagnostic execution condition, and the vehicle operating conditions are consistent with the diagnostic command values. determining whether or not the diagnostic command value is consistent with the condition; performing a diagnostic data collection operation in response to the active diagnostic description; storing a diagnostic data set in response to the diagnostic data collection operation; The collection operation processes the collected data and stores the diagnostic data set responsive to the processing, the diagnostic execution circuitry further structured to communicate the diagnostic data set responsive to the diagnostic data collection operation to an external device. The diagnostic data collection operation processes the collected data, communicates the diagnostic data set responsive to this processing to an external device, and determines a diagnostic confirmation value based on the actuator's response to the diagnostic command value. , performing one of storing or communicating this diagnostic confirmation value to an external device; determining a network address value for the endpoint in response to the target device description and further providing a diagnostic command value for the endpoint in response to the network address value; , a target device description including identification information that the endpoint is on a first network zone, the method further comprising determining that the endpoint is on a second zone in response to the target device description. Contains the characteristic of containing. Exemplary operations for processing the collected data include compressing the collected data, summarizing the collected data, utilizing the collected data to operate a virtual sensor, determining a diagnostic data set responsive to the virtual sensor, determining vehicle operating condition parameters responsive to the collected data; determining a diagnostic data set responsive to the vehicle operating condition parameters; performing an upsampling operation on the collected data; and downsampling the collected data. It may include one or more operations, such as the step of performing an operation.

An example system includes a vehicle having a first legacy network zone and a second highly functional network zone, a policy inserted between the first legacy network zone and the second highly functional network zone that includes an external communication value. a centralized network device (CND) including a policy management circuit structured to interpret and/or respond to an external communication value with the external device and one of the first legacy network zone or the second highly functional network zone; an external communication control circuit structured to coordinate communications between endpoints of the apparatus.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system includes: the external communication value includes an active diagnostic description; the external communication value includes an active test description; the external communication value includes at least one of a data request value or a vehicle command value. the first legacy network zone includes a controller area network (CAN) bus network; the second advanced network zone includes an Ethernet network; the external device includes a service tool; the external communication value includes at least one of a manufacturer tool, a merchant tool, or a cloud-based tool; and wherein the external communication control circuit is further structured to determine that the endpoint is on the second advanced network zone in response to the target device description, the external device is connected to the first legacy network. the external device includes one of a service tool or a manufacturing tool communicatively coupled to the zone; an external device is communicatively coupled to the second intelligent network zone; a target device description including identification information that the endpoint is located on a first legacy network zone; and the external communication control circuit is further structured to determine that the endpoint is located on a first legacy network zone. and/or the external device is communicatively coupled to the second enhanced network zone.

An example method includes the steps of: interpreting a policy that includes an external communication value; and coordinating communications between.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes the external communication value including an active test description, wherein coordinating the communication includes performing an active diagnosis responsive to the active diagnostic description, and wherein the external communication value includes an active test description. and the step of coordinating the communication includes the step of conducting an active test responsive to the active test description; the step of coordinating the communication includes collecting data values in response to an external communication value; or communicating an external communication value from an external device, including at least one of the steps of providing a vehicle control command in response to the external communication value; determining a target device description including identification information of being on a second legacy network zone, and determining in response to the target device description that the endpoint is on a second advanced network zone; determining a target device description including identification information that the endpoint resides on the second advanced network zone in response to the communication value; including the step of determining that the

An example apparatus includes a vehicle communication circuit structured to interpret vehicle communication data and, in response to the vehicle communication data, visualize data, a first network onboard the vehicle, and a first network onboard the vehicle. a visualization circuit structured to generate the visualization data, the visualization circuit having a first network identifier and a second network identifier each corresponding to a second network of a different type from the first network; a display interface circuit structured to transmit.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. Yet another example apparatus includes an electronic display structured to interpret and display visualization data, the visualization data including topology data corresponding to a network topology of the first network and/or the second network. the visualization circuit is further structured to include a portion of the metadata of the vehicle communication data in the visualization data; the input monitor circuit structured to interpret the data filtering values; an input monitor circuit, the first or second network, wherein the circuit is further structured to filter a portion of the vehicle communication data used to generate the visualization data based at least in part on the data filtering value; the identifier supports an Ethernet-based protocol; the other of the first or second network identifier supports a Controller Area Network (CAN)-based protocol; a third network identifier that supports both networks of the first network and a third network of a different type; the visualization data includes a traffic monitor visualization; an endpoint on one of the networks, a vehicle system, an application, a flow, a vehicle controller, a vehicle function, a selected one of the first network or the second network, or one of the first network or the second network; the visualization data includes a port counter visualization, the visualization data includes an endpoint data flow monitor visualization, the visualization data supports at least one of the ports of the first network or and/or the visualization data includes a network activity profile for an endpoint on one of the first or second networks, a vehicle system, an application, a flow, a vehicle controller, , a network activity profile for at least one of a selected one of the first network or the second network, or a port of one of the first network or the second network. include. The example system includes a display interface circuit storing visualization data on a shared storage of a vehicle, storing visualization data on a shared storage of a vehicle, and selectively transmitting the stored visualization data to an external device. transmitting the visualization data to the secure cloud storage; and/or transmitting the visualization data to the secure cloud storage and to at least one of a monitoring tool, an external application, a service tool, or a user device. The method further includes a feature further configured to transmit the visualization data by performing at least one act, such as providing selective access to the visualization data stored on the display. An example system includes the steps of: a vehicle communication circuit interpreting vehicle communication data from a policy stored on a memory disposed on the vehicle and communicatively coupled to the vehicle communication circuit; receiving vehicle communication data from a coupled service tool; receiving vehicle communication data from an application communicatively coupled to the vehicle communication circuit; and/or from a monitoring tool communicatively coupled to the vehicle communication circuit. The method further includes a feature further configured to interpret the vehicle communication data by performing at least one act, such as receiving the vehicle communication data.

Exemplary data filtering values include network address association, vehicle control device association, vehicle system association, service group association, network protocol type, endpoint identifier, data type, application association, and/or flow association. Exemplary data filtering values include one or more of an engine system, a steering system, a braking system, a fuel system, a prime mover system, an anti-lock braking system, a traction control system, and/or a drive transfer control system. Exemplary data filtering values refer to systems such as security systems, lighting systems, safety systems, environmental control systems, advanced driver assistance systems, and/or infotainment systems. Exemplary third network identifiers include one or more of a cellular-based protocol, a WiFi-based protocol, and/or a Bluetooth-based protocol.

An example method includes interpreting vehicle communication data and visualizing data in response to the vehicle communication data, the first network onboard the vehicle and the first network onboard the vehicle being of a different type. generating the visualization data having a first network identifier and a second network identifier each corresponding to a second network of the network; and transmitting the visualization data.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method is characterized in that generating visualization data includes generating topology data corresponding to a network topology of the first network and/or the second network, generating visualization data. further comprising: including a portion of metadata of the vehicle communication data; interpreting the data filtering value; and filtering the portion of the vehicle communication data based at least in part on the data filtering value; The generating step includes a step of determining traffic monitor visualization, the step of generating visualization data includes a step of determining port counter visualization, and the step of generating visualization data includes a step of determining a data flow at an end point. monitoring and determining an endpoint data flow monitor visualization, wherein the step of generating visualization data includes determining a network activity profile for one endpoint of the first network or the second network. , and/or generating visualization data at an endpoint on one of the first network or the second network, a vehicle system, an application, a flow, a vehicle controller, a vehicle function, the first network or the second network. or a port of one of the first network or the second network.

Exemplary operations that determine traffic monitor visibility include endpoints, vehicle systems, applications, flows, vehicle controllers, vehicle functions, on one of the first network or the second network, the first network or the second network, monitoring traffic on one or more of the ports of the selected one and/or of the first network or the second network. Exemplary operations for transmitting visualization data include storing visualization data on shared storage of a vehicle, storing visualization data on shared storage of a vehicle, and selectively transmitting the stored visualization data to an external device. transmitting the visualization data toward the secure cloud storage; and/or transmitting the visualization data toward the secure cloud storage and at least one of a monitoring tool, an external application, a service tool, and/or a user device. The method may include one or more acts such as providing selective access to visualization data stored for. An example operation of interpreting vehicle communication data includes interpreting vehicle communication data from a policy stored on a memory located on the vehicle and communicatively coupled to the vehicle communication circuitry. receiving vehicle communication data from a service tool coupled to the vehicle communication circuit; receiving vehicle communication data from an application communicatively coupled to the vehicle communication circuit; and/or a monitor tool communicatively coupled to the vehicle communication circuit. and at least one act, such as receiving vehicle communication data from.

An example system includes a vehicle having a first network zone and a second network zone of a different type, and a centralized network device (CND) inserted between the first network zone and the second network zone. and a policy management circuit structured to interpret a policy including a network coordination description, and a configuration circuit structured to configure the first network interface circuit in response to the network coordination description. CND and the first network interface circuit is structured to coordinate communication between the first network zone endpoint and the second network zone endpoint.

Certain further aspects of example systems, any one or more of which may be present in certain embodiments, are described below. Yet another example system provides that the network coordination description includes a data request authorization description that includes a data value for a data requestor, and at least a portion of the data requestor is in at least one of a first network zone or a second network zone. the first network interface circuit is further structured to coordinate communications in response to the data request authorization description; the configuration circuit comprises a second network interface circuit in response to the network coordination description; further structured to configure the interface circuit, the second network interface circuit being structured to coordinate communication between endpoints of the second network zone, the configuration circuit comprising: a network coordination description; further structured to configure a responsive gatekeeper interface circuit, the gatekeeper interface circuit configured to coordinate communications between the endpoints of both the first network zone and the second network zone and the external device; the external device is communicatively coupled to one of the first network zone or the second network zone; the external device is communicatively coupled to a transceiver of the vehicle; is communicatively coupled to the second network zone, the external device includes an application including at least one of a cloud server-based application, a web-based application, or a mobile device application; The data request authorization description includes a flow for one of the endpoints of the external device, the first network zone and/or the second network zone, the flow for the external device, the first network zone and/or the second network zone. further comprising a data access grant associated with at least one of the vehicle functionality with respect to one of the endpoints of the vehicle, or with the vehicle functionality with respect to the external device, the gatekeeper interface circuit being configured to communicate with the external device in response to the data access grant. wherein the data request authorization description further includes an external communication bandwidth limit, and the gatekeeper interface circuit adjusts communication with the external device in response to the external communication bandwidth limit. The configuration circuit is further configured to receive a policy update including a change to the network adjustment description and update the configuration of the first network interface circuit in response to the change. structured, the policy management circuit interprets the authorization associated with the policy update, and the authorization indicates that the requesting unit is not authorized to make changes to the network coordination description of the policy update. and/or the requesting unit is further structured to suppress the policy update in response to the policy update, and/or the requesting unit is an entity related to the policy update, an application related to the policy update, a flow related to the policy update, a vehicle function related to the policy update, a policy and at least one unit selected from a plurality of units consisting of an identifier of an external device communicating the update. An example gatekeeper interface circuit includes a flow associated with one of the coordinated communications, a data type associated with the coordinated communication, a data service provider associated with the coordinated communication, a vehicle function associated with the coordinated communication, a vehicle function associated with the coordinated communication, and a data type associated with the coordinated communication. The device is further configured to coordinate communication with the external device in response to at least one of the services and/or the connection type of the communicable coupling with the external device.

The example method includes the steps of: interpreting a policy that includes a network coordination description; configuring a first network interface circuit in response to the network coordination description; and configuring a first network interface circuit of a vehicle using the first network interface circuit. coordinating communications between the network zone endpoint and the second network zone endpoint of the vehicle.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method provides that the network coordination description includes a data request authorization description that includes data values for a data requestor, and at least a portion of the data requestor is in at least one of a first network zone or a second network zone. coordinating the communication in response to the data request authorization description, the second network interface circuit responsive to the network coordination description; coordinating communications between the endpoints of both the first network zone and the second network zone and the external device, including a gatekeeper interface circuit responsive to the network coordination description; and/or the data request authorization description comprises coordinating communications with the external device, the flow with respect to one of the endpoints of the first network zone and/or the second network zone, the flow with respect to the external device, the first the gatekeeper if further comprising data access permissions associated with at least one of the vehicle functions with respect to the network zone and/or one of the endpoints of the second network zone and/or with respect to the external device; coordinating communication with the external device in response to the data access grant using the interface circuit. The example data request authorization description includes an external communication bandwidth limit, and the example method further includes adjusting communication with the external device in response to the external communication bandwidth limit using a gatekeeper interface circuit. Exemplary acts of coordinating communications include: a flow for one of the coordinated communications, a data type for the coordinated communication, a data service provider for the coordinated communication, a vehicle function for the coordinated communication, a coordinated communication. and/or a connection type of communicable coupling with an external device. The example method includes receiving a policy update including a change to a network coordination description, updating a configuration of a first network interface circuit in response to the change, and/or interpreting a grant associated with the policy update. , suppressing the policy update in response to the authorization indicating that the requesting unit is not authorized to make changes to the network coordination description of the policy update.

An example method includes the steps of: interpreting a policy that includes a network authorization description; configuring a first network interface circuit responsive to the network authorization description; coordinating communications between a network zone endpoint of the vehicle and a second network endpoint of the vehicle.

Certain further aspects of exemplary methods, any one or more of which may be present in certain embodiments, are described below. Yet another example method includes a gatekeeper interface circuit responsive to an external data access description if the network authorization description further includes the external data access description; responsively coordinating communication with the external device; the external data access description includes permissions associated with the external device; the external data access description includes permissions associated with the flow of the vehicle; wherein the step of coordinating the communications includes coordinating the communications based on a flow association of the communicating endpoints of the first network zone or the second network zone, the external data access description being provided to the application. coordinating the communication is based on an application association of the communication device including one of the external device, the first network zone endpoint, or the second network zone endpoint, if the step includes an associated permission; wherein the external data access description includes permissions associated with a network zone of the vehicle; the first network zone and the second network zone each include a separate virtual local area network of the vehicle; and/or the first network zone and the second network zone each include a separate virtual local area network of the vehicle. or the network usage authorization description supports at least one of the first network zone or the second network zone, an end point, a flow, a vehicle function of one of the first network zone or the second network zone, or The method further includes a communication device description that includes at least one of the applications.

Here, coordinating the communication includes coordinating the communication based on the network usage description and a communication device associated with the coordinated communication.

An example apparatus includes a policy management circuit structured to interpret a policy that includes a network authorization description, and a configuration structured to configure a first network interface circuit in response to the network authorization description. and a first network interface circuit structured to coordinate communications between a first network zone endpoint of the vehicle and a second network zone endpoint of the vehicle.

Certain further aspects of the exemplary apparatus, any one or more of which may be present in certain embodiments, are described below. Yet another example apparatus includes a feature in which the network authorization description further includes an external data access description.

wherein the configuration circuitry is further structured to configure a gatekeeper interface circuit responsive to the external data access description, the gatekeeper interface circuit responsive to the external data access description to coordinate communication with the external device. structured such that the external data access description includes permissions associated with the external device, and the external data access description includes permissions associated with the flow of the vehicle, the gatekeeper interface circuit includes a first further structured to coordinate the communication based on the flow association of those communicating among the endpoints of the network zone or the second network zone, where the external data access description includes a permission associated with the application; The gatekeeper interface circuit is further structured to coordinate communications based on an application association of the communication device including one of the external device, the first network zone endpoint, or the second network zone endpoint. , the gatekeeper interface circuit bases the coordinated communication on at least one of the source zone or the destination zone and the external data access description, if the external data access description includes permissions associated with a network zone of the vehicle. the first network zone and the second network zone each include a separate virtual local area network of the vehicle; A communication including at least one of a network usage description, an endpoint of one of the first network zone or the second network zone, a flow, a vehicle function, or an application corresponding to at least one of the network zone or the second network zone. If further including a device description, the gatekeeper interface circuit is further structured to coordinate the communication based on the network usage description and the communication device associated with the coordinated communication.

The methods and systems described herein are configured to execute computer readable instructions, program code, instructions and/or to operably perform one or more operations of the methods and systems herein. A computer, computer device, processor, circuit, and/or server including hardware may be deployed in part or in whole through a machine having a computer, computer device, processor, circuit, and/or server. As used herein, the terms computer, computing device, processor, circuit, and/or server ("computing device") should be understood broadly.

An exemplary computing device has the capability of accessing instructions stored on a non-transitory computer-readable medium or the like in communication with the computer, thereby performing operations of the computing device upon execution of the instructions. Including any type of computer. In certain embodiments, such instructions include a computing device itself. Additionally or alternatively, a computing device may be a separate hardware device distributed across one or more computing resources and/or in response to determined conditions. any logic circuits, embedded circuits, sensors, actuators, input devices and/or output devices, network resources and/or communication resources configured to functionally perform one or more operations of the systems and methods of may include aspects such as memory resources of any type, processing resources of any type, and/or hardware devices.

Network resources and/or communication resources include, but are not limited to, local area networks, wide area networks, wireless, the Internet, or any other known communication resources and protocols. Exemplary and non-limiting hardware and/or computing devices include, but are not limited to, general purpose computers, servers, embedded computers, mobile devices, virtual machines, and/or emulation computing devices. A computing device includes a distributed set of resources that are included as aspects of a number of devices and interoperable to perform the described functionality of the computing device. It can be a resource. In certain embodiments, each computing device may reside on separate hardware, and/or one or more hardware devices may be configured, e.g., separately executable devices stored on the device. can include more than one aspect of a computing device as instructions and/or as a logically partitioned manner of a set of executable instructions, some aspects being part of one of the first computing devices; , and some aspects include part of another of the computing devices.

A computing device may be part of a server, client, network infrastructure, mobile computing platform, fixed computing platform, or other computing platform. A processor may be any type of computing or processing device capable of executing program instructions, code, binary instructions, etc. The processor may be a signal processor, a digital processor, an embedded processor, a microprocessor, or any variant thereof, e.g., which may directly or indirectly facilitate the execution of program code or program instructions stored on these processors. The computer may be or include a number of capable coprocessors (such as a numerical coprocessor, graphics coprocessor, communication coprocessor, etc.). Additionally, a processor may be capable of executing multiple programs, threads, and codes. Multiple threads can be executed simultaneously to improve processor performance and to facilitate simultaneous operation of applications. Depending on implementation, the methods, program code, program instructions, etc. described herein may be implemented in one or more threads. A thread can spawn other threads that can be assigned an associated priority, and the processor can spawn them in any other order based on the priority or based on instructions given within the program code. These threads can be executed. A processor can include memory that stores the methods, code, instructions, and programs described herein and others. The processor has access through the interface to a storage medium that can store the methods, code, and instructions described herein and the like. A storage medium connected to a processor for storing methods, programs, codes, program instructions, or other types of instructions that can be executed by a computing device or a processing device may include a CD-ROM, a DVD, a memory, a hard disk, It can include, but is not limited to, one or more of a flash drive, RAM, ROM, cache, and the like.

A processor may include one or more cores that can improve multiprocessor speed and performance. In embodiments, the processing may be a dual-core processor combining two or more independent cores (referred to as a die), a quadrupole-core processor, other chip-level multiprocessor, or the like.

The methods and systems described herein may be implemented in part or through machines that execute computer-readable instructions on servers, clients, firewalls, gateways, hubs, routers, or other such computer and/or network-connected hardware. Can be deployed globally. The computer readable instructions can be attached to a server that can include file servers, print servers, domain servers, Internet servers, intranet servers, as well as other variations, such as secondary servers, host servers, distributed servers, and the like. A server has memory, processors, computer-readable temporary and/or non-transitory media, storage media, ports (physical and virtual), communication devices, and interfaces with other servers, clients, machines, and devices through wired or wireless media. The interface may include one or more of the following: The methods, programs, or code described herein and elsewhere may be executed by a server. Additionally, other devices required to perform the methods described herein may be considered part of the infrastructure attached to the server.

A server may provide an interface to other devices including, but not limited to, clients, other servers, printers, database servers, print servers, file servers, communication servers, distributed servers, and the like. Additionally, this coupling and/or connection can facilitate remote execution of instructions over a network. Networking of some or all of these devices may facilitate parallel processing of program code, instructions, and/or programs at one or more locations without departing from the scope of the present disclosure. Can be done. Furthermore, every device connected to a server through an interface may include at least one storage medium capable of storing methods, program code, instructions, and/or programs. A central repository can provide program instructions to be executed on various devices. In this implementation, the remote repository may serve as a storage medium for the methods, program code, instructions, and/or programs.

The methods, program code, instructions, and/or programs can be applied to clients that may include file clients, print clients, domain clients, Internet clients, intranet clients, and other variations, such as secondary clients, hosted clients, distributed clients, etc. can be attached to. The Client may include memory, processors, computer-readable temporary and/or non-transitory media, storage media, ports (physical and virtual), communication devices, and other clients, servers, machines, and devices through wired or wireless media. The interface may include one or more of the following: The methods, program code, instructions, and/or programs described herein and elsewhere may be executed by a client. Additionally, other devices required to perform the methods described herein may be considered part of the infrastructure attached to the client.

A client may provide an interface to other devices, including but not limited to servers, other clients, printers, database servers, print servers, file servers, communication servers, distributed servers, and the like. Additionally, the coupling and/or connection can facilitate remote execution of methods, program code, instructions, and/or programs over a network. Network connectivity of some or all of these devices may facilitate parallel processing of methods, program code, instructions, and/or programs at one or more locations without departing from the scope of the present disclosure. can do. Furthermore, any device connected to a client through an interface may include at least one storage medium capable of storing methods, program code, instructions, and/or programs. A central repository can provide program instructions to be executed on various devices. In this implementation, the remote repository may serve as a storage medium for the methods, program code, instructions, and/or programs.

The methods and systems described herein can be deployed in part or in whole through a network infrastructure. Network infrastructure includes elements such as computing devices, servers, routers, hubs, firewalls, clients, personal computers, communication devices, routing devices, and other active and passive devices, modules, and/or components. can include. Computing devices and/or non-computing devices associated with a network infrastructure may include storage media such as flash memory, buffers, stacks, RAM, ROM, etc., among other components. The methods, program code, instructions, and/or programs described herein and elsewhere may be executed by one or more of the network infrastructure elements.

The methods, program code, instructions, and/or programs described herein and elsewhere may be executed on a cellular network having multiple cells. A cellular network can be either a frequency division multiple access (FDMA) network or a code division multiple access (CDMA) network. Cellular networks can include mobile devices, cell sites, base stations, repeaters, antennas, towers, and the like.

The methods, program code, instructions, and/or programs described herein and elsewhere may be implemented on or by a mobile device. Mobile devices can include navigation devices, cell phones, mobile phones, mobile personal digital assistants, laptops, palmtops, netbooks, pagers, electronic book readers, music players, and the like. These devices may include storage media such as flash memory, buffers, RAM, ROM, and one or more computing devices, apart from other components. A computing device associated with a mobile device may be capable of executing methods, program code, instructions, and/or programs stored thereon. Alternatively, mobile devices may be configured to cooperate with other devices to execute instructions. A mobile device may be configured to communicate with a base station that interfaces with a server and execute methods, program code, instructions, and/or programs. Mobile devices can communicate over peer-to-peer networks, mesh networks, or other communication networks. The methods, program code, instructions, and/or programs may be stored on a storage medium associated with the server and executed by a computing device embedded within the server. A base station can include computing devices and storage media. The storage device may store methods, program code, instructions, and/or programs that are executed by computing devices attached to the base station.

Methods, program code, instructions, and/or programs may be applied to computer components, devices, and storage media, known as random access memory (RAM), for holding digital data used to perform operations over a period of time. , optical disks, magnetic storage forms like hard disks, mass storage, generally more permanent storage like tapes, drums, cards, and other types, processor registers, cache memory, volatile memory, non-volatile Memory, optical storage like CDs, DVDs, flash memory (e.g. USB stick or USB key), floppy disks, magnetic tape, paper tape, punched cards, standard RAM disks, zip drives, removable mass storage, offline, etc. Removable media, such as dynamic memory, static memory, read/write storage, variable storage, read-only, random access, sequential access, location addressable, file addressable, content addressable, network attached storage, storage Stored on and/or accessible on machine-readable temporary and/or non-transitory media, which may include other computer memory such as area networks, bar codes, magnetic ink, and the like.

Certain operations described herein include interpreting, receiving, and/or determining one or more values, parameters, inputs, data, or other information (“received data”). An act of receiving data includes receiving data through user input, receiving data over any type of network, receiving data values from a memory location in communication with a receiving device, receiving data values estimating, calculating, or deriving the data value based on other information available to the receiving device; and/or estimating, calculating, or deriving the data value based on other information available to the receiving device; including but not limited to updating any. In certain embodiments, data values can be received by a first operation and later updated by a second operation as part of receiving the data values. For example, a first receive operation can be performed when communications are down, intermittently stopped, or interrupted, and an updated receive operation can be performed when communications are restored.

Certain logical groupings of the operations herein, eg, methods or procedures of the present disclosure, are presented to illustrate aspects of the present disclosure. The acts described herein are generally illustrated and/or illustrated, and the acts may be combined, divided, reordered, added, or removed in a manner consistent with the disclosure herein. can do. The context of the operation description may require ordering with respect to one or more operations, and/or may explicitly disclose an ordering with respect to one or more operations, but yielding equivalent operation results. It is understood that where any equivalent grouping of acts is specifically contemplated herein, the order of acts must be understood broadly. For example, if a value is used in one actuation step, certain circumstances may require a step to determine this value before this actuation step (e.g. to achieve a certain effect). (if the time delay of the data is important for the actuation), other situations may not require this decision step before this actuation step (e.g. if the (if the use is considered sufficient for these purposes). Thus, in certain embodiments, although the described ordering of acts and groupings of acts are explicitly contemplated herein, in certain embodiments, reordering, subdivision, and/or Different groupings are explicitly contemplated herein.

The methods and systems described herein can transform physical and/or intangible items from one state to another. The methods and systems described herein can convert data representing physical and/or intangible items from one state to another.

The methods and/or processes described above, and the steps thereof, may be performed using hardware, program code, instructions, and/or programs, or a combination of hardware and methods, program code, instructions, and/or programs suitable for a particular application. It can be realized. Hardware refers to a dedicated computing device or a particular computing device, a particular aspect or component of a particular computing device, and/or a hardware configuration for carrying out one or more of the operations of the method and/or system. It may include an arrangement of elements and/or logic circuits. Processing may be implemented within one or more microprocessors, microcontrollers, embedded microcontrollers, programmable digital signal processors, or other programmable devices with internal and/or external memory. The processing may also or alternatively be within an application specific integrated circuit, a programmable gate array, programmable array logic, or any other device or combination of devices that can be configured to process electronic signals. It can be implemented. It will be further appreciated that one or more of the processes may be implemented as computer-executable code capable of being executed on a machine-readable medium.

Computer-executable code may be implemented on one of the above-mentioned devices as well as on a processor, a heterogeneous combination of processor architectures, a combination of different hardware and computer-readable instructions, or any other machine capable of executing program instructions. A structured programming language such as C, an object-oriented programming language such as C++, or any other high-level or low-level programming language (such as assembly) that can be stored, compiled, and interpreted to run on (including languages, hardware description languages, and database programming languages and techniques).

That is, in one aspect, each of the methods and combinations thereof described above can be implemented in computer-executable code that performs the steps of the methods when executed on one or more computing devices. In another aspect, the method can be implemented in a system for performing the steps, and in some schemes can be distributed across multiple devices, or all of the functionality can be implemented in a dedicated stand-alone device or Can be integrated into other hardware. In another aspect, the means for performing the processing-related steps may include any of the hardware and/or computer readable instructions described above. All such permutations and combinations are intended to fall within the present disclosure.

Although this disclosure has been disclosed with respect to certain embodiments shown and described in detail, various modifications and improvements to these embodiments will become readily apparent to those skilled in the art. Accordingly, the spirit and scope of the present disclosure is not to be limited by the above-described examples, but is to be understood in the broadest sense permitted by law.

1904 First Network Zone 1908 Second Network Zone 1912 Centralized Network Device (CND)
2002 First risk exposure profile 2004 Second risk exposure profile

Images