Can通信矩阵DBC文件制作Autosar开发流程
Can通信矩阵
基本定义
Can通信矩阵是描述Can控制器局域网总线系统中所有通信报文及其包含信号的结构化、标准化数据规范文档。通常格式为.dbc、 数据库文件、execel表格、或专用格式，通信矩阵通常由整车制造商OEM或者系统集成者进行设计，定义同时发布，是整车电子电气架构中各电子控制单元ECU之间通过Can总线进行数据交换的唯一权威契约跟通信蓝图。然后Can通信矩阵信号由节点、报文、信号组成。
通常情况下要根据Can通信矩阵的execel表格的输入跟输出来做.dbc文件，有了.dbc文件再去做底软开发或者应用层开发。
| 元素层级 | 描述与定义 |
|---|---|
| 节点 (Node) | 指CAN网络中的一个通信单元，通常是一个ECU（例如发动机控制器、车身控制器）。 |
| 报文 (Message) | 总线上一个节点发送给其他节点的数据帧。一个节点可以发送多种报文。 |
| 信号 (Signal) | 报文数据场中的具体参数，是通信的最小数据单元，例如“车速”、“发动机转速”。一个报文通常包含多个信号。 |
常用术语
Network-can网络，一个车上有很多Can网络，底盘Can，然后诊断Can，同时可以叫Can1、Can2、Can3
Node-Can网络，在单个Can网络中挂在的节点，一个节点对应一个ECU
Message ECU在Can网络中发送的消息
Signal-信号发送话题的具体内容。
Messge属性
name
Type
ID
DLC
TR
TX
Cycle Time
Signal属性
Name
Length
Byte Orader
Value Tyep
Unit
Factor
Offset
Min and Max
Value Table
Byte Order字节序
LSB：最低有效位
MSB：最高有效位
Intel：小端模式，LSB在低字节低位，MSB在高字节高位。
Motorola：大端模式，lSB在高字节的低位，MSB在低字节的高位。
不论是Intel还是Motorola起始位都是LSB，
信号在不跨字节的情况下，Intel跟Motorola格式编码结构都是没有区别的
一个DBC数据库中信号排布方式只能选择一种(Intel或Motorola)，一般两种模式不会存在一个DBC文件中。
DBC文件制作
首先DBC文件使用的是Vector CANdb++软件进行制作，这个软件是免费的，这里下载软件然后新建一个工程具体截图如下所示。
然后一个dbc工程文件里面，包含Message跟Signal信号具体截图如下所示，然后还包含NodeNoteword 节点
为什么需要Can通信矩阵
总的来说通过使用Vector Candb++制作dbc文件能够展现出在一个Can网络中所有的节点Node，每个节点收发不同的Message的情况。
Autosar开发流程框架
Autosar-CP架构介绍
在软件定义汽车的背景下，Autoasr作为汽车行业广泛采用的软件架构标准，然后CP架构应用而生,在整个CP架构中主要分为ASW应用层RTE中间层也就是实时运行层，以及BSW底层，同时BSW底层又能够细分为三个层。
应用层 (Application Layer)
包含实现具体控制逻辑的软件组件（SWC）。
通过标准化的端口（Ports）进行通信，不直接操作硬件。
运行时环境 (Runtime Environment, RTE)
作为中间层，隔离应用层与基础软件层。
负责SWC之间、SWC与基础软件之间的数据交换，实现了应用软件的硬件无关性。
基础软件层 (Basic Software, BSW)
为应用层提供底层服务（通信、内存管理、诊断、操作系统等
然后再BSW层跟ASW层进行通信的时候通过使用RTE层的各种接口。
BSW细分介绍
BSW底层又分为三个层，分别是MCAL层也就是
服务层：提供操作系统、网络管理、存储、诊断等服务。
ECU抽象层：屏蔽ECU硬件设计差异，提供统一的接口。
微控制器抽象层（MCAL）：直接访问微控制器寄存器，将硬件封装起来。
复杂驱动：为特殊硬件（如不在MCAL中定义的传感器）提供快速通道。
Autosar方法论-实例