Think in automotive Ethernet Topology

Episode 1：from msg routing to data bursting

文章目录

Think in automotive Ethernet Topology
- Episode 1：from msg routing to data bursting
1. Topology category
- 1.1 Star and Daisy
- - ## START:
  - ## Daisy:
  - - *线性拓扑*：例如，A-B-C-D-E，A-B-C-D-E和C-M-N-O（在C处分支）是菊花链。
    - *环形拓扑*：从最后一个设备到第一个设备有一个环路连接。例如，A-B-C-D-E-A（环）。这通常被称为“菊花链循环”。
    - 系统访问
- 1.2 Ring and subnet Ring
- - - Advantages:
    - Disadvantages:
  - 1.2.1 Subnet Ring:
  - 1.2.2 Ring
- 1.3 Tree
2. Communication category
- 2.1 Standards and specifications
- 2.2 配置管理 Configuration Management
- 2.3 安全管理 Security Management
- 2.3 性能管理 Performance Management
- 2.4 故障管理 Fault Management
- 2.5 拓扑管理 Topology Management
- - 网络拓扑性质
3. Scenarios
- 3.1 DOIP/ Diagnosis
- 3.2 OTA /
- 3.3 SOVD - Service Oriented Vehicle Diagnostics
- - Main Goal of the Project
  - Problem Description
  - Use-Cases for Standardization
  - Proposal for Standardization
  - Further Information
4. Comparison
- 4.1 List
- 4.2 Examples
5. Summary

1. Topology category

1.1 Star and Daisy

## START:

星型结构是各个控制器以星型方式连接成网。网络有中央节点，其他节点（工作站、服务器）都与中央节点直接相连，这种结构以中央节点为中心，因此又称为集中式网络。它具有如下特点：结构简单，便于管理；控制简单，便于建网；网络延迟时间较小，传输误差较低。但缺点也是明显的：成本高、可靠性较低、资源共享能力也较差。

星形拓扑结构的主要优点有：

结构简单，容易管理维护；
重新配置灵活；
方便故障检测与隔离；
控制简单，便于建网；
网络延迟时间较小，传输误差较低；

星形拓扑结构的主要缺点有：

成本高、可靠性较低；

## Daisy:

任何特定的菊花链形成两种网络拓扑之一：

线性拓扑：例如，A-B-C-D-E，A-B-C-D-E和C-M-N-O（在C处分支）是菊花链。

环形拓扑：从最后一个设备到第一个设备有一个环路连接。例如，A-B-C-D-E-A（环）。这通常被称为“菊花链循环”。

工业自动化领域，采用菊花链拓扑结构的实时以太网得到了较为广泛的应用．

系统访问

用户可以将计算会话菊花链连接在一起。使用Telnet或SSH等服务，用户通过Telnet在第二台计算机上创建会话，从第二个会话，Telnet到第三个计算机创建会话，依此类推。另一个典型示例是使用RDP的“终端会话内的终端会话”。创建菊花链的原因包括通过网关系统连接到非路由网络上的系统，在第二台计算机上工作时保留初始计算机上的会话，通过首先连接到更好的网络来节省带宽或改善不稳定网络上的连接连接机器。一项不那么健康的目的是在从事网络犯罪时进行伪装活动。

在这种结构上，应用时间槽调度实时协议会由于数据交换次数的增多、延迟增大带来较为严重的效率问题。

1.2 Ring and subnet Ring

环形拓扑结构由沿固定方向连接成封闭回路的网络节点组成，每一节点与它左右相邻的节点连接，是一个点对点的封闭结构。所有的节点公用一个信息环路，都可以提出发送数据的请求，获得发送权的节点可以发送数据。环形网络常使用令牌来决定哪个节点可以访问通信系统。在环形网络中信息流只能是单方向的，每个收到信息包的站点都向它的下游站点转发该信息包，直至目的节点。信息包在环网中“环游”一圈，最后由发送站进行回收，只有得到令牌的站才可以发送信息。每台设备都可直接连到环上，或通过一个接口设备和分支电缆连到环上，如图3-4-2所示

实时性较好, 也就是说，信息在网中传输的最大时间固定。
每个结点只与相邻两个结点有物理链路
传输控制机制比较简单
某个结点的故障将导致物理瘫痪
单个环网的结点数有限
单向性

环形网的数据传输具有单向性，即每个转发器仅与两个相邻的转发器有直接的物理线路。

