1 前言Introduction

核心价值主张：用一根线，让传感器数据更精准、更可靠、更经济。SENT协议正成为汽车电子领域替代模拟和PWM信号，实现传感器数字化通信的首选方案。

Core Value Proposition: With a single wire, make sensor data more accurate, more reliable, and more cost-effective. The SENT protocol is becoming the preferred solution in the automotive electronics field to replace analog and PWM signals, enabling digital communication for sensors.

随着汽车电动化、智能化浪潮的推进，车载传感器数量呈指数级增长，对数据传输的精度、实时性和可靠性提出了前所未有的要求。传统的模拟电压信号易受干扰，PWM信号的精度和诊断能力有限，而复杂的CAN/LIN总线网络则带来了高昂的成本和布线负担。在此背景下，SENT协议应运而生，为汽车传感器与电子控制单元（ECU）之间的点对点通信提供了最优解决方案。

With the advancement of automotive electrification and intelligentization, the number of onboard sensors has grown exponentially, placing unprecedented demands on data transmission accuracy, real-time performance, and reliability. Traditional analog voltage signals are susceptible to interference, PWM signals have limited accuracy and diagnostic capabilities, and complex CAN/LIN bus networks bring high costs and wiring burdens. In this context, the SENT protocol emerged as the optimal solution for point-to-point communication between automotive sensors and Electronic Control Units (ECUs).

2 技术原理剖析：SENT协议如何实现"以时传数"Technical Principles Analysis: How SENT Protocol Achieves "Data Transmission Through Time"

SENT协议的核心设计哲学在于将信息编码在时间维度而非电压幅度。这种"以时传数"的机制，使其在严苛的汽车电磁环境中展现出卓越的抗干扰能力和高精度特性。

The core design philosophy of the SENT protocol lies in encoding information in the time dimension rather than voltage amplitude. This "data transmission through time" mechanism enables it to demonstrate excellent anti-interference capabilities and high-precision characteristics in harsh automotive electromagnetic environments.

其核心技术架构围绕以下四个关键机制构建：

Its core technical architecture is built around the following four key mechanisms:

1. 时间编码：协议的基本数据单元为"半字节"（Nibble，4位）。每个Nibble的值（0-15）通过测量两个下降沿之间的时间差来编码。具体公式为：脉冲宽度 = (N + 1) × Tick。其中"+1"机制确保了即使传输值为0，脉冲也有最小宽度，增强了信号的鲁棒性。

1. Time Encoding: The basic data unit of the protocol is the "Nibble" (4 bits). Each Nibble value (0-15) is encoded by measuring the time difference between two falling edges. The specific formula is: Pulse Width = (N + 1) × Tick. The "+1" mechanism ensures that even when transmitting a value of 0, the pulse has a minimum width, enhancing signal robustness.

2. 自同步时钟校准：每帧数据以固定56个Tick时长的同步脉冲开始。接收端ECU通过精确测量该同步脉冲的实际物理时间，动态反推出传感器端的Tick周期。这一机制实现了无外部时钟线的动态校准，有效补偿了因温度、电压变化引起的时钟漂移。

2. Self-Synchronizing Clock Calibration: Each data frame begins with a synchronization pulse of fixed 56 Tick duration. The receiving ECU dynamically calculates the sensor-side Tick period by precisely measuring the actual physical time of this synchronization pulse. This mechanism achieves dynamic calibration without external clock lines, effectively compensating for clock drift caused by temperature and voltage variations.

3. 结构化帧传输：一个完整的SENT帧由同步脉冲、状态/通信字、最多6个数据字、CRC校验字和可选的暂停脉冲组成。状态字可携带传感器故障标志或慢速通道数据起始位，数据字则承载核心的传感信息，支持双12位通道传输，CRC校验保障了数据的完整性。

3. Structured Frame Transmission: A complete SENT frame consists of a synchronization pulse, status/communication nibble, up to 6 data nibbles, CRC checksum nibble, and optional pause pulse. The status nibble can carry sensor fault flags or slow channel data start bits, while data nibbles carry core sensor information, supporting dual 12-bit channel transmission. CRC checksum ensures data integrity.

4. 硬件极简主义：发送端（传感器）通常仅需一个精准定时器和一个GPIO引脚，无需专用通信控制器或PHY芯片。接收端（ECU）也仅需一个带输入捕获功能的定时器。这种设计将协议复杂性从遍布车辆的传感器节点转移到了集中的ECU，显著降低了系统整体成本。

4. Hardware Minimalism: The transmitting end (sensor) typically requires only a precision timer and a GPIO pin, without needing dedicated communication controllers or PHY chips. The receiving end (ECU) also requires only a timer with input capture functionality. This design transfers protocol complexity from numerous sensor nodes distributed throughout the vehicle to the centralized ECU, significantly reducing overall system costs.

3 核心优势对比：为什么选择SENT而非传统方案？Core Advantages Comparison: Why Choose SENT Over Traditional Solutions?

为清晰展示SENT协议的全面优势，我们将其与模拟信号、PWM信号及CAN/LIN总线在传感器应用场景下进行多维度对比。

To clearly demonstrate the comprehensive advantages of the SENT protocol, we compare it with analog signals, PWM signals, and CAN/LIN buses in sensor application scenarios across multiple dimensions.

通过对比可见，SENT协议在精度、抗扰、成本、诊断和实时性五个关键维度上取得了最佳平衡，尤其适合对成本敏感且要求高可靠性的汽车传感器应用。

Through comparison, it is evident that the SENT protocol achieves the optimal balance across five key dimensions: accuracy, anti-interference capability, cost, diagnostics, and real-time performance. It is particularly suitable for automotive sensor applications that are cost-sensitive and require high reliability.

4 关键增强：SPC功能与协议演进Key Enhancement: SPC Functionality and Protocol Evolution

基础SENT协议为单向通信，为满足更复杂的系统需求，SENT SPC应运而生。SPC通过在数据帧的暂停脉冲期间插入主触发脉冲，实现了有限的双向通信和单线多传感器管理。

The basic SENT protocol is unidirectional. To meet more complex system requirements, SENT SPC (Short PWM Code) was developed. SPC achieves limited bidirectional communication and single-wire multi-sensor management by inserting Master Trigger Pulses (MTP) during the pause pulse period of data frames.

SPC功能允许ECU通过发送不同宽度的MTP来"寻址"总线上的特定传感器，从而按需获取数据，可将总线负载降低30%。这使其在需要初始化配置、在线诊断或优先调度关键传感器的场景中价值巨大。

The SPC functionality allows the ECU to "address" specific sensors on the bus by sending MTPs of different widths, thereby obtaining data on demand and reducing bus load by up to 30%. This makes it extremely valuable in scenarios requiring initialization configuration, online diagnostics, or priority scheduling of critical sensors.

5 全景应用：SENT协议赋能现代汽车Panoramic Applications: SENT Protocol Empowering Modern Automobiles

SENT协议已深度渗透到现代汽车的各个核心系统，从传统动力总成到新兴的智能驾驶领域，成为连接物理世界与数字控制的关键桥梁。

The SENT protocol has deeply penetrated various core systems of modern automobiles, from traditional powertrains to emerging intelligent driving fields, becoming a crucial bridge connecting the physical world with digital control.

• 动力总成系统：曲轴/凸轮轴位置传感器、涡轮增压压力传感器、变速箱速度传感器

• Powertrain Systems: Crankshaft/camshaft position sensors, turbocharger pressure sensors, transmission speed sensors

• 底盘与安全系统：轮速传感器（ABS）、加速度传感器、横摆角速度传感器（ESC）

• Chassis and Safety Systems: Wheel speed sensors (ABS), acceleration sensors, yaw rate sensors (ESC)

• 车身电子与新能源：电子油门位置传感器、电池管理系统（BMS）、能量回收系统

• Body Electronics and New Energy: Electronic throttle position sensors, Battery Management Systems (BMS), energy recovery systems

• 智能驾驶：线控转向、线控制动、自动驾驶传感器网络

• Intelligent Driving: Steer-by-wire, brake-by-wire, autonomous driving sensor networks

6 知从科技木牛配置工具对SENT协议的支持ZC.MuNiu Configuration Tool Support for SENT Protocol

6.1 木牛配置工具简介Introduction to MuNiu Configuration Tool

知从科技木牛配置工具是一款专为汽车电子嵌入式软件开发设计的可视化配置工具，深度集成于知从科技基础软件（ZCBasic）生态体系中。该工具基于AUTOSAR架构设计理念，为ECU软件开发提供图形化的配置界面，大幅降低开发门槛，提升开发效率。

The ZC.MuNiu Configuration Tool is a visual configuration tool specifically designed for automotive electronics embedded software development, deeply integrated into the ZC.Basic software ecosystem. Based on AUTOSAR architecture design concepts, it provides a graphical configuration interface for ECU software development, significantly lowering the development threshold and improving development efficiency.

木牛配置工具支持多种车载通信协议的配置与代码生成，包括CAN/CANFD、LIN、FlexRay以及SENT协议。通过可视化的参数配置界面，开发人员可以快速完成协议栈的参数设置、信号映射、诊断配置等复杂工作，自动生成符合标准的配置文件和底层代码，实现"零代码"或"低代码"的协议栈开发。

The MuNiu Configuration Tool supports configuration and code generation for various in-vehicle communication protocols, including CAN/CANFD, LIN, FlexRay, and SENT protocols. Through a visual parameter configuration interface, developers can quickly complete complex tasks such as protocol stack parameter settings, signal mapping, and diagnostic configuration, automatically generating standard-compliant configuration files and low-level code, achieving "zero-code" or "low-code" protocol stack development.

6.2 SENT协议配置功能详解Detailed SENT Protocol Configuration Functions

• 完整的SENT协议栈支持：木牛配置工具完整支持SAE J2716标准定义的SENT协议，包括基础SENT和SPC（Short PWM Code）增强模式，满足不同应用场景的通信需求。

• Complete SENT Protocol Stack Support: The MuNiu Configuration Tool fully supports the SENT protocol as defined by the SAE J2716 standard, including both basic SENT and SPC (Short PWM Code) enhanced modes, meeting communication requirements for different application scenarios.

• 可视化参数配置：通过直观的图形界面配置Tick时间、同步脉冲参数、数据帧格式（Nibble数量）、CRC校验方式等关键参数，避免手动配置的错误。

• Visual Parameter Configuration: Configure key parameters such as Tick time, synchronization pulse parameters, data frame format (number of Nibbles), and CRC checksum methods through an intuitive graphical interface, avoiding manual configuration errors.

• 多通道管理：支持同时配置和管理多个SENT通道，每个通道可独立设置参数，适用于复杂ECU中连接多个传感器的应用场景。

• Multi-Channel Management: Supports simultaneous configuration and management of multiple SENT channels, with each channel independently configurable, suitable for application scenarios in complex ECUs connecting multiple sensors.

• 信号映射与解析：提供可视化的信号映射工具，将SENT帧中的数据Nibble映射到应用层信号，自动完成数据解析和物理值转换配置。

• Signal Mapping and Parsing: Provides visual signal mapping tools to map data Nibbles in SENT frames to application-layer signals, automatically completing data parsing and physical value conversion configuration.

• 诊断与错误处理配置：内置完善的诊断功能配置，包括CRC错误检测、同步脉冲异常检测、时钟漂移监控等，支持用户自定义错误处理策略。

• Diagnostic and Error Handling Configuration: Built-in comprehensive diagnostic function configuration, including CRC error detection, synchronization pulse anomaly detection, clock drift monitoring, etc., supporting user-defined error handling strategies.

• 代码自动生成：基于配置自动生成符合AUTOSAR标准的SENT驱动代码和配置文件，无缝集成到MCAL层，减少90%以上的手动编码工作。

• Automatic Code Generation: Automatically generates AUTOSAR-standard-compliant SENT driver code and configuration files based on configuration, seamlessly integrating into the MCAL layer, reducing manual coding work by over 90%.

6.3 配置界面展示Configuration Interface Display

下图展示了知从科技木牛配置工具的SENT协议配置界面，用户可以通过图形化界面轻松完成协议参数配置：

The following figure shows the SENT protocol configuration interface of the ZC.MuNiu Configuration Tool, where users can easily complete protocol parameter configuration through a graphical interface:

[知从科技木牛配置工具SENT协议配置界面截图]

[Screenshot of ZC.MuNiu Configuration Tool SENT Protocol Configuration Interface]

6.4 典型配置流程Typical Configuration Workflow

1. 通道启用与命名：在配置界面选择SENT模块，启用所需通道并设置通道名称

1. Channel Enable and Naming: Select the SENT module in the configuration interface, enable the required channels, and set channel names.

2. Tick时间配置：根据传感器规格设置Tick时间（通常3-10μs）

2. Tick Time Configuration: Set Tick time according to sensor specifications (typically 3-10μs).

3. 帧格式配置：选择数据Nibble数量（1-6个）、是否使用暂停脉冲