Advantages:

电缆长度短。环形拓扑结构所需的电缆长度与总线型拓扑网络相当，比星形拓扑网络还要短。

适合用光纤。光纤传输速度高，环形拓扑网络是单向传输，适合用光纤作为通信介质，这样可以大大提高网络的速度和加强抗干扰的能力。

无差错传输。由于采用点到点通信链路，被传输的信号在每一个节点上都会再生，因此，传输信息的误码率可大大降

Disadvantages:

环形拓扑结构存在的缺点：

可靠性差。在环上传输数据都要通过连接在环上的每个中继器才能得以完成，任何两个节点间的电缆或者中继器发生故障都将会引起全网的故障。

故障诊断困难。因为环上的任一节点出现故障都会引起全网的故障，所以对故障很难进行定位。

调整网络比较困难。要调整网络中的节点，例如加人或撤出节点都是比较困难。

每个节点既要收也要发，同时具备网关功能。

1.2.1 Subnet Ring:

通常在一个中央网关存在的情况下，子网环形网络更符合实际。

1.2.2 Ring

1.3 Tree

2. Communication category

2.1 Standards and specifications

CIA:

ASA:

PCI SIG:

NAV Alliance:

AVNU:

Open Alliance:

IEEE :

MiPI Alliance:
总结列表：

2.2 配置管理 Configuration Management

网络配置管理（Configuration Management)是指初始化网络并配置网络，以使其提供网络服务，配置管理是一组对辨别、定义、控制和监视组成一个通信网络的对象所必要的相关功能，目的是为了实现某个特定功能或使网络性能达到最优。它通过控制、记录、追踪对软件的修改和每个修改生成的软件组成部件来实现对软件产品的管理功能。

配置管理过程是对处于不断演化、完善过程中的软件产品的管理过程。一致性、可追溯性，使产品极大程度地与用户需求相吻合。随着软件系统的日益复杂化和用户需求、软件更新的频繁化，配置管理逐渐成为软件生命周期中的重要控制过程，在软件开发过程中扮演着越来越来重要的角色。一个好的配置管理过程能覆盖软件开发和维护的各个方面，同时对软件开发过程的宏观管理，即项目管理，也有重要的支持作用。良好的配置管理能使软件开发过程有更好的可预测性，使软件系统具有可重复性，使用户和主管部门用软件质量和开发小组有更强的信心。

2.3 安全管理 Security Management

保护网络安全技术：

联通技术

国际上的网管软件大多是基于SNMP设计的，一般只侧重于设备管理，且编程复杂、结构单一，不利于大规模集成。如果用户要管理各类网络设备、操作系统及安全产品，则要综合使用诸如WBEM、UDDI和XML等协议与通信技术。因此应尽量提高各协议接口间的透明访问程度，实现协议间的互联互访。

集成技术

各安全子系统要对网络及用户进行实时管理，大多采用用户端安装插件的技术，在多个子系统都需插件的情况下，可能产生冲突，且给用户系统增加负担，因此各厂商除提供必要的接口信息外，集成单位也应注意将各种信息技术进行融合，通过编程实现对各系统探头的集成。

可视化管理技术

为了让用户更好地通过安全管理平台进行集中管理，用户管理界面最好能够提供直观的网络拓朴图，实时显示整个网络的安全状况，使用户可以便捷地查看各安全产品组件的状态、日志以及信息处理结果，产生安全趋势分析报表。因此可视化管理技术的研究与应用尤为重要。

事件关联技术

由于从单独的安全事件中很难发觉其它的攻击行为，必须综合多种安全设备的事件信息进行分析，才能得到准确的判断。

事件过滤技术

一个安全事件有可能同时触动多个安全单元，同时产生多个安全事件报警信息，造成同一事件信息“泛滥”，反而使关键的信息被淹没。因此，事件过滤技术也是安全管理平台需要解决的一个重要问题。

快速响应技术

发生网络安全事件后，单靠人工处理可能会贻误战机，所以必须要开发快速响应技术，从而能使系统自动响应安全事件。如实现报警、阻塞、阻断、引入陷阱，以及取证和反击等。

数据安全保护系统以全面数据文件安全策略、加解密技术与强制访问控制有机结合为设计思想，对信息媒介上的各种数据资产，实施不同安全等级的控制，有效杜绝机密信息泄漏和窃取事件。