3. Frame Format Configuration: Select the number of data Nibbles (1-6) and whether to use pause pulses.

4. SPC模式配置（可选）：如需双向通信，启用SPC模式并配置MTP参数

4. SPC Mode Configuration (Optional): If bidirectional communication is required, enable SPC mode and configure MTP parameters.

5. 信号映射：将SENT数据Nibble映射到应用层信号变量

5. Signal Mapping: Map SENT data Nibbles to application-layer signal variables.

6. 诊断配置：启用CRC校验、同步脉冲监控等诊断功能

6. Diagnostic Configuration: Enable diagnostic functions such as CRC checksum and synchronization pulse monitoring.

7. 代码生成：一键生成配置文件和驱动代码，集成到项目中

7. Code Generation: One-click generation of configuration files and driver code for integration into the project.

7 结语：拥抱SENT，智驭未来Conclusion: Embrace SENT, Drive the Future with Intelligence

在汽车电子向着更智能、更集成、更可靠方向发展的今天，SENT协议在精度、可靠性、成本这个传统的不可能三角中，找到了一个优雅的平衡点。它并非意在取代复杂的CAN或FlexRay网络，而是作为其关键补充，在点对点、高精度、高可靠的传感器通信场景中，提供了无可替代的最优解。

As automotive electronics evolves toward greater intelligence, integration, and reliability today, the SENT protocol has found an elegant balance point in the traditional "impossible triangle" of accuracy, reliability, and cost. It is not intended to replace complex CAN or FlexRay networks, but rather serves as a crucial complement, providing an irreplaceable optimal solution for point-to-point, high-precision, high-reliability sensor communication scenarios.

对于汽车电子工程师而言，掌握并应用SENT协议，意味着能为产品赋予更高的性能、更强的鲁棒性和更优的成本结构。而对于希望在项目中快速落地SENT协议的开发者，知从科技木牛配置工具提供了全方位的技术支持。

For automotive electronics engineers, mastering and applying the SENT protocol means endowing products with higher performance, stronger robustness, and better cost structures. For developers seeking to rapidly implement the SENT protocol in their projects, the ZC.MuNiu Configuration Tool provides comprehensive technical support.

知从科技木牛配置工具核心优势

Core Advantages of ZC.MuNiu Configuration Tool

★ 开箱即用：完整的SENT协议栈支持，无需从零开发，缩短项目周期50%以上

★ Ready to Use: Complete SENT protocol stack support, no need to develop from scratch, reducing project cycle by over 50%.

★ 可视化配置：直观的图形界面，大幅降低协议配置复杂度，减少人为错误

★ Visual Configuration: Intuitive graphical interface, significantly reducing protocol configuration complexity and human errors.

★ AUTOSAR兼容：生成符合AUTOSAR标准的代码和配置，无缝集成主流AutoSAR工具链

★ AUTOSAR Compatible: Generates AUTOSAR-standard-compliant code and configuration, seamlessly integrating with mainstream AUTOSAR toolchains.

★ 一站式服务：从配置到代码生成、从调试到验证，提供全流程技术支持

★ One-Stop Service: From configuration to code generation, from debugging to verification, providing full-process technical support.

★ 持续更新：紧跟SAE标准演进，持续更新协议支持，保障技术领先性

★ Continuous Updates: Following SAE standard evolution, continuously updating protocol support to ensure technological leadership.

★ 本土化支持：国内专业团队提供及时的技术支持和服务响应

★ Localized Support: Domestic professional teams provide timely technical support and service response.

1  功能概述functional overview

知从木牛基础软件平台（ ZC.MuNiu ）为汽车电子控制器产品开发，提供完整的基础软件平台解决方案。该产品参考AUTOSAR、OSEK等国际规范。有基于AUTOSAR ARTOP架构的上位机配置工具，支持上汽、一汽、吉利、广汽、长安、长城等整车厂通讯、诊断、网络管理规范。

ZC.MuNiu provides a comprehensive basic software platform solution for the development of automotive electronic control units. This product refers to international standards such as AUTOSAR and OSEK, and has a configuration tool based on the AUTOSAR ATOP architecture that supports communication, diagnostics, and network management specifications for major OEMs like SAIC Motor, FAW, Geely, GAC Group, Changan Automobile, and Great Wall Motors. 

知从木牛基础软件平台，主要包括：操作系统、通讯协议栈（CAN\ LIN）、诊断协议栈(UDS\OBD\J1939)、网络管理（OSEK\AUTOSAR）、标定协议栈（XCP\CCP）、存储协议栈、加密模块（CRYPTO）、复杂驱动等模块，配套知从的Bootloader刷新程序和上位机工具，可以根据不同的客户项目要求进行配置和再开发。知从科技提供基础软件产品的同时，也提供控制器基础软件功能实现的开发服务。

The platform mainly includes: operating system, communication protocol stack (CAN/LIN), diagnostic protocol stack (UDS/J1939), network management (OSEK/AUTOSAR), calibration protocol stack (XCP/CCP), storage protocol stack, complex driver modules, etc., along with ZC 's bootloader update program and configuration tool, which can be configured and redeveloped according to different customer project requirements. While providing basic software products, ZC also offers development services for the implementation of controller basic software functions.

CanIf模块将底层不同的Can驱动，CanTrcv驱动抽象化，方便上层模块统一通过CanIf模块进行访问。在AUTOSAR架构中，其上层模块主要为PduR，CanTp，J1939Tp，CanNm，CanSm等。CanIf主要功能包含L-PDU的接收指示，L-PDU的发送及发送确认等通信功能， 以及Can Controller/Trcv的模式控制，波特率切换，睡眠唤醒等其它功能栈功能。

The CanIf module abstracts different underlying Can and CanTrcv drivers, facilitating unified access by upper-layer modules through the CanIf module. In the AUTOSAR architecture, the upper-layer modules mainly include PduR, CanTp, J1939Tp, CanNm, CanSm, etc. The main functions of CanIf include communication functions such as L-PDU reception indication, L-PDU transmission and transmission confirmation,as well as CAN controller/Trcv management, covering mode control, baud rate switching, and sleep/wake-up capabilities.

2  应用领域APPLICATION FIELD

Ø  发动机管理系统（EMS）

Engine Management System (EMS)

Ø  变速器控制器（TCU）

Transmission Control Unit (TCU)

Ø  制动控制器（BCU）

Brake Control Unit (BCU)

Ø  电机控制器（MCU）

Motor Control Unit (MCU)

Ø  电子驻车系统（EPB）

Electronic Parking Brake (EPB)

Ø  电池管理系统控制器（BMS）

Battery Management System (BMS)

3  配置环境CONFIGURATION ENVIRONMENT

4  开发背景 DEVELOPMENT BACKGROUND

AUTOSAR组织成立于2003年，主要由欧洲汽车制造商、部件供应商及其他电子、半导体和软件系统公司联合建立。致力于为汽车工业开发一个开放的、标准化的软件架构；希望大家“在标准上合作，在应用上竞争”提高基础平台的稳定，降低成本，提高控制器产品开发质量和速度。2006年底发布了2.1版规范，2008年发布3.1版本开始产品化；后续逐步增加了功能安全，以太网等内容，目前广泛使用2014年后发布的4.2.1和4.2.2版本，以及4.3.1版本。

The AUTOSAR organization was established in 2003, mainly by European car manufacturers, component suppliers, and other electronics, semiconductor, and software system companies. It is committed to developing an open, standardized software architecture for the automotive industry; the goal is for everyone to "cooperate on standards and compete on applications," improving the stability of the basic platform, reducing costs, and enhancing the quality and speed of controller product development. The 2.1 version of the specification was released at the end of 2006, and the 3.1 version was released in 2008 for productization; subsequently, functional safety, Ethernet, and other contents were gradually added. Currently, the widely used versions are 4.2.1 and 4.2.2 released after 2014, as well as version 4.3.1

知从.木牛（ ZC.MuNiu ）为汽车电子控制器产品开发，提供完整的基础软件平台解决方案。该产品符合AUTOSAR、OSEK等国际规范，有基于AUTOSAR ARTOP架构的上位机配置工具，支持上汽、一汽、吉利、广汽、长安、长城等整车厂通讯、诊断、网络管理规范。该平台主要包括：操作系统、通讯协议栈（CAN\ LIN）、诊断协议栈(UDS\OBD\J1939)、网络管理（OSEK\AUTOSAR）、标定协议栈（XCP\CCP）、存储协议栈、加密模块（CRYPTO）、复杂驱动等，配套知从Bootloader刷新程序和上位机工具，可以根据不同的客户项目要求进行配置和再开发。

ZC.MuNiu provides a comprehensive basic software platform solution for the development of automotive electronic control unit products. This product complies with international standards such as AUTOSAR and OSEK, and features a configuration tool based on the AUTOSAR ATOP architecture, supporting communication, diagnostics, and network management specifications for major vehicle manufacturers like SAIC Motor, FAW, Geely, GAC Group, Changan Automobile, and Great Wall Motors.  The platform mainly includes: operating system, communication protocol stack (CAN/LIN), diagnostic protocol stack (UDS/J1939), network management (OSEK/AUTOSAR), calibration protocol stack (XCP/CCP), storage protocol stack, complex driver modules, etc. It is equipped with ZC 's bootloader update program and upper computer tool, which can be configured and redeveloped according to different customer project requirements.

知从科技提供基础软件产品的同时，也提供符合ASPICE Level2和功能安全ASILB\D要求的控制器基础软件功能实现的开发服务，以及SBC芯片等软件的定制开发。

ZC not only provides basic software products but also offers development services for the implementation of control unit basic software functions that comply with ASPICE Level 2 and functional safety requirements ASIL B/D. In addition, it provides customized software development for SBC (Safety-Critical Base Control) chips and similar components.

知从科技掌握AUTOSAR平台软件的开发和应用核心技术，提供本地现场支持，质量好，速度快，成本低。

ZC has mastered the core technology of development and application of the AUTOSAR platform software, providing on-site local support with high quality, fast speed, and low cost.

5  功能描述FUNCTIONAL DESCRIPTION

5.1     CAN 协议栈Protocol Stack

CanIf模块的状态机控制，包括未初始化和已初始化状态，除了CanIf_Init 和CanIf_GetVersionInfo之外，都需要在已初始化状态下才能正常调用。

The state machine control of the CanIf module includes UNINITIALIZED and INITIALIZED states. With the exception of CanIf_Init and CanIf_GetVersionInfo, all other API functions require the module to be in the INITIALIZED state for proper operation.

Controller模式控制，分为STOPPED，STARTED，SLEEP三种，只有在START状态下Controller才能正常通信。Trcv模式控制，分为NORMAL，STANDBY，SLEEP三种，只有在NORMAL状态下Trcv才能正常通信。Controller的Pdu模式控制，分为OFFLINE，TX_OFFLINE，TX_OFFLINE_ACTIVE，ONLINE四种， ONLINE模式下允许正常收发通信，TX_OFFLINE模式下只能接收不能发送， TX_OFFLINE_ACTIVE模式下允许接收和虚拟发送，OFFLINE模式下不允许收发通信。

The Controller supports three modes: STOPPED, STARTED, and SLEEP. Normal communication is possible only when the Controller is in the STARTED state. Trcv supports three modes: NORMAL, STANDBY, and SLEEP. Normal communication is possible only when Trcv is in the NORMAL state. The Controller supports four PDU modes: OFFLINE, TX_OFFLINE, TX_OFFLINE_ACTIVE, and ONLINE. In the ONLINE mode, both transmission and reception are allowed; in the TX_OFFLINE mode, only reception is allowed and transmission is not permitted; in the TX_OFFLINE_ACTIVE mode, reception and virtual transmission are allowed; in the OFFLINE mode, both transmission and reception are not allowed.

CAN协议栈具有以下特点：

The CAN protocol stack has the following characteristics:

Ø  TxPdu发送功能：TxPdu Transmission Function:

当模块初始化成功，Controller模式及其Pdu模式，Trcv模式均处于允许发送状态时，可通过CanIf两种发送机制来发送L-Pdu: 上层模块调用CanIf_Transmit请求TxPdu的发送，发送时机由上层决定；下层驱动调用CanIf_TriggerTransmit请求TxPdu的发送数据，发送时机由下层决定；

When the module is successfully initialized and the Controller, PDU, and Trcv modes all enter a transmit-enabled state, L-PDUs can be sent using either of the two transmission mechanisms provided by CanIf: The upper-layer module calls CanIf_Transmit to request the transmission of TxPdu. The transmission timing is determined by the upper layer. The lower-layer driver calls CanIf_TriggerTransmit to request TxPDU data for transmission. The transmission timing is determined by the lower layer.

Ø  RxPdu接收功能：RxPdu Reception Function:

当模块初始化成功，Controller模式及其Pdu模式，Trcv模式均处于允许接收状态时，将从驱动层接收到的报文，传递到上层模块。当驱动层邮箱收到报文后，调用CanIf_RxIndication将接收数据传递到CanIf模块，CanIf通过接收的HRH以及CanId， 查询匹配到接收RxPdu，调用关联上层模块的将接收RxPdu数据传递给上层模块。