数据安全保护系统的保护对象主要是政府及企业的各种敏感数据文档，包括设计文档、设计图纸源代码、营销方案、财务报表及其他各种涉及国家机密和企业商业秘密的文档，可以广泛应用于政府研发、设计、制造等行业。

产品特点

**1. 透明加解密技术：**提供对涉密或敏感文档的加密保护，达到机密数据资产防盗窃、防丢失的效果，同时不影响用户正常使用。

**2. 泄密保护：**通过对文档进行读写控制、打印控制、剪切板控制、拖拽、拷屏/截屏控制、和内存窃取控制等技术，防止泄漏机密数据。

**3. 强制访问控制：**根据用户的身份和权限以及文档的密级，可对机密文档实施多种访问权限控制，如共享交流、带出或解密等。

**4. 双因子认证：**系统中所有的用户都使用USB-KEY进行身份认证，保证了业务域内用户身份的安全性和可信性。

**5. 文档审计：**能够有效地审计出，用户对加密文档的常规操作事件。

**6. 三权分立：**系统借鉴了企业和机关的实际工作流程，采用了分权的管理策略，在管理方法上采用了职权分离模式，审批，执行和监督机制。

**7. 安全协议：**确保密钥操作和存储的安全，密钥存放和主机分离。

产品功能

1. 密指定程序生成的文档

强制加密指定程序编辑的文档。用户访问加密文档时，需要连接服务器（在线，非脱机状态），并且具有合适的访问权限。该加密过程完全透明，不影响现有应用和用户习惯。通过共享、离线和外发管理可以实行更多的访问控制。

2. 泄密控制

对打开加密文档的应用程序进行如下控制：打印、内存窃取、拖拽和剪贴板等，用户不能主动或被动地泄漏机密数据。

3. 审批管理

支持共享、离线和外发文档，管理员可以按照实际工作需求，配置是否对这些操作进行强制审批。用户在执行加密文档的共享、离线和外发等操作时，将视管理员的权限许可，可能需要经过审批管理员审批。

4. 离线文档管理

客户端需要连接服务器才能访问加密文档。通过本功能制作离线文档，即使客户端未连接服务器，用户也可以阅读这些离线的文档。根据管理员权限许可，离线文档可能需要经过审批管理员审批离线时，可以控制客户端的离线时间和离线时是否允许打印。

5. 外发文档管理

外部人员不能阅读加密文档的内容。本功能制作外发文档，即使在未安装客户端的机器上，也可以阅读这些外发的文档。根据管理员权限许可，外发文档可能需要经过审批管理员审批外发的文档，和内部使用一样，受到加密保护和泄密控制，不会造成文档泄露，同时增加口令和机器码验证，增强外发文档的安全性。

6. 用户/鉴权

集成了统一的用户/鉴权管理，用户统一使用USB-KEY 进行身份认证，客户端支持双因子认证。

7. 审计管理

对加密文档的常规操作，进行详细且有效的审计。控制台提供了基于WEB的管理方式。审计管理员可以方便地通过浏览器进行系统的审计管理。

8. 自我保护

通过在操作系统的驱动层对系统自身进行自我保护，保障客户端不被非法破坏，并且始终运行在安全可信状态。即使客户端被意外破坏，客户端计算机里的加密文档也不会丢失或泄漏。

安全管理效果：

1. 数据资产保护

只有通过身份认证，并在服务器管理下，才能访问这些文档。因此，无论是因为计算机失窃，还是由于内部员工通过移动存储设备、电子邮件或即时通讯工具把加密文档外传，都能够保证加密文档无法阅读。

2. 防止泄密

有效防止用户主动或被动泄漏机密数据，用户无法通过拷贝、打印、内存窃取、外传等方式外泄这些加密文档的内容，即使是通过黑客工具也无法窃取加密文档的内容。

3. 文档访问管理

用户只能访问属于本人的加密文档，根据管理员配置，对加密文档的指定操作需要管理员审批才能进行，例如共享和解密文档。

4. 灵活、容易操作

不改变用户使用习惯和业务操作流程，根据实际应用需求，可进行系统配置，支持加密文档的共享、解密以及带出功能，同时允许设置管理员进行审批，规范了文档的管理,降低了管理成本。

5. 事件追踪

全面的系统管理，及数据文档操作事件审计，系统详细记录了管理员管理系统的事件，用户操作**加密****文档**的事件，做到系统发生的事件均可追溯相关责任人。