When the module is successfully initialized and the Controller, PDU, and Trcv modes all enter a receive-enabled state, any messages received from the driver layer will be passed up to the upper-layer module. When a message is received in the driver layer's mailbox, it invokes CanIf_RxIndication to deliver the data to the CanIf module. Using the received HRH and CanId, CanIf looks up the matching Rx PDU and then calls the correspondingcallback to pass the received data to the associated upper-layer module.

Ø  睡眠唤醒功能：Sleep and Wake-up Function:

上层模块可以通过CanIf来将Controller/Trcv设置为SLEEP模式，支持Controller/Trcv唤醒源检测，Controller/Trcv唤醒确认，Trcv唤醒原因获取，Trcv唤醒标志位检测/清除，Trcv唤醒模式设置。CanIf提供CanIf_SetControllerMode/CanIf_SetTrcvMode来设置Controller/Trcv的模式(包含SLEEP模式)， 当发生唤醒事件后可通过调用CanIf_CheckWakeup来检测是否由Controller/Trcv导致的唤醒事件， 可通过CanIf_CheckValidation来检测唤醒成功确认(唤醒确认条件为接收到任意Pdu/NM Pdu， 参见配置项CanIfPublicWakeupCheckValidByNM是否勾选)。

The upper-layer module can set the Controller/Trcv to SLEEP mode through CanIf. CanIf supports Controller/Trcv wake-up source detection, Controller/Trcv wake-up confirmation, Trcv wake-up reason retrieval, Trcv wake-up flag detection/clearance, and Trcv wake-up mode setting. CanIf provides CanIf_SetControllerMode/CanIf_SetTrcvMode to set the mode of Controller/Trcv (including SLEEP mode). When a wake-up event occurs, CanIf_CheckWakeup can be called to detect whether the event is caused by the Controller/Trcv. CanIf_CheckValidation can be used to confirm the wake-up (a wake-up is confirmed upon receipt of any Pdu/NM Pdu, see whether the configuration item CanIfPublicWakeupCheckValidByNM is checked).

5.2  软件架构 Software Architecture

知从木牛基础软件平台架构
ZC.MUNIU basic software platform ARCHITECTURE

5.3 配置工具Configuration Tool

木牛配置工具主界面
MUNIU CONFIGURATION TOOL MAIN INTERFACE

为了满足客户的不同项目需求，提高基础软件平台的扩展性， 木牛基础软件平台实现了各个模块可配置性，并且实现了配置工具。客户可根据不同需求，在配置工具上完成各个模块的配置工作，可生成配置代码文件，将生成的配置文件集成到工程中即可。

To meet the diverse project requirements of our clients and enhance the extensibility of the basic software platform, ZC.MuNiu Basic Software Platform has implemented configurable modules and a configuration tool. Customers can use the configuration tool to tailor the modules according to their specific needs, generate configuration code files, and integrate these generated configuration files into their projects. This approach allows for a high degree of customization and adaptability, ensuring that the software platform can be easily adapted to various applications and use cases.

木牛配置工具架构
ZC.MUNIU CONFIGURATION TOOL ARCHITECTURE

木牛基础软件平台的配置工具是基于Eclipse平台，并基于ARTOP架构，实现AUTOSAR模型和ARXML的解析。除了AUTOSAR标准定义的模块之外，还支持OEM和Tie1厂商二次开发自己的模块。配置完成后，可生成各个模块的配置代码。

 ZC.MuNiu basic software platform configuration tool is based on the Eclipse platform and is built on the ARTOP architecture, which implements the parsing of the AUTOSAR model and ARXML. In addition to the modules defined by the AUTOSAR standard, it also supports OEM and Tie1 manufacturers to develop their own modules for secondary development. After the configuration is completed, the configuration code for each module can be generated.

6   过程文档PROCESS DOCUMENTATION

7  证书CERTIFICATE

木牛软件著作权登记证书
MUNIU SOFTWARE COPYRIGHT REGISTRATION CERTIFICATE 

1  概述

在软件定义汽车（SDV）的浪潮下，汽车逐渐从“纯机械怪兽”演变为“移动的智能终端”。在这场变革中，底层软件的稳定性直接决定了上层应用的可靠性。作为汽车电子软件架构的中流砥柱，AUTOSAR 诊断协议栈（DiagnosticStack, 简称 DiagStack） 负责处理从物理层链路到Dcm诊断层的所有诊断数据交换。无论是下线检测（EOL）、售后维修，还是行车过程中的故障自检与安全降级，诊断栈都扮演着不可替代的角色。

2  DCM介绍

DCM 是诊断栈的对外窗口，负责处理外部诊断仪（Tester）与 ECU 之间的诊断通信。它直接对接 UDS (ISO 14229) 和 OBD (ISO 15031 / SAE J1979) 协议。在 AUTOSAR 规范中，DCM 被严谨地拆分为三个子层：DSL、DSD 和 DSP。

1、DSL (Diagnostic Session Layer - 诊断会话层)

DSL 负责管理整个诊断通信的状态机，处理会话（Session）切换和定时器（Timers）：

会话状态管理： 管理 Default Session（默认会话）、Programming Session（编程会话） 以及 Extended Session（扩展会话） 之间的跳转。控制在未收到诊断请求时，经过 S3Server 超时后自动回退到默认会话的逻辑。

通信定时参数控制： 严格控制 UDS 协议中定义的 P2 和 P2* 时间。

P2 Server：ECU 收到请求后，必须在此时间内给出响应。

P2 Server*：如果 ECU 无法在 P2 时间内完成处理（例如正在写入 Flash），DSL 必须向诊断仪发送0x7F 0x78（Pending，否定响应码 NRC 78），并启动 P2* 定时器，争取更多的处理时间。

安全访问等级（Security Access）： 管理解锁状态（Lock/Unlock）。配合 0x27 服务，DSL 会跟踪当前的 Security Level，确保只有通过密钥校验的诊断仪才能访问敏感数据或执行敏感例程。

2、DSD (Diagnostic Service Dispatcher - 诊断服务分发层)

DSD 处于承上启下的位置，主要负责对接收到的诊断请求（I-PDU）进行有效性校验，并将其准确分发：

服务 ID（SID）检查： 验证诊断仪发送的请求是否是当前架构支持的 UDS 服务。

权限仲裁： 检查请求的 SID 是否被允许在当前会话和当前安全等级下执行。例如，在 Default 状态下请求 0x2E（写 DID）或 0x31（例程控制），DSD会直接拒绝并返回对应的 NRC（Negative Response Code）。

格式与长度校验： 验证诊断报文的有效数据长度（Payload）是否符合该服务的规范。

3、DSP (Diagnostic Service Processing - 诊断服务处理层)

DSP 是具体业务逻辑的执行者。当 DSD 将合法的请求分发下来后，DSP 会解析具体的子服务（Sub-function）或数据标识符（DID），并调用底层的 SW-C（应用层软件）或 BSW 接口：

典型服务支持：

0x10 (DiagnosticSessionControl)： 切换诊断会话。

0x22 / 0x2E (Read/Write DataByIdentifier)： 读写标定参数或传感器数据（DID）。

0x19 (ReadDTCInformation)： 从 DEM 获取当前的故障码信息。

0x14 (ClearDiagnosticInformation)： 请求 DEM 清除故障内存。

0x31 (RoutineControl)： 启动、停止或查询 ECU 内部的特殊测试例程（如传感器校准、执行器动作测试）。

0x34 / 0x36 / 0x37 (Request Download/Transfer Data/Exit)： 在 Bootloader 刷写流程中，用于请求下载数据、传输数据切片和退出传输。

3  DEM介绍

DEM 是诊断栈的“中央数据库”，负责处理、记录和存储所有由 SW-C 或 BSW 模块上报的故障事件（Events）。它不仅仅是记录一个代码，而是维护一个庞大的故障状态机。

• 故障事件（Event）与 DTC 的映射

在 DEM 中，应用层上报的是 Event（事件），而对外（如 0x19 服务）呈现的是 DTC（Diagnostic Trouble Code）。

多个 Event 可以映射到同一个 DTC，或者一个 Event 对应一个独立的 DTC。

DEM 负责将具体的故障现象转换为符合 SAE J2012 或 ISO 15031-6 标准的 3 字节或 4 字节 DTC。

• 严苛的防抖（Debounce）机制

物理信号的抖动极易造成误报，DEM 提供了标准的防抖算法来过滤毛刺：

Counter-Based（基于计数器的防抖）： 每次检测到 Fail，计数器加 StepUp值；检测到 Pass，计数器减 StepDown 值。当计数器超过 JumpUp 阈值时，故障才被标记为 Pre-Failed；超过 Failed 阈值时，故障被确认为 Failed。

Time-Based（基于时间的防抖）： 故障必须持续指定的时间长度（如 200ms），DEM才会确认该故障。

• DTC 状态掩码（Status Mask）的精密流转

DEM 严格遵循 ISO 14229-1 标准，为每个 DTC 维护一个 8 位的状态字节（Status Byte）。这是 DEM 最核心的技术细节：

Bit 0 (TestFailed): 当前测试周期内，最后一次测试结果为失败。

Bit 1 (TestFailedThisOperationCycle): 当前操作周期（Operation Cycle）内，曾经发生过失败。

Bit 2 (PendingDTC): 故障已经初步发生，处于待定状态。

Bit 3 (ConfirmedDTC): 故障经过防抖和多次周期验证，被正式确认，将写入 NVRAM（非易失性存储）。

Bit 4 (TestNotCompletedSinceLastClear): 自上次清除故障码以来，该测试尚未完成。

Bit 5 (TestFailedSinceLastClear): 自上次清除故障码以来，该测试曾经失败过。

Bit 6 (TestNotCompletedThisOperationCycle): 当前操作周期内，该测试尚未完成。

Bit 7 (WarningIndicatorRequested): 该故障触发了仪表盘报警灯（MIL灯）的请求。

• 冻结帧（Freeze Frame）与扩展数据（EDR）

当 Bit 3 (ConfirmedDTC) 被置 1 的瞬间，DEM 会执行“现场抓拍”：

Freeze Frame (0x02)： 抓取发生故障瞬间的车辆关键上下文数据（如车速、发动机转速、电池电压、水温等），严格按照 DID 的形式打包存储。

Extended Data Record (0x06)： 记录故障发生的次数（Fault Counter）、连续未发生故障的周期数（Aging Counter）等统计数据。

• 故障老化（Fault Aging）与覆盖（Displacement）

Aging： 当一个故障在连续 N 个操作周期内都不再复现（测试结果持续为 Pass），DEM 会将其从 NVRAM 中清除，释放存储空间。

Displacement： 如果 NVRAM 空间已满，新发生的严重故障（如 ASIL D 级安全故障）会根据优先级（Priority），覆盖并替换掉那些不重要的、低优先级的历史故障码。

4  FIM介绍

FIM 是 DEM 与应用层 SW-C 之间的桥梁，专门用于处理故障后的整车策略响应和安全降级（Fail-Safe）。

• 什么是功能抑制？

当 DEM 确定某个部件损坏（例如电子节气门传感器故障）后，FIM 需要立即采取行动，禁止依赖该传感器的某些高级功能（如定速巡航、自动驾驶辅助），以防止系统发生误动作导致安全事故。

• FID（Function Inhibition Identifier）

在 FIM 中，每一个可以被独立禁止的应用层功能或算法模块，都会被分配一个唯一的标识符，称为 FID。

例如：FID_CruiseControl（定速巡航功能）、FID_ABS_Control（防抱死控制功能）。

• 抑制矩阵（Inhibition Matrix）

FIM 的核心是一张静态或动态配置的映射表（Matrix）。它定义了 DEM 的Event（事件）与 FIM 的 FID（功能标识）之间的对应关系。

示例关系： 当 Event_WheelSpeedSensor_Error（轮速传感器故障）的 DEM 状态满足特定条件（如 Confirmed 位被置 1）时，抑制矩阵会指示 FIM 激活对FID_ABS_Control 的抑制。

• FIM 与 SW-C 的交互机制

应用层软件组件（SW-C）在执行核心控制逻辑之前，必须主动向 FIM 申请权限。常见的交互方式有两种：

轮询模式（Polling）：SW-C 通过 RTE 调用 FIM 的 API（如 FiM_GetFunctionPermission），传入自己的 FID，询问“我当前是否被允许运行？”。

通知模式（Notification）： 当抑制矩阵的状态发生改变时，FIM 主动通过 RTE 将最新的FID 状态推送给对应的 SW-C。

通过这种解耦设计，应用层开发者在编写具体的控制算法时，不需要关心底层是哪个传感器坏了，只需要向 FIM 询问当前功能是否可用，从而极大地提高了软件的模块化程度。

5  知从木牛CAN诊断协议栈