6. 无需值守，管理成本低

提供基于WEB的管理方法，管理员可以通过浏览器进行系统管理。用户与计算机设备绑定，同时使用USB-KEY身份认证技术，每个用户依据配置的策略进行操作，即使“管理员不在场”也不会发生违规操作和窃、泄密事故。

2.3 性能管理 Performance Management

网络性能管理（Network Performance Management）是指评价系统资源的运行状况及通信效率等系统性能。其能力包括监视和分析被管网络及其所提供服务的性能机制，性能分析的结果可能会触发某个诊断测试过程或重新配置网络以维持网络的性能。性能管理收集分析有关被管网络当前状况的数据信息，并维持和分析性能日志

性能管理的功能包括以下几个方面：

1.性能监控

由用户定义被管对象及其属性。被管对象类型包括线路和路由器；被管对象属性包括流量、延迟、丢包率、CPU利用率、温度、内存余量，对于每个被管对象，定时采集性能数据，自动生成性能报告

2.阀值控制

可对每一个被管对象的每一条属性设置网值，对于特定被管对象的特定属性，可以针对不同的时间段和性能指标进行岗值设置。可通过设置岗值检查开关控制阀值检查和告警，提供相应的阀值管理和溢出告警机制。

3.性能分析

对历史数据进行分析、统计和整理，计算性能指标，对性能状况做出判断，为网络规划提供参考。

4.可视化的性能报告

对数据进行扫描和处理，生成性能趋势曲线，以直观的图形反映性能分析的结果。

5.实时性能监控

提供了一系列实时数据采集、分析和可视化工具，用以对流量、负载、丢包、温度、内存、延迟等网络设备和线路的性能指标进行实时检测，可任意设置数据采集间隔。

2.4 故障管理 Fault Management

用户都希望有一个可靠的计算机网络。当网络中某个组成部分失效时，网络管理器必须迅速查找到故障并及时排除。通常不大可能迅速隔离某个故障，因为网络故障的产生原因往往相当复杂，特别是当故障是由多个网络组成共同引起的。在此情况下，一般先将网络修复，然后再分析网络故障的原因，分析故障原因对于防止类似故障的再发生相当重要。网络故障管理包括故障监测、报警、排错、分析等方面

2.5 拓扑管理 Topology Management

提供灵活的自定义拓扑的工具，使用这些工具可以定义出多种风格的网络拓扑图，以满足多用户的需求。除此之外，可根据实际行政区域划分来定义每个网络设备的位置使拓扑视图更加清晰、易懂。

网络拓扑性质

信息时代的到来,网络技术的迅猛发展,新的网络产品及组网模式不断地涌现，网络已经与人们的学习、工作及社会生活密不可分，因此保障网络的通畅、可靠也就显得极为重要。一个稳定、安全、可靠、可以监督网络运行状况的网络管理系统成为亟待研究的问题。而网络管理是通过监控网络拓扑结构实现的。网络拓扑发现的主要目的是获取和维护网络节点的存在和连接信息,并绘制出拓扑结构图。网络拓扑发现更能提高网络故障管理、计量管理、配置和名称管理、性能管理和安全管理的性能，网络管理人员根据拓扑结构图对故障节点进行快速定位和修复。对于网络管理系统来说，一个完善的网络拓扑自动发现模块对网络管理至关重要。

3. Scenarios

3.1 DOIP/ Diagnosis

3.2 OTA /

3.3 SOVD - Service Oriented Vehicle Diagnostics

Main Goal of the Project

Definition of a standardized service API for HPC diagnostics, which includes new HPC-related and conventional diagnostic use-cases.

Problem Description

The primary focus of ECU diagnostic in today’s vehicles is on checking the functionality of hardware components, such as sensors, actuators and the ECU. Diagnostic communication then allows to read trouble codes, manage the diagnostic memory, carry out test procedures in the workshop and perform some other operations like parameter changes and software updates. The most widely spread bus system in use is the CAN-bus. First vehicle platforms supporting Ethernet access have entered the market. The most widely spread diagnostic protocol across both bus systems is UDS.

With the introduction of HPCs (high performance computers) to the vehicle network, the diagnostic capabilities of UDS seem to reach its limitations. HPCs have capabilities, which go far beyond those of conventional ECUs:

multi-core, multi-threaded computing
virtualized ECUs sharing resources on the same hardware
high band-width low-latency communication to other HPCs (e.g. via Automotive Ethernet)
complex operating systems
complex software and AI-engines

Hence, mechanisms are required to analyze and diagnose not only the hardware aspects of the vehicle network but also the software executing on HPCs.

In addition to HPCs, new connectivity technology enters the market place, that may in the long run obsolete the OBD connector. Wi-Fi and mobile broadband (4G, 5G) allow for remote and OTA (over-the-air) access to the vehicle network, allowing remote diagnostics, coding, parametrization and re-programming. At the same time, HPCs allow to perform on-board diagnostic tasks without any external access. We thus have to distinguish between use-cases for onboard, proximity and remote diagnostics, which is a new challenge not covered by today’s prevailing diagnostic stacks.

Use-Cases for Standardization

ASAM members have proposed three use-cases for HPC diagnostics standardization, which are given as a starting point for discussion and elaboration for the proposal workshop.

Use-Case 1: Proximity Diagnostics

The person performing vehicle diagnostics is close to the vehicle. The diagnostics system helps the person to detect and localize the fault, e.g. by reading out error codes, sensor/actuator values or debugging information (e.g. log files). He can check the operational status of components (OK/NOK), performing actuations or stimulations and carry out parameter and software updates.

Use-Case 2: Remote Diagnostics

The vehicle diagnostics is performed remotely, i.e. over-the-air (OTA diagnostics). Besides detecting and localizing the fault by a technician, as described in use-case 1, there are more operations possible. Roadside assistance may provide remote help with no technician present. A service advisor may prepare the vehicle for service. Information may be retrieved for monitoring purposes, e.g. fuel level, battery health check, etc. Other services are possible, such as remote activation of vehicle functions or fleet management.

Use-Case 3: Onboard Diagnostics
There is no external device or remote application connected to the vehicle and no external operator or application interacts with the vehicle. Instead, diagnostic functions run autonomously within the vehicle, for instance to monitor critical components, carry out predictive or preventive maintenance scenarios and to collect vehicle status information.

Proposal for Standardization

The aim of the standardization proposal is to define and standardize interfaces and services to cover the above use-cases in a flexible architecture, which includes classic diagnostics for regular ECUs and the additional diagnostic use-cases for one or multiple HPCs. UDS diagnostics capabilities and OBD-based access must be supported. Proximity and remote diagnostics shall be supported by a ‘public’ interface, that is accessible by external devices. Those HPCs with a ‘private’ interface shall be accessible by external devices via connected HPCs with a ‘public’ interface, allowing to implement domain- or gateway-network architectures. This is achieved by API-level standardization of the application interfaces of two diagnostic software components running on an HPC:

HPC Diagnostics Service (private and public)
Classic Diagnostic Adapter

The positioning of the software components in a simple central diagnostic access network architecture is shown in the following figure:

Further Information

For further information about the proposal, please download the document HPC Diagnostics - List of Use-Cases for Standardization or review the presentations from the proposal workshop on Jun 05, 2019.

4. Comparison

4.1 List

4.2 Examples

HPC<->HPC: Ethernet (1Gbps -> 2.5G/5G/10G)

HPC<->Zone Controller (1Gbps -> 2.5G/5G/10G)

Zone <> Zone: (100mbps->1Gbps -> 2.5G/5G/10G)

Zone<>legacy ECUs (CAN/LIN,etc)

5. Summary

就个人经验来看，HPC和HPC之间的通讯还是以以太网为主，并从千兆开始迭代，随着L3 和自动驾驶的推荐，算法复杂度与数据量的增加，开始2.5G，5G到10G的大数据交互开始；

-千兆为起点的一个原因，中央网关或者超级网关的存在依然是过渡，并会形成多个子环网的星型拓扑为主要形式；

其次成本的控制和芯片成熟度，2025-2030是一个节点，芯片厂商的动态值得期待。

再者，车载网络技术，动态路由的使用和规范化还有待成熟；

还有，随着L3以上的自动驾驶，中国ICV，车云结合，边缘计算等智慧路边设备的使用，数据量暴增，如何处理并保证节点的动态加入，汽车变成IOT设备，网络拓扑变环形，甚至mesh组网未来是否有可能，也是问号。

总之，汽车网络需要汽车人才和IT人才共同探讨和合作，科技未来值得期待。