理论的严谨性最终需依托强大的工程平台方能转化为量产价值。针对智能汽车对底层软件日益增长的需求，知从木牛基础软件平台可以帮助OEM和Tier1更加快速的实现控制器开发。

作为一款立足于正向研发的BSW 产品，知从木牛基础软件平台在诊断与通信领域具备显著的技术优势：

前瞻性技术标准： 平台原生支持并满足 AUTOSAR R25-11 最新版本的规范要求，为客户提供具备高度前瞻性的控制器软件架构方案。

最高等级安全准则： 研发全流程深度契合 ISO 26262 功能安全标准，完全满足最高 ASIL D 级别的开发要求。从底层驱动到复杂的诊断事件管理，我们通过严谨的验证体系确保每一行代码的安全性。

高效本土化技术支持： 依托经验丰富的核心研发团队，知从科技致力于提供极速响应的本土化支持。无论是复杂的诊断策略配置，还是 CanTp 链路的深度调优，我们均能提供保姆式的工程咨询与定制服务，协助客户大幅缩短项目 SOP 周期。

木牛配置工具架构

为了满足客户的不同项目需求，提高基础软件平台的扩展性， 木牛基础软件平台实现了各个模块可配置性，并且实现了配置工具。客户可根据不同需求，在配置工具上完成各个模块的配置工作，可生成配置代码文件，将生成的配置文件集成到工程中即可。

木牛基础软件平台的配置工具是基于Eclipse平台，并基于ARTOP架构，实现AUTOSAR模型和ARXML的解析。除了AUTOSAR标准定义的模块之外，还支持OEM和Tie1厂商二次开发自己的模块。配置完成后，可生成各个模块的配置代码。

Amidst the wave of Software-Defined Vehicles (SDVs), automobiles are gradually evolving from "purely mechanical beasts" into "mobile intelligent terminals." In this transformation, the stability of the underlying software directly determines the reliability of the upper-layer applications. As a cornerstone of automotive electronics software architecture, the AUTOSAR Diagnostic Stack (DiagStack) is responsible for handling all diagnostic data exchange—ranging from the physical layer link up to the Diagnostic Communication Manager (DCM) layer. Whether for End-of-Line (EOL) testing, after-sales maintenance, or in-vehicle fault self-diagnostics and safety degradation during operation, the Diagnostic Stack plays an indispensable role.

2  Introduction to DCM

DCM serves as the external interface of the diagnostic stack, responsible for managing diagnostic communication between an external diagnostic tool (Tester) and the ECU. It interfaces directly with the UDS (ISO 14229) and OBD (ISO 15031 / SAE J1979) protocols. Within the AUTOSAR specification, the DCM is rigorously partitioned into three distinct sub-layers: DSL, DSD, and DSP.

1. DSL (Diagnostic Session Layer)

The DSL is responsible for managing the state machine governing the entire diagnostic communication process, handling session transitions and timers:

Session State Management: Manages transitions between the Default Session, Programming Session, and Extended Session. It controls the logic for automatically reverting to the Default Session—specifically after the S3Server timeout expires—should no diagnostic requests be received.

Communication Timing Parameter Control: Strictly controls the P2 and P2* timing parameters defined within the UDS protocol.

P2 Server: The ECU must provide a response within this specified timeframe after receiving a request.

P2 Server*: If the ECU is unable to complete processing within the P2 timeframe (e.g., while writing to Flash memory), the DSL must send a 0x7F 0x78 response (indicating "Pending"—Negative Response Code NRC 78) to the diagnostic tool, thereby initiating the P2* timer to secure additional processing time.

Security Access Levels: Manages the lock/unlock status. In conjunction with Service 0x27, the DSL tracks the current Security Level, ensuring that only diagnostic tools that have successfully passed key validation can access sensitive data or execute sensitive routines.

2. DSD (Diagnostic Service Dispatcher)

The DSD occupies a pivotal position within the architecture; its primary responsibility is to validate the integrity of incoming diagnostic requests (I-PDUs) and accurately dispatch them to the appropriate handlers:

Service ID (SID) Check: Verifies whether the request sent by the diagnostic tool corresponds to a UDS service currently supported by the system architecture.

Authorization Arbitration: Checks whether the requested SID is permitted to be executed within the context of the current diagnostic session and the current security access level. For example, if a request for 0x2E (Write DID) or 0x31 (Routine Control) is received while in the Default state, the DSD will immediately reject it and return the corresponding NRC (Negative Response Code).

Format and Length Validation: Verifies whether the effective data length (Payload) of the diagnostic message complies with the specifications for the requested service.

3. DSP (Diagnostic Service Processing)

The DSP is the executor of the specific business logic. Once the DSD has dispatched a valid request, the DSP parses the specific Sub-function or Data Identifier (DID) and invokes the underlying SW-C (Application Layer Software) or BSW interfaces:

Typical Service Support:

0x10 (DiagnosticSessionControl): Switches the diagnostic session.

0x22 / 0x2E (Read/Write DataByIdentifier): Reads or writes calibration parameters or sensor data (DIDs).

0x19 (ReadDTCInformation): Retrieves current Diagnostic Trouble Code (DTC) information from the DEM.

0x14 (ClearDiagnosticInformation): Requests the DEM to clear the fault memory.

0x31 (RoutineControl): Starts, stops, or queries special internal test routines within the ECU (e.g., sensor calibration, actuator actuation tests).

0x34 / 0x36 / 0x37 (Request Download/Transfer Data/Exit): Used during the Bootloader flashing process to request data download, transfer data segments, and exit the transfer mode.

3  Introduction to DEM

The DEM serves as the "central database" of the diagnostic stack, responsible for processing, recording, and storing all fault events reported by SW-C or BSW modules. It does not merely record a simple code; rather, it maintains an extensive state machine for fault conditions.

1. Mapping of Fault Events to DTCs

Within the DEM, the Application Layer reports *Events*, whereas the interface exposed to external entities (e.g., via Service 0x19) presents *DTCs* (Diagnostic Trouble Codes).

Multiple Events may be mapped to a single DTC, or a single Event may correspond to a unique, standalone DTC.

The DEM is responsible for translating specific fault phenomena into 3-byte or 4-byte DTCs that comply with the SAE J2012 or ISO 15031-6 standards.

2. Robust Debouncing Mechanisms

Fluctuations in physical signals can easily lead to false positives; consequently, the DEM provides standard debouncing algorithms to filter out such transient spikes:

Counter-Based Debouncing: Each time a "Fail" condition is detected, a counter is incremented by a specified *StepUp* value; conversely, if a "Pass" condition is detected, the counter is decremented by a *StepDown* value. A fault is flagged as *Pre-Failed* only when the counter exceeds a specific *JumpUp* threshold; it is formally confirmed as *Failed* only when the counter surpasses the *Failed* threshold.

Time-Based Debouncing: A fault must persist for a specified duration (e.g., 200 ms) before the DEM formally confirms its existence.

3. Precise State Transitions for DTC Status Masks

The DEM strictly adheres to the ISO 14229-1 standard, maintaining an 8-bit *Status Byte* for each DTC. This constitutes the most critical technical detail within the DEM:

Bit 0 (TestFailed): The result of the most recent test execution within the current test cycle was a failure.

Bit 1 (TestFailedThisOperationCycle): A failure condition has occurred at least once during the current *Operation Cycle*.

Bit 2 (PendingDTC): The fault has preliminarily occurred and is currently in a pending state.

Bit 3 (ConfirmedDTC): The fault has undergone debouncing and verification across multiple cycles; it is now formally confirmed and will be written to NVRAM (Non-Volatile Random Access Memory).

Bit 4 (TestNotCompletedSinceLastClear): The specific diagnostic test associated with this DTC has not yet been completed since the last time the fault codes were cleared. Bit 5 (TestFailedSinceLastClear): This test has failed at least once since the last clearing of fault codes.

Bit 6 (TestNotCompletedThisOperationCycle): This test has not yet completed within the current operation cycle.

Bit 7 (WarningIndicatorRequested): This fault has triggered a request for the dashboard warning light (MIL) to illuminate.

4. Freeze Frame and Extended Data Record (EDR)

The moment Bit 3 (ConfirmedDTC) is set to 1, the DEM performs a "snapshot capture":

Freeze Frame (0x02): Captures key vehicle context data (such as vehicle speed, engine RPM, battery voltage, coolant temperature, etc.) at the exact instant the fault occurred, packaging and storing it strictly according to the DID format.

Extended Data Record (0x06): Records statistical data, such as the number of times the fault has occurred (Fault Counter) and the number of consecutive operation cycles during which the fault did not recur (Aging Counter).

5. Fault Aging and Displacement

Aging: If a fault does not recur for N consecutive operation cycles (i.e., the test result remains "Pass" continuously), the DEM will clear it from NVRAM, thereby releasing storage space.

Displacement: If the NVRAM storage space is full, a newly occurring severe fault (e.g., an ASIL D-level safety-critical fault) will—based on its Priority—overwrite and replace less critical, lower-priority historical fault codes.

4  Introduction to FIM

FIM serves as the bridge between the DEM and the Application Layer SW-Cs, specifically designed to manage vehicle-level strategic responses and safety degradation (Fail-Safe) measures following a fault.

• What is Function Inhibition?

When the DEM identifies a component failure (e.g., an electronic throttle sensor fault), the FIM must take immediate action to inhibit certain advanced functions that rely on that sensor (such as cruise control or automated driving assistance systems). This prevents system malfunctions that could potentially lead to safety incidents.

• FID (Function Inhibition Identifier)

Within the FIM, every application-layer function or algorithm module capable of being independently inhibited is assigned a unique identifier, known as an FID.

Examples: FID_CruiseControl (Cruise Control Function), FID_ABS_Control (Anti-lock Braking System Control Function).

• Inhibition Matrix

At the core of the FIM lies a statically or dynamically configured mapping table (Matrix). This matrix defines the correspondence between DEM Events and FIM FIDs.

Example Relationship: When the DEM status for a specific event—such as Event_WheelSpeedSensor_Error (Wheel Speed Sensor Fault)—meets certain criteria (e.g., the "Confirmed" bit is set to 1), the Inhibition Matrix instructs the FIM to activate the inhibition of the FID_ABS_Control function.

• Interaction Mechanism between FIM and SW-Cs

Before executing their core control logic, Application Layer Software Components (SW-Cs) must actively request permission from the FIM. There are two common interaction methods:

Polling Mode: The SW-C invokes a specific FIM API (e.g., `FiM_GetFunctionPermission`) via the RTE, passing its own FID to query: "Am I currently permitted to execute?"

Notification Mode: Whenever the state of the Inhibition Matrix changes, the FIM proactively pushes the latest status of the relevant FID to the corresponding SW-C via the RTE.

Through this decoupled design, application-layer developers—when writing specific control algorithms—do not need to concern themselves with which underlying sensor has failed; they simply need to query the FIM to determine whether the current function is available. This approach significantly enhances the modularity of the software.

5  ZC.MuNiu CAN DIAGNOSTIC PROTOCOL STACK

The rigor of theoretical concepts must ultimately be underpinned by a robust engineering platform to be successfully translated into value for mass production. Addressing the growing demand for foundational software in intelligent vehicles, the Zhicong Muniu foundational software platform empowers OEMs and Tier 1 suppliers to accelerate the development of control units.

As a BSW product built upon a foundation of forward engineering, the Zhicong MuNiu Basic Software Platform demonstrates significant technical advantages in the domains of diagnostics and communication:

Forward-Looking Technical Standards: The platform offers native support for—and complies with—the specifications of the latest AUTOSAR R25-11 release, providing customers with a highly forward-looking software architecture solution for their controllers.

Highest-Level Safety Standards: The entire R&D lifecycle is deeply aligned with the ISO 26262 functional safety standard, fully meeting the development requirements for the highest safety integrity level, ASIL D. From low-level drivers to complex diagnostic event management, we employ a rigorous verification framework to ensure the safety and security of every single line of code.

Efficient Localized Technical Support: Backed by a highly experienced core R&D team, Zhicong Technology is committed to providing rapid-response, localized technical support. Whether the task involves configuring complex diagnostic strategies or performing in-depth optimization of CAN-TP links, we offer comprehensive, hands-on engineering consulting and customization services to help our customers significantly accelerate their project SOP (Start of Production) timelines.

To meet the requirements of customer and enhance the extensibility of the basic software platform, ZC.MuNiu has implemented configurable modules and configuration tool. Customers can use the configuration tool to configthe modules according to their specific needs, generate configuration code files, and integrate these files into projects. 

ZC.MuNiu basic software platform configuration tool is based on the Eclipse platform and is built on the ARTOP architecture, which implements the parsing of the AUTOSAR model and ARXML. In addition to the modules defined by the AUTOSAR standard, it also supports OEM and Tie1 manufacturers to develop their own modules for secondary development. After the configuration is completed, the configuration code for each module can be generated.

支持AUTOSAR的哪些模块呢？