设备、主设备及从设备
阅读：669发布：2020-05-14
专利汇可以提供设备、主设备及从设备专利检索，专利查询，专利分析的服务。并且本公开的 实施例 涉及设备、主设备及从设备。一种设备包括主设备、从设备集和总线。主设备被配置成传送第一消息和第二消息，第一消息携带操作数据消息部分集，该操作数据消息部分集指示用于由从设备集中的从设备实施的操作，第二消息被寻址到从设备集中的从设备。第二消息传达标识第二消息被寻址所至的从设备中的相应的从设备的标识符， 请求 在相应的预期反应间隔内对主设备做出相应的反应。从设备被配置成：接收从主设备传送的第一消息，读取操作数据消息部分集中的相应的操作数据消息部分，根据所读取的相应的操作数据消息部分来实施相应的操作，以及接收从主设备传送的第二消息。(ESM)同样的 发明 创造已同日 申请 发明 专利，下面是设备、主设备及从设备专利的具体信息内容。
1.一种设备，其特征在于，包括：
主设备；
从设备集；和
总线，其中所述主设备和所述从设备被配置成经由所述总线通信；
其中所述主设备被配置成传送：
第一消息，所述第一消息携带操作数据消息部分集，所述操作数据消息部分集指示用于由所述从设备集中的从设备实施的操作；和
第二消息，所述第二消息被寻址到所述从设备集中的从设备，所述第二消息传达标识所述从设备中的、所述第二消息被寻址所至的相应的从设备的标识符，所述第二消息请求在相应的预期反应间隔内对所述主设备做出相应的反应；并且
其中所述从设备被配置成：
在所述总线上接收从所述主设备传送的所述第一消息；
读取所述操作数据消息部分集中的相应的操作数据消息部分；
根据所读取的所述相应的操作数据消息部分来实施相应的操作；
在所述总线上接收从所述主设备传送的所述第二消息；以及
通过在所述总线上向所述主设备传送反应消息，在所述相应的预期反应间隔内对所述第二消息做出反应。
2.根据权利要求1所述的设备，其特征在于：
所述主设备被配置成传送包括初始化数据的初始化消息，所述初始化数据指示来自所述主设备的、在所述总线上传送的所述第一消息中的哪些操作数据消息部分专用于所述从设备中的相应的从设备；并且
所述从设备被配置成：接收来自所述主设备的、在所述总线上传送的所述初始化消息，并且根据所述初始化数据，来初始化对在所述操作数据消息部分集中的、专用于所述从设备的相应的操作数据消息部分的读取。
3.根据权利要求1所述的设备，其特征在于，所述从设备被布置在从设备的子集中，并且其中所述主设备被配置成传送包括子集标识索引的第一消息，所述子集标识索引标识所述第一消息所专用于的所述从设备的所述子集。
4.根据权利要求1所述的设备，其特征在于，所述主设备被配置成以恒定速率在所述总线上传送所述第一消息。
5.根据权利要求1所述的设备，其特征在于，作为相应的看门狗定时器到期的结果，所述从设备集中的从设备被配置成切换到故障安全状态。
6.根据权利要求1所述的设备，其特征在于，作为接收从所述第一消息和所述第二消息中选择的消息的结果，所述从设备集中的所述从设备被配置成将所述相应的看门狗定时器复位。
7.根据权利要求1所述的设备，其特征在于，所述主设备对于所请求的来自所述从设备集中的从设备的相应的反应未在所述相应的预期反应间隔内到达所述主设备敏感。
8.根据权利要求1所述的设备，其特征在于，所述主设备被配置成触发相应的看门狗错误信号，所述看门狗错误信号指示所述从设备集中的从设备，来自所述从设备中的相应的反应未在所述相应的预期反应间隔内到达所述主设备。
9.根据权利要求1所述的设备，其特征在于，所述总线包括差分布线总线。
10.一种主设备，其特征在于，被配置成经由总线与从设备集通信，所述主设备包括：
微控制器，被配置成耦合到所述总线，所述微控制器被配置成传送：
第一消息，所述第一消息携带操作数据消息部分集，所述操作数据消息部分集指示用于由所述从设备集中的从设备实施的操作；和
第二消息，所述第二消息被寻址到所述从设备集中的从设备，所述第二消息请求在相应的预期反应间隔内对所述主设备做出相应的反应，所述第二消息传达标识所述从设备中的、所述第二消息被寻址所至的相应的从设备的标识符。
11.根据权利要求10所述的主设备，其特征在于，所述主设备还包括：
主功率转换器，被耦合到所述微控制器；
低压差线性电压调节器、待机、复位和窗口以及看门狗电路块，被耦合到所述微控制器；
收发器电路，被耦合到所述微控制器；和
接入点，用于在外部通信总线和所述收发器之间通信。
12.根据权利要求10所述的主设备，其特征在于，所述主设备：
对于所请求的来自所述从设备集中的从设备的相应的反应未在所述相应的预期反应间隔内到达所述主设备敏感；或者
被配置成触发相应的看门狗错误信号，所述看门狗错误信号指示所述从设备集中的从设备，来自所述从设备中的相应的反应未在所述相应的预期反应间隔内到达所述主设备。
13.一种从设备，其特征在于，被包括在经由总线耦合到主设备的从设备集中，所述从设备包括：
收发器，被耦合到所述总线；
存储器；和
控制器，被耦合到所述收发器和所述存储器，所述控制器被配置成：
在所述总线上接收第一消息，所述第一消息携带操作数据消息部分集，所述操作数据消息部分集指示用于由所述从设备集中的从设备实施的操作；
读取所述操作数据消息部分集中的至少一个相应的操作数据消息部分；
根据所读取的所述至少一个相应的操作数据消息部分来实施至少一个相应的操作；
在所述总线上接收相应的第二消息，所述相应的第二消息传达将所述设备标识为所述从设备中的、所述相应的第二消息被寻址所至的从设备的标识符，所述相应的第二消息请求在相应的预期反应间隔内对所述主设备做出相应的反应；并且
在所述相应的预期反应间隔内对所述相应的第二消息做出反应，其中反应消息将在所述总线上从所述从设备传送到所述主设备。
14.根据权利要求13所述的从设备，其特征在于，作为相应的看门狗定时器到期的结果，所述控制器被配置成切换到故障安全状态。
15.根据权利要求13所述的从设备，其特征在于，作为经由所述总线从所述主设备接收消息的结果，所述控制器被配置成将所述相应的看门狗定时器复位。
16.根据权利要求13所述的从设备，其特征在于，所述控制器包括专用硬件。
17.根据权利要求13所述的从设备，其特征在于，所述从设备是光辐射源驱动器。
18.根据权利要求17所述的从设备，其特征在于，所述从设备是交通工具灯驱动器。
设备、主设备及从设备
技术领域
背景技术
[0003] 现有的高数据速率(例如，1Mb/s)标准化交通工具通信系统可能涉及使用外部部件的复杂且精确的协议控制器。这些可能变得昂贵，特别是当被实现为单芯片模拟/双极专用集成电路(ASIC)和/或专用标准产品(ASSP)时。
[0004] 交通工具灯(例如，前灯、后灯和内部灯)变得越来越复杂和分散化(例如，矩阵LED、环境LED)。控制这种复杂和分散式系统可能涉及高数据速率控制。而且，汽车级安全性和鲁棒性是所期望的，特别是对于前照明系统和后照明系统。
[0005] 例如，当采用诸如双极型CMOS-DMOS(BCD)技术的单芯片技术时，LED驱动器可以是成本高效的。另外注意到，使用例如BCD技术的高数据速率协议控制器可能很昂贵并且依赖于精确的时钟源(晶体)。
[0007] 因此，例如用于驱动分散式照明源(诸如LED矩阵)的交通工具中的通信网络的日益复杂性可能导致生产成本的增加，这可能与汽车工业中的商业模型难以兼容。
[0008] 例如，一个或多个实施例适用于CAN(控制器区域网络)总线。这是众所周知的布置，其可以有助于例如在没有主机计算机的情况下的微控制器和交通工具上的设备之间的通信。CAN总线的操作可以以基于消息的协议为基础，如在诸如例如ISO 11898-2:2015和ISO 11898-2:2016的标准中所处理的。实用新型内容
[0009] 在第一方面，提供了一种设备，包括：主设备；从设备集；和总线，其中主设备和从设备被配置成经由总线通信；其中主设备被配置成传送：第一消息，第一消息携带操作数据消息部分集，操作数据消息部分集指示用于由从设备集中的从设备实施的操作；和第二消息，第二消息被寻址到从设备集中的从设备，第二消息传达标识从设备中的、第二消息被寻址所至的相应的从设备的标识符，第二消息请求在相应的预期反应间隔内对主设备做出相应的反应；并且其中从设备被配置成：在总线上接收从主设备传送的第一消息；读取操作数据消息部分集中的相应的操作数据消息部分；根据所读取的相应的操作数据消息部分来实施相应的操作；在总线上接收从主设备传送的第二消息；以及通过在总线上向主设备传送反应消息，在相应的预期反应间隔内对第二消息做出反应。
[0010] 根据一个实施例，主设备被配置成传送包括初始化数据的初始化消息，初始化数据指示来自主设备的、在总线上传送的第一消息中的哪些操作数据消息部分专用于从设备中的相应的从设备；并且从设备被配置成：接收来自主设备的、在总线上传送的初始化消息，并且根据初始化数据来初始化对在操作数据消息部分集中的、专用于从设备的相应的操作数据消息部分的读取。
[0011] 根据一个实施例，从设备被布置在从设备的子集中，并且其中主设备被配置成传送包括子集标识索引的第一消息，子集标识索引标识第一消息所专用于的从设备的子集。
[0012] 根据一个实施例，主设备被配置成以恒定速率在总线上传送第一消息。
[0014] 根据一个实施例，作为接收从第一消息和第二消息中选择的消息的结果，从设备集中的从设备被配置成将相应的看门狗定时器复位。
[0015] 根据一个实施例，主设备对于所请求的来自从设备集中的从设备的相应的反应未在相应的预期反应间隔内到达主设备敏感。
[0016] 根据一个实施例，主设备被配置成触发相应的看门狗错误信号，看门狗错误信号指示从设备集中的从设备，来自从设备中的相应的反应未在相应的预期反应间隔内到达主设备。
[0017] 根据一个实施例，总线包括差分布线总线。
[0018] 在第二方面，提供了一种主设备，被配置成经由总线与从设备集通信，主设备包括：微控制器，被配置成耦合到总线，微控制器被配置成传送：第一消息，第一消息携带操作数据消息部分集，操作数据消息部分集指示用于由从设备集中的从设备实施的操作；和第二消息，第二消息被寻址到从设备集中的从设备，第二消息请求在相应的预期反应间隔内对主设备做出相应的反应，第二消息传达标识从设备中的、第二消息被寻址所至的相应的从设备的标识符。
[0019] 根据一个实施例，主设备还包括：主功率转换器，被耦合到微控制器；低压差线性电压调节器、待机、复位和窗口以及看门狗电路块，被耦合到微控制器；收发器电路，被耦合到微控制器；和接入点，用于在外部通信总线和收发器之间通信。
[0020] 根据一个实施例，主设备：对于所请求的来自从设备集中的从设备的相应的反应未在相应的预期反应间隔内到达主设备敏感；或者被配置成触发相应的看门狗错误信号，看门狗错误信号指示从设备集中的从设备，来自从设备中的相应的反应未在相应的预期反应间隔内到达主设备。
[0021] 在第三方面，提供了一种从设备，被包括在经由总线耦合到主设备的从设备集中，从设备包括：收发器，被耦合到总线；存储器；和控制器，被耦合到收发器和存储器，控制器被配置成：在总线上接收第一消息，第一消息携带操作数据消息部分集，操作数据消息部分集指示用于由从设备集中的从设备实施的操作；读取操作数据消息部分集中的至少一个相应的操作数据消息部分；根据所读取的至少一个相应的操作数据消息部分来实施至少一个相应的操作；在总线上接收相应的第二消息，相应的第二消息传达将设备标识为从设备中的、相应的第二消息被寻址所至的从设备的标识符，相应的第二消息请求在相应的预期反应间隔内对主设备做出相应的反应；并且在相应的预期反应间隔内对相应的第二消息做出反应，其中反应消息将在总线上从从设备传送到主设备。
[0022] 根据一个实施例，作为相应的看门狗定时器到期的结果，控制器被配置成切换到故障安全状态。
[0023] 根据一个实施例，作为经由总线从主设备接收消息的结果，控制器被配置成将相应的看门狗定时器复位。
[0027] 现在将参考附图仅通过示例的方式描述一个或多个实施例，其中：
[0028] 图1是实施例的可能的实施方式的示例；
[0029] 图2是实施例中的主设备的可能的实施方式的示例；
[0030] 图3是实施例中的从设备的可能的实施方式的示例；
[0031] 图4是实施例的可能的操作的示例性示图；
[0033] 图6是管理“诊断”帧的实施例的可能的操作的示例性框图；
[0034] 图7是管理“错误”帧的实施例的可能的操作的示例性框图；
[0035] 图8是实施例中的主设备通信循环的可能的实施方式的示例性框图；以及[0036] 图9是实施例中的从设备通信循环的可能的实施方式的示例性框图。
具体实施方式
[0037] 实施例涉及用于例如汽车应用中使用的总线支持通信。例如，一个或多个实施例可以应用于交通工具灯(例如，前灯、后灯、内部灯)的电子控制单元(ECU)与对应的照明模块(例如，LED灯模块)之间的通信。
[0038] 实施例提供了对以上描述的那些解决方案的进一步改进的解决方案。例如，实施例可以有助于例如实现成本高效的高数据速率交通工具网络，以用于驱动在鲁棒性、故障检测和安全性方面符合汽车要求的分散式LED光源。类似的解决方案还可以有助于实现用于在例如生产自动化系统等中的实施方式的高数据速率网络。
[0039] 一个或多个实施例可以涉及对应的系统。
[0041] 一个或多个实施例可以涉及对应的信号。
[0042] 一个或多个实施例可以涉及对应的交通工具，例如机动交通工具(诸如汽车)。
[0043] 一个或多个实施例可以提供适合于实现用于在例如电子控制单元(ECU)和诸如LED灯模块的照明模块之间的通信的通信网络的硬件解决方案。
[0044] 一个或多个实施例可以实现可以在汽车应用中使用的主从通信总线接口。
[0045] 用于在汽车应用中使用的这种通信总线接口可以依赖于标准化的CAN FD(灵活数据速率)协议，以用于驱动交通工具中的灯模块(“CAN FD灯”)。
[0046] 一个或多个实施例可以依赖于除标准化CAN FD网络之外的网络技术，例如以用于在非汽车应用(诸如例如自动化系统等)中使用。
[0047] 例如，一个或多个实施例可以使用差分总线布线，并且可以提供经定义的边缘密度(例如，一个隐性到显性边缘用于每10比特)以用于同步的目的。
[0048] 出于安全原因，一个或多个实施例可以实现循环冗余校验(CRC)和错误校验。
[0049] 在一个或多个实施例中，数据交换可以依赖于主从方案，其中“卫星”(即，从设备)(仅)在接收到来自主设备的请求时在通信总线上发送数据。这种操作方案可以不涉及冲突(collision)解决特征，只要正常操作可以旨在避免冲突，其中将冲突视为错误。
[0050] 在一个或多个实施例中，通信总线的正常操作可以涉及主设备(规律地)向从设备发送数据。这种(规律的)数据流可以被从设备用作一种网络“心跳”或看门狗(watchdog)。如果在所定义的时隙内未收到规律的数据流，则从设备可以进入故障安全(或跛行回家)模式。
[0051] 在一个或多个实施例中，可以由主设备例如通过使用专用命令帧来寻找诸如来自从设备的诊断数据的数据。某个被寻址的从设备可以在某个时间帧内对这种请求做出反应。可以由主设备使用这种反应来检测从设备的可用性。
[0052] 在随后的描述中，图示了一个或多个具体细节，旨在提供对本说明书的实施例的示例的深入理解。可以在没有一个或多个特定细节的情况下或者利用其他方法、部件、材料等获得实施例。在其他情况下，未详细说明或描述已知结构、材料或操作，使得实施例的某些方面将不被模糊。
[0053] 在本说明书的框架中对“实施例”或“一个实施例”的参考旨在指示：关于该实施例描述的特定配置、结构或特性被包括在至少一个实施例中。因此，可以存在于本说明书的一个或多个点中的诸如“在实施例中”或“在一个实施例中”的短语不一定指代同一个实施例。而且，在一个或多个实施例中，可以以任何适当的方式组合特定构造、结构或特性。
[0054] 在本文中使用的附图标记仅仅是为了方便而提供的，因此不限定保护的范围或实施例的范围。
[0055] 如所指出的，一个或多个实施例可以提供可以在汽车应用中使用的“鲁棒”主从总线接口。
[0056] 一个或多个实施例可以依赖于标准化的CAN FD物理接口和协议，并且利用差分总线布线，同时提供一定的边缘密度以用于同步的目的。
[0057] 为了安全合规性，一个或多个实施例可以实现循环冗余校验(CRC)和错误校验。
[0058] 图1的示图是其中第一设备10和第二设备集201、202...20n(例如，在交通工具V上)经由总线30被耦合的布置的一般示例。例如，总线30可以是差分总线。CAN总线是这种可能的差分总线的示例。
[0059] 在如图1中例示的这种布置中，第一设备10在总线30上传送“第一”消息，“第一”消息携带操作数据消息部分集，并且第二设备集201、202...20n中的第二设备在第一消息中标识寻址到它们的相应的操作数据消息部分，并且通过实施相应的操作来对其做出反应。
[0060] 如图1中所例示的，一个或多个实施例可以应用于本地通信总线网络，例如以用于驱动LED簇(例如，交通工具的灯)。在这种总线网络与标准CAN FD网络兼容的情况下，在本文中将它们被称为“CAN FD灯”网络。
[0061] 将会另外理解，对这种可能的应用的参考仅用于示例性目的，而不应当被解释(甚至间接地被解释)为限制实施例。
[0062] 例如，如图1所例示的通信系统还可以适用于与用于交通工具的前灯和/或内部灯的驱动器一起使用。
[0063] 类似的通信系统可以适用于与任何其他类型的ECU和驱动器(不一定在交通工具内)一起使用，只要它们可以依赖于主从架构。
[0064] 图1是根据实施例的系统的示例，该系统包括主设备10(例如，用于例如交通工具中的后灯中的LED簇的电子控制单元(ECU))。
[0065] 再次强调，对这种可能的应用的参考仅用于示例性目的，而不应当被解释(甚至间接地被解释)为限制实施例。
[0066] 一个或多个实施例可以包括多个“卫星”或从设备201、202...20n(例如，通过通信总线30与主设备通信的(线性)LED驱动电路)。
[0067] 在一个或多个实施例中，主设备10和从设备201、202...20n都可以从电源40(例如，在交通工具内提供的电池)供电。
[0068] 在一个或多个实施例中，主设备10和从设备201、202...20n可以以不同的接地为基准。
[0069] 如图1中所图示的主设备10可以包括以下部件中的一个或多个部件：主(例如，“降压”)转换器101；可选的(例如，再次“降压”)转换器102；低压差(LDO)线性电压调节器、待机、复位和窗口以及看门狗电路块103；电压监控器、电源正常、振荡器和使能电路块104；微控制器106；用于与可能安装在交通工具中的其他ECU通信的收发器电路105(例如，LIN2.2/HS-CAN收发器)；以及到外部通信总线107的接入点，该外部通信总线被连接到用于与包括在交通工具中的其他ECU通信的收发器105。
[0070] 在一个或多个实施例中，可以从主转换器101和/或从可选的转换器102提供微控制器106。微控制器106可以与电路块103和收发器105耦合，并且可以被适配用于与通信总线30通信和/或协作。
[0071] 除以下讨论的方面之外，针对主设备10的这种架构在本领域中是常规的，因此不必在此提供更详细的描述。
[0072] 在一个或多个实施例中，可以使用在微控制器106中嵌入的协议控制器和CAN FD收发器(图1中不可见)来实现设备10的“主”功能。
[0073] 例如，在本文中例示的一个或多个实施例中，主设备10是处理总线通信的微控制器(μC)。这种微控制器可以使用嵌入式CAN FD协议控制器，其可以在没有软件干预的情况下处理CAN FD协议。这可以是比经由SW运行不同的控制器(将占用微控制器核的资源并且可能不合期望地慢)更优选的选择。因此，一个或多个实施例便于重新使用现有的硬件协议控制器，其中由软件控制发送的CAN FD消息及其内容。
[0074] 在一个或多个实施例中，从设备20可以被实现为使用BCD(双极型CMOS-DMOS)技术的LED驱动器。
[0075] 在一个或多个实施例中，通信总线30上的数据交换可以依赖于主从方案，其中从设备201、202...20n可以(仅)在接收到来自主设备10的请求时在通信总线30上发送数据。
[0076] 如所指出的，在一个或多个实施例中，这种操作方案可以不涉及冲突解决特征，只要正常操作可以旨在避免冲突，其中冲突被视为错误。通信总线30的正常操作可以涉及主设备10规律地(即，以所定义的时间间隔)向从设备201、202...20n发送数据，其中这种数据由(所有)从设备201、202...20n接收。这种规律的数据流可以由从设备用作网络“心跳”或看门狗。作为在所定义的时隙内没有接收到规律的数据流的结果，从设备可以进入其故障安全(或跛行回家)模式。
[0077] 在一个或多个实施例中，可以由主设备10通过使用专用命令帧(例如，由主设备10在总线30上发送的“第二”消息)来请求诸如来自从设备201、202...20n的诊断数据的数据。某个(一个)被寻址的从设备20i可以做出反应，例如，在某个时间帧内回答由主设备发出的请求。由从设备20i在总线网络30上发送的这种回答可以由主设备10使用以检测从设备20i的可用性和/或正确操作。
[0078] 将会理解，在本文中讨论的第一消息基本上对应于如常规地在基于消息的协议(诸如，例如CAN总线协议)中传送的广播消息，其中由一个设备在总线上传送的消息被(所有)其他设备(同时)接收，其中这些后面的设备能够根据由这种广播消息传达的操作数据部分来实施相应的操作。尽管由一个(主)设备在总线上进行所谓的“物理”广播，但是第二消息事实上作为请求消息被“逻辑地”寻址到其他(从)设备中的各个设备，从而从设备被请求以通过向主设备(在某个时间间隔内)发送相应的响应(诸如，例如诊断消息)来做出反应，其中只要主设备向从设备分配相应的、非冲突的响应间隔，就能避免这种响应的可能的冲突。
[0079] 还将注意到，在本说明书的框架中，术语“帧”和“消息”都可以用于指示在通信总线30中的参与者之间交换的消息。
[0080] 在一个或多个实施例中，通信协议可以(仅)使用没有比特率切换并且具有标准ID的CAN FD格式的帧。
[0081] 可以可选地包括例如支持扩展ID、经典CAN帧或比特率切换的扩展。可以忽略实施方式不支持的帧，其中用于改变这些操作模式的比特保持其固定值。
[0082] 图2是根据实施例的主设备10的可能的实施方式的示例性框图。
[0083] 贯穿本文所附的附图，相同的部件或元件用相同的附图标记/标号指示，并且为了简洁起见，将不再重复对应的描述。
[0084] 因此，图2示出了主设备10，其可以包括：到通信总线30(例如，CAN总线)的接入点、到第二通信总线107的接入点、用于与通信总线107协作的收发器电路105、用于与通信总线30协作的收发器电路108(例如，CAN FD收发器)和微控制器106，微控制器106又包括：(HW和/或SW)通信协议控制器1062(例如，CAN FD协议控制器)、通信协议扩展(例如，SW)1061(例如，“CAN FD灯”协议扩展)以及可能的其他电路块1063。
[0085] 在一个或多个实施例中，附加的CAN FD协议扩展1061可以控制CAN FD协议控制器1062以用于实现如在本文中所例示的CAN FD灯协议的主设备侧。
[0086] 在一个或多个实施例中，可以通过使用另外的常规的CAN FD收发器108来提供到总线30的物理接口的接入。
[0087] 图3是根据实施例的从设备20i的可能的实施方式的示例性框图。
[0088] 如图3中所例示的，从设备20i可以包括：通信和协议控制器电路201(例如，“CAN FD灯”通信和协议控制器)、存储器区域202、用于与通信总线30协作的收发器203(例如，CAN FD收发器)以及可能的其他ECU电路块204。
[0089] 除以下讨论的方面之外，针对从设备20i的这种架构在本领域中是常规的，因此使得不必在本文中提供更详细的描述。
[0090] 例如，在一个或多个实施例中，通信和协议控制器电路201的实施方式可以借助于专用硬件来减少用于运行软件的嵌入式处理器的必要性。
[0091] 在一个或多个实施例中，通信和协议控制器电路201可以包括精确的振荡器(图3中不可见)以用于生成和采样数据比特。
[0092] 图4是通信和协议控制器电路201(例如，CAN FD灯通信和协议控制器电路)的可能操作的示例性示图。
[0093] 如图4中所例示的通信和协议控制器201包括通信控制器2010、协议控制器2011和振荡器2016(可选地，电压、工艺和温度补偿型和/或对应地调整的振荡器)，协议控制器2011又包括发射器电路2012、传送错误计数器(TEC)电路2013、接收器电路2014和接收错误计数器(REC)电路2015。
[0094] 在一个或多个实施例中，发射器电路2012和/或接收器电路2014可以被配置成与收发器203(例如，CAN FD收发器)协作以用于在总线30上进行通信。
[0095] 在一个或多个实施例中，发射器电路2012可以被配置成执行帧准备(2012a)、比特填充(2012b)、CRC插入(2012c)、帧错误校验(2012d)、错误计数(2012e)和应答(acknowledge)(2012f)。
[0096] 在一个或多个实施例中，接收器电路2014可以被配置成执行比特解码(采样-2014a)、错误检测(2014b)、比特去填充(2014c)、CRC验证(2014d)和应答生成(2014e)。
[0097] 在一个或多个实施例中，通信控制器2010可以向协议控制器2011发送数据和从协议控制器2011接收数据以控制通信。
[0098] 在一个或多个实施例中，将主从架构应用于基于CAN FD的通信总线30可以提供以下可能性：利用CAN FD协议的优点(例如，高数据速率、鲁棒的差分信令、用于安全目的的CRC)，同时克服其缺点(例如，要求多边通信的精确的时钟时序(例如，用于仲裁、错误信令、每个ECU的帧校验)、高复杂性以及由于缺少中央通信主设备而导致缺少有保证的通信时隙)。
[0099] 在本文例示的一个或多个实施例中，可以采用高带宽(例如，500kb/s，优选1Mb/s)，并且通信可以涉及针对ASIL B(汽车安全完整性等级B)安全要求的校验。例如，可以通过与每个数据帧一起发送的CRC值来促进满足这种安全要求。
[0100] 在本文例示的一个或多个实施例中，作为接收数据帧(例如，由主设备10在总线上30发送的“第一”消息)的结果，接收者(从设备201、202...20n)发送“应答”比特，以便如果系统正确操作，则发送器(主设备10)接收至少一个应答比特。
[0101] 因此，作为从从设备201、202...20n接收至少一个应答比特的结果，主设备10可以检测它是否仍然被耦合到总线网络30。由于总线网络30的参与者被连接到相同的导线，则发射器可以能够检测它是否未正确操作，并且因此可以进入“被动”状态以不扰乱总线通信。
[0102] 在一个或多个实施例中，总线网络30的处于被动(例如，隐性)状态的参与者可能能够感测总线差分电压的值，但是可能无法驱动总线，即它可能无法将总线差分电压强制为某个值。
[0103] 在一个或多个实施例中，可以在接收器电路中单独地生成数据采样时钟。因此，数据流的最小边缘密度将是有益的，例如，至少每个例如第10比特具有隐性到显性边缘，从而有助于接收器电路与数据流的同步。
[0104] 在一个或多个实施例中，差分总线网络以低成本促进“鲁棒”数据传送。在一个或多个实施例中，还可以实现在网络上的唤醒，并且可以使用根据ISO 11898-2:2015标准的唤醒模式(WUP，例如，使用滤波时间Tfilter(短))唤醒从设备201、202...20n。
[0105] 因此，一个或多个实施例可以利用常规的CAN FD协议(例如，在1Mb/s)，而没有出于兼容性原因的比特率切换。因此，可以通过(在另外的常规的CAN FD协议控制器中)(仅)实现常规的CAN FD协议的特征的子集(例如，不实现比特率切换特征)来寻求兼容性。
[0107] 例如，在如本文所例示的一个或多个实施例中：
[0108] (仅)可以使用CAN FD基本帧格式(FBFF)，而不必求助于扩展ID，例如，以便增加每个帧的数据有效载荷(例如，每帧多至64字节)；
[0109] (仅)可以支持一种帧格式(FBFF)，其中控制字段中的比特固定，并且不要求支持扩展ID(EID，IDE比特始终显性)、比特率切换(BRS，始终显性)和错误状态指示(ESI，始终显性)：例如，可以将FD帧(FDF)(稳定地)设置为隐性。
[0110] 在一个或多个实施例中，支持(仅)一种帧格式(例如，CAN FD基本帧格式)可以导致更简单的实施方式并且可以有助于降低成本。
[0111] CAN FD基本帧格式中的数据字段可以长达64字节。根据数据字节的数目，可以计算CRC17或CRC21。在一个或多个实施例中，(仅)可以发送和接受一个CRC定界符比特。
[0112] 在一个或多个实施例中，网络参与者20可以包括接收错误计数器(REC)2015和传送错误计数器(TEC)2013。
[0113] 在一个或多个实施例中，作为网络参与者201、202...20n中的网络参与者20i中的接收错误计数器2015达到某个阈值的结果，网络参与者20i与通信总线30的耦合可以被假设为丢失。
[0114] 在一个或多个实施例中，作为网络参与者201、202...20n中的网络参与者20i中的传送错误计数器达到某个阈值的结果，节点20i可以停止发送数据并且进入被动状态(隐性状态)以避免扰乱总线。
[0115] 在一个或多个实施例中，可以通过来自主设备10的命令来复位网络参与者201、202...20n中的任何网络参与者的传送错误计数器，该命令可以作为在一段时间内没有接收到来自节点20i的数据的结果而被发送到某个参与者20i。在某个从设备20i中接收复位命令可以解锁可能由于例如一些异常情况(例如，失真)而进入被动状态的该从设备。
[0116] 一个或多个实施例可以采用REC/TEC，只要这些(已经)在CAN总线“业界(de facto)”标准中被提供。
[0117] 一个或多个实施例的安全概念可以被建立在涉及在给定时间帧内发送消息并且正确地接收这些消息的主从协议结构和操作上。
[0118] 一个或多个实施例可以考虑如下所讨论的情况：
[0119] a.超过TEC阈值
[0120] i.主设备中的TEC：主设备知道不再与从设备耦合->发出警告消息(例如，发送给驾驶员：灯、仪表板消息等)
[0121] ii.从设备中的TEC：某个从设备知道它无法向主设备发送诊断消息->进入故障安全状态(“跛行回家”)，例如，LED后灯开启
[0122] b.超过REC阈值
[0124] ii.从设备中的REC：网络“失真”->从设备将停止通信(从而将避免总线阻塞其他从设备通信的潜在风险)并且进入故障安全状态
[0125] c.主设备发送“第一”消息
[0126] i.主设备没有收到应答->主设备中的TEC增加，具有上面讨论的相同反应[0127] ii.从设备在给定的时间帧内没有收到“第一”消息->网络失真(与从设备中的REC故障相同，具有上面讨论的相同的反应)
[0128] d.主设备发送“第二”消息
[0129] i.主设备没有收到应答(ACK)->上面讨论的相同反应
[0130] ii.主设备没有收到来自被寻址的从设备的回答->网络失真(至少在相关的从设备处，具有上面讨论的相同反应)
[0131] iii.从设备没有收到“第二”消息->没有动作；通过“第一”消息验证通信，具有与上面在该方面所讨论的相同的反应
[0132] e.从设备通过发送诊断帧来回答“第二”消息
[0133] i.主设备在某个时间帧内没有收到诊断帧或接收到失真的回答->网络失真(至少在相关的从设备处，具有与上面针对主设备中的REC故障所讨论的相同的反应)[0134] ii.从设备没有收到应答：网络失真->与上面针对从设备中的TEC故障所讨论的相同的反应；在从设备可能缺少TEC的情况下(也常见下文)，不提供任何反应，并且通过接收来自主设备的“第一”消息来验证通信。
[0135] 如所指出的，一个或多个实施例可以考虑“丢弃”用于从设备的REC/TEC概念，而将其(仅)保留在主设备中(例如，作为原始CAN(FD)协议的一部分)，以便(只有)主设备将评估其TEC/REC。
[0136] 在一个或多个实施例中，在故障安全/跛行回家的情况下，从设备(例如，汽车中的后灯的LED驱动器)将进入安全状态，例如，其中后灯(至少部分地)开启，这样汽车在黑暗中仍然可以被其他驾驶员看到，同时停止可能增加功耗的其他辅助功能，以便避免例如过热或其他故障。
[0137] 当然，故障安全/跛行回家情况的类型和性质可以根据所涉及的从设备的类型而变化：例如，可以简单地关闭内部灯以避免在夜间驾驶期间驾驶员的烦恼。
[0138] 在一个或多个实施例中，如果主设备通过总线107与主控制器(底盘/主体控制器、较高层级的控制器)的网络连接失败，则主设备还可以进入故障安全状态。作为主设备进入故障安全状态的结果，主设备可以向与其耦合的从设备发送命令以进入相应的故障安全状态。而且，主设备可以通过警报消息对网络失真做出反应，例如经由警告灯和/或仪表板消息通知驾驶员。
[0139] 在一个或多个实施例中，作为接收器正确接收数据帧的结果，任何发送器可以从至少一个接收器接收应答(“ACK”)比特。因此，发送器可以标识它是否仍然被耦合到网络的至少一部分。例如，作为发送器没有收到ACK比特的结果，发送器的传送错误计数器增加。
[0140] 例如，在如本文例示的一个或多个实施例中，主设备10将在规律的时间段内发出可以用作“看门狗触发”和/或网络“心跳”的消息。因此，接收从设备201、202...20n可以识别主设备10是否正在通信。主设备10可以周期性地从每个连接的从设备20请求状态信息。在从设备201、202...20n中的从设备20i没有回答由主设备10发出的状态信息请求的情况下，可以检测到从设备20i的“不存在”(例如，故障)。
[0141] 例如，在本文中例示的一个或多个实施例中，任何发送器可以被配置成将其在通信总线30上发送的比特与在总线30上所接收的比特进行比较。作为发现所发送的比特和所接收的比特不相等的结果，可以假设存在错误，并且因此发送器的传送错误计数器增加。作为对应的TEC达到某个阈值的结果，发送器节点可以停止传送数据，导致发送器进入被动状态。
[0142] 例如，在本文例示的一个或多个实施例中，可以例如通过校验以下特征中的一个或多个特征来验证所接收的帧的正确性：
[0143] 所接收的CRC的正确性，
[0144] 在CRC字段之后接收到一个隐性比特作为CRC定界符，
[0145] 所接收的帧的比特填充的正确性。
[0146] 在一个或多个实施例中，作为所接收的CRC未能匹配所接收的帧的结果，可以丢弃所接收的帧并且可以增加接收器的REC。
[0147] 在一个或多个实施例中，作为所接收的帧的比特填充不正确的结果，可以丢弃所接收的帧并且可以增加接收器的REC。
[0148] 在一个或多个实施例中，可以例如通过校验以下特征中的一个或多个特征来验证所传送的帧的正确性：
[0149] 所发送的比特与所接收的比特之间的相等性，因为所发送的比特还由收发器电路接收；
[0150] 通过从至少一个接收器发出ACK比特，由至少一个接收器电路应答所传送的帧。
[0151] 在一个或多个实施例中，作为发现所发送的比特并且所接收的比特不相同的结果，所传送的帧可以被认为是无效的，中止传输并且增加发射器的TEC。
[0152] 在一个或多个实施例中，作为发射器电路未能从接收器接收任何ACK比特的结果，所传送的帧可以被视为未被任何的接收器接收，可以增加发射器的TEC并且可以不重新发送所传送的帧。
[0153] 在一个或多个实施例中，从设备201、202...20n的振荡器2016可以具有其振荡频率的最大允许偏差，例如预期值的±2％。因此，在一个或多个实施例中，两个从设备之间的最大频率偏移可以达到例如高达振荡频率的±4％的最大值。
[0154] 在一个或多个实施例中，由一个从设备发送的帧可以不旨在由在相同的通信总线30上的另一个从设备解码。作为从设备接收由另一个从设备发送的帧的结果，第一从设备的接收错误计数器可以增加。从设备不传送错误帧，因此通信不会失真。
[0155] 因此，在一个或多个实施例中，作为接收到无差错帧的结果，接收器的REC可以根据这种所接收的帧的长度而减小，如下面在表1中所例示的。
[0156] 在一个或多个实施例中，例如，根据与经典的CAN扩展帧格式(CEFF)一起工作的CAN局部网络(CAN PN)，对于上至8的数据长度码(DLC)，接收器的REC可以减少一个单位。在更长的帧的情况下，可以根据经典CAN帧数据有效载荷的数量来减小REC。在一个或多个实施例中，可以在通信控制器2010中考虑这种行为，因为源自从设备的许多帧可能未被通信总线30中的其他从设备识别。在最坏的情况下，源自从设备的(所有的)帧可能未被通信总线30中的其他从设备识别。而且，由于填充错误、CRC错误和CRC定界符错误可以相加，因此对于每个所接收的帧，接收器的REC可以增加多于一个单位。
[0157] 在一个或多个实施例中，主设备将针对每个从设备响应比从设备多发送8字节的数据分组。实际上，在一个或多个实施例中，从设备响应可以比由主设备发送的帧短(例如，携带较少数目的数据字节)。
[0158] 为了“补偿”由一个从设备在总线上30发送的从设备响应导致被耦合到总线30的其他从设备增加它们的REC，由主设备发送的长帧被从设备正确接收可以使得从设备的REC根据由主设备发送的帧的长度来减小，如表1中所例示的。
[0159] 表1-DLC和REC更新
[0160]
[0161]
[0162] 图5是描述在一个或多个实施例中实现的“广播”帧协议的可能的逻辑流程的示例性框图，例如，以用于主设备发送“第一”消息和从设备接收这种消息。
[0163] 在图5中，位于粗垂直线左侧的逻辑框指示在主设备10中实施的操作，并且位于粗垂直线右侧的逻辑框指示在从设备201、202...20n中的任何从设备20i中实施的操作。
[0164] 图5中的逻辑框的含义如下：
[0165] 300：发送具有广播ID的“第一”消息，
[0166] 301：接收“第一”消息，
[0167] 302：检测所接收的“第一”消息中的错误(Y＝检测到错误，N＝未检测到错误)，[0168] 303：在框302的结果为肯定(Y)时，增加从设备的REC，
[0169] 304：结束传输，
[0170] 305：在框302的结果为否定(N)时，发送ACK比特，
[0171] 306：减少从设备的REC，
[0172] 307：以状态“接收成功”结束，
[0173] 308：接收ACK比特，
[0174] 309：检测所接收的ACK比特中的错误(Y＝检测到错误，N＝未检测到错误)，[0175] 310：在框309的结果为否定(N)时，以状态“传输成功”结束，
[0176] 311：在框309的结果为肯定(Y)时，可选地增加主设备的TEC，并且发送错误帧，[0177] 312：结束传输，
[0178] 313：接收错误帧，
[0179] 314：增加从设备的REC，
[0180] 315：结束传输。
[0181] 为了便于理解，下面还简要讨论了图5的框图描述的操作。
[0182] 如图5中所例示的，在一个或多个实施例中，可以将“第一”消息从主设备10传送到从设备201、202...20n以设置操作值，例如设置致动器值。
[0183] 在一个实施例中，“第一”消息可以包含针对被连接到通信总线30的所有从设备201、202...20n的设置值。
[0184] 在另一实施例中，“第一”消息可以包含针对连接到通信总线30的所有从设备201、202...20n中的从设备的子集(例如，甚至针对从设备201、202...20n中的单个从设备)的设置值。
[0185] 在一个或多个实施例中，主设备10在发送“第一”消息之后可以不期望来自从设备201、202...20n回答，但是它可以例如在CAN应答时隙中期望来自至少一个从设备的至少一个应答比特。
[0186] 在本文例示的一个或多个实施例中，作为(例如，在CAN应答时隙中)主设备10未能接收到来自至少一个从设备的任何应答比特的结果，主设备10将增加其传送错误计数器的值。在一个或多个实施例中，主设备10还可以在通信总线30上发送错误帧。
[0187] 在本文例示的一个或多个实施例中，从设备201、202...20n可以校验所接收的“第一”消息的完整性，并且如果所接收的“第一”消息无差错则发送应答比特，在这种情况下，“第一”消息被认为是有效的。在一个或多个实施例中，接收到附加的错误帧将导致接收错误计数器增加而没有任何附加的反应。
[0188] 在一个或多个实施例中，从设备201、202...20n可以从“第一”消息中挑选对它们有效的数据。在一个或多个实施例中，“第一”消息可以携带广播ID，例如，在CAN消息的标准ID字段中。
[0189] 图6是描述在一个或多个实施例中实现的诊断帧协议的可能逻辑流程的示例性框图，例如，以用于主设备发送“第二”消息和从设备接收这种消息并对其做出反应。
[0190] 如图5中一样，位于图6中的粗垂直线左侧的逻辑框指示在主设备10中实施的操作，并且位于粗垂直线右侧的逻辑框指示在从设备201、202...20n中的任何从设备20i中实施的操作。
[0191] 图6中的逻辑框的含义如下：
[0192] 400：发送具有(目标)从设备ID的“第二”消息，
[0193] 401：接收“第二”消息，
[0194] 402：检测所接收的“第二”消息中的错误(Y＝检测到错误，N＝未检测到错误)，[0195] 403：在框402的结果为肯定(Y)时，增加从设备的REC，
[0196] 404：结束传输，
[0197] 405：在框402的结果为否定(N)时，发送ACK比特，
[0198] 406：减小从设备的REC，
[0199] 407：等待10比特总线空闲，
[0200] 408：检测错误(Y＝检测到错误，N＝未检测到错误)，
[0201] 409：发送具有从设备ID的反应消息，
[0202] 410：接收ACK比特，
[0203] 411：检测所接收的ACK比特中的错误(Y＝检测到错误，N＝未检测到错误)，[0204] 412：在框411的结果为肯定(Y)时，增加主设备的TEC并且发送错误帧，[0205] 413：接收错误帧，
[0206] 414：增加从设备的REC，
[0207] 415：结束传输，
[0208] 416：等待TREC，
[0209] 417：校验是否达到TREC超时(Y＝达到TREC超时，N＝未达到TREC超时)，[0210] 418：在框417的结果为肯定(Y)时，触发看门狗故障，
[0211] 419：在框417的结果为否定(N)时，接收反应消息，
[0212] 420：检测所接收的反应消息中的错误(Y＝检测到错误，N＝未检测到错误)，[0213] 421：在框420的结果为肯定(Y)时，增加主设备的REC并且发送错误帧，[0214] 422：接收错误帧，
[0215] 423：增加从设备的TEC和REC，
[0216] 424：结束传输，
[0217] 425：在框420的结果为否定(N)时，发送ACK比特，
[0218] 426：减小主设备的REC，
[0219] 427：以状态“接收成功”结束，
[0220] 428：接收ACK比特，
[0221] 429：检测所接收的ACK比特中的错误(Y＝检测到错误，N＝未检测到错误)，[0222] 430：在框429的结果为肯定(Y)时，增加从设备的TEC，
[0223] 431：结束传输，
[0224] 432：在框429的结果为否定(N)时，减小从设备的TEC，
[0225] 433：以状态“传输成功”结束。
[0226] 为了便于理解，下面还简要讨论了由图6的框图描述的操作。
[0227] 如图6中所例示的，在一个或多个实施例中，主设备10可以发送“第二”消息，以通过将从设备20i的标识从设备ID包括到(例如，在CAN消息的标准ID字段中的)消息ID中，来请求来自被连接到通信总线30的从设备201、202...20n中的某个从设备20i的诊断数据。主设备10可以在特定时间窗口TREC内等待来自所寻址的从设备的回答(例如，反应消息)。作为主设备10在该时间窗口TREC内未接收到回答的结果，可以触发看门狗错误。
[0228] 在一个或多个实施例中，作为正确接收由主设备10在总线上30发送的“第二”消息的结果，从设备20i在ACK时隙中回复ACK比特并且在等待某个时间间隔(例如，至少10比特总线空闲)之后发送其反应消息。
[0229] 在一个或多个实施例中，从设备201、202...20n中的其他从设备可能不正确地接收了反应消息(例如，由于相对于主设备10的频率的相应的振荡器的频率偏移)。作为不正确地接收这种反应消息的结果，可以增加接收的从设备201、202...20n的REC。
[0230] 在本文例示的一个或多个实施例中，未被由主设备10发出的“第二”消息寻址的从设备将不回答并且忽略由所寻址的从设备发送的反应消息。
[0231] 在本文例示的一个或多个实施例中，(仅)将在存在来自主设备10的请求时由从设备201、202...20n传送帧。因此，在发生错误的情况下，从设备201、202...20n将不重新传送任何帧。
[0232] 在本文例示的一个或多个实施例中，“第二”消息可以由所寻址的从设备的ID标记。可选地，可以通过使用标准ID字段中的未使用的ID比特来将“第二”消息标记为广播帧(例如，标准ID字段的低10比特可以表示被寻址的从设备，而第11比特可以将该帧标记为广播帧)。
[0233] 图7是描述在一个或多个实施例中实现的错误和过载帧协议的可能逻辑流的示例性框图。
[0234] 与在图5和图6中所示的一样，位于图7中的粗垂直线左侧的逻辑框指示在主设备10中实施的操作，并且位于粗垂直线右侧的逻辑框指示在从设备201、202...20n中的任何从设备20i中实施的操作。
[0235] 图7中的逻辑框的含义如下：
[0236] 500：检测错误(Y＝检测到错误，N＝未检测到错误)，
[0237] 501：在框500的结果为否定(N)时，以状态“传输成功”结束，
[0238] 502：在框500的结果为肯定(Y)时，增加主设备的TEC并且发送错误帧，[0239] 503：结束传输，
[0240] 504：接收错误帧，
[0241] 505：增加从设备的REC，
[0242] 506：结束传输。
[0243] 为了便于理解，下面还简要讨论了由图7的框图描述的操作。
[0244] 在一个或多个实施例中，错误帧(仅)由主设备10发送，而不由从设备201、202...20n发送。接收错误帧可以导致从设备的REC增加一。在过载帧(其被视为错误帧)的情况下可以应用相同的行为。
[0245] 在一个或多个实施例中，总线参与者(从设备201、202...20n)可以不仲裁总线30上的通信，因为通信可以(仅)由主设备10发起和/或控制。
[0246] 在本文例示的一个或多个实施例中，总线30上的任何冲突将导致相关联的错误计数器的增加。主设备10可以将冲突检测为错误并且增加其传送错误计数器，而不必重新发送帧。从设备201、202...20n中的从设备可以检测总线30上的错误比特(例如，显性比特而不是预期的隐性比特)并且增加其传送错误计数器。
[0247] 人们可能会注意到，错误消息本身就是错误，也就是说它们可能不符合CAN协议要求。它们可以简单地是一行中的(例如，六个)显性比特的集合。因此，可以将它们视为错误并将其丢弃，而从设备侧不对这些做出反应。
[0248] 一个或多个实施例下面的概念是：只要“第一”消息和“第二”消息是由主设备发送的(仅有的)消息，则(仅)在正确接收“第一”消息和/或“第二”消息时复位看门狗定时器。
[0249] 图8是指示在一个或多个实施例中主设备单元10的通信循环的可能的实施方式的框图。
[0250] 图8中的逻辑框的含义如下：
[0251] 600：开始通信，
[0252] 601：判断是否应当向从设备20i发出诊断数据请求(Y＝向从设备20i的发出诊断数据请求，N＝不向从设备20i发出诊断数据请求)，
[0253] 602：在框601的结果为肯定(Y)时，向从设备20i发送“第二”消息，[0254] 603：复位从设备20i的看门狗定时器，
[0255] 604：校验是否接收到来自从设备20i的具有诊断数据的反应消息(Y＝接收到诊断数据，N＝未接收到诊断数据)，
[0256] 605：校验从设备20i的看门狗定时器是否到期(Y＝看门狗到期，N＝看门狗未到期)，
[0257] 606：在框605的结果为肯定(Y)时，感测针对从设备20i的看门狗超时，[0258] 607：在框601的结果为否定(N)时，发送“第一消息”，
[0259] 608：可选地等待达Twait。
[0260] 在一个或多个实施例中，主设备10可以(例如，循环地)向从设备201、202...20n发送“第一”消息，例如，以用于致动器设置，从设备201、202...20n可以使用这种循环作为看门狗触发器。作为在看门狗时间内“第一”消息未由从设备20i接收到的结果，可以感测到看门狗超时。作为感测到看门狗超时的结果，从设备20i可以进入故障安全状态。
[0261] 在一个或多个实施例中，主设备10可以从某个被寻址的从设备20i请求诊断数据。作为被寻址的从设备20i在一定量的时间内没有回答的结果，可以触发看门狗超时，因此主设备可以对与从设备20i的通信的丢失做出反应。
[0262] 在本文例示的一个或多个实施例中，可以以至少两种不同的方式将数据发送到从设备201、202...20n。
[0263] 在第一情况下，主设备10可以将“第一”消息发送给所有从设备201、202...20n。在这种情况下，主设备10可以不期望来自从设备201、202...20n的回答。
[0264] 在第二情况下，主设备10可以将“第二”消息发送到特定的从设备20i。从设备201、202...20n可以将“第二”消息视为广播帧，例如以用于致动器设置。因此，(仅)被寻址的从设备可以通过在反应消息中发送回其诊断数据来对“第二”消息做出反应。这种诊断数据将被总线30上的其他从设备忽略。由于从设备之间的频率偏移，由从设备中的一个从设备发送的反应消息可以被其他从设备视为错误帧，并且可以导致增加它们相应的REC。
[0265] 在一个或多个实施例中，“第二”消息还可以是可以被其他从设备忽略的专用帧。
[0267] 在一个或多个实施例中，标准ID字段中可用的剩余的比特可以用于区分向从设备发送数据的诊断请求以及仅针对所寻址的从设备的特定请求。
[0268] 图9是指示在一个或多个实施例中从设备单元201、202...20n的通信循环的可能的实施方式的框图。
[0269] 图9中的逻辑框的含义如下：
[0270] 700：开始通信，
[0271] 701：复位看门狗定时器，
[0272] 702：检测是否接收到有效消息(Y＝接收到有效消息，N＝未接收到有效消息)，[0273] 703：在框702的结果为肯定(Y)时，确定所接收的有效消息是“第一”消息还是“第二”消息(Y＝接收到“第一”消息，N＝接收到“第二”消息)，
[0274] 704：在框703的结果为否定(N)时，发送具有诊断数据的反应消息，
[0275] 705：在框702的结果为否定(N)时，校验看门狗是否已经到期(Y＝看门狗到期，N＝看门狗未到期)，
[0276] 706：在框705的结果为肯定(Y)时，发出看门狗故障。
[0277] 在一个或多个实施例中，主设备10(例如，循环地)向从设备201、202...20n发送数据。从设备可以使用这种数据以复位相应的看门狗。如果在看门狗到期之前，从设备没有接收到用于复位相应的看门狗的帧，则可以设置看门狗故障。从设备可以使用这种看门狗故障来进入故障安全状态。
[0278] 在一个或多个实施例中，作为从设备20i接收到被寻址到该从设备20i的“第二”消息的结果，接收的从设备20i将通过发送包含所请求的诊断数据的反应消息来回答。
[0279] 在一个或多个实施例中，主设备10可以在单个数据帧中发送例如64字节(即，512比特，一个字节等于8比特)的数据。总线参与者(例如，从设备201、202...20n)将接收从主设备10发送的这种数据。因此，从设备可以从从主设备10接收的512比特的数据的任何集合中“挑选”它所需的信息。这种帧被称为“第一”消息。
[0280] 从设备可以在某个“第一”消息中读取的比特的数目可以根据通信总线的具体实施例而变化。可以在初始化序列期间确定某个从设备的数据的位置。
[0281] 例如，每个从设备可以在“第一”消息中读取8比特的数据。如果由主设备10在某个“第一”消息中发送的数据总量等于例如64字节(即，512比特)，则每个“第一”消息可以为多达64个从设备提供数据。当限定了由主设备10在“第一”消息中发送的数据量以及由从设备在“第一”消息中读取的数据量时，就可以相应地限定可以由“第一”消息寻址的从设备的最大数目。
[0282] 在一个或多个实施例中，可以通过提供从设备的“链”来增加可能的总线参与者的数目(即，从设备的数目)。在该情况下，第一“第一”消息可以寻址第一链从设备(包括例如64个从设备)，第二“第一”消息可以寻址第二链从设备，等。从设备链可以由消息ID字段(例如CAN FD ID字段)中的专用ID寻址。
[0283] 在一个或多个实施例中，可以通过使用从设备的从设备地址来单独寻址该从设备，并且所寻址的从设备将对该诊断请求帧做出反应。
[0284] 在一个或多个实施例中，将协议(诸如例如，由ST集团的公司开发的例如ST SPI(串行外围接口)4.1协议)嵌入到由主设备10发送的“第二”消息的数据中，并且由从设备201、202...20n发送的反应消息将有助于读取某些数据或者将某些数据写入某些地址。
[0285] 在一个或多个实施例中，根据被嵌入到来自主设备的“第二”消息的数据中的ST SPI协议的SPI命令可以包括存储器地址和针对请求(读/写)的数据字节的数目。从设备可以根据ST SPI协议用特定字节来响应，而不是用所请求的存储器地址的地址和数据字节来响应。这种特定字节被称为“全局状态字节”(GSB)，并且包含重要的状态字节，这种状态字节指示例如发生错误、发生复位等。因此，可以用每个诊断响应发送回全局状态寄存器。
[0286] 在一个或多个实施例中，“第一”消息由主设备10传送到总线网络30中的(所有)从设备201、202...20n。“第一”消息的ID字段可以包含由“第一”消息寻址的链的标识号。属于被寻址的链的从设备可以从由该帧传递的数据(例如，最多64字节的数据)中挑选它们的数据。由从设备读取的数据比特的数目将在功能的实施方式中进行限定(例如，是所谓的“硬编码”值)。可以在链初始化期间确定在“第一”消息的整个数据字段中指向被寻址的链的某个从设备的数据的位置。
[0287] 在一个或多个实施例中，“第一”消息可以使用例如以“1”开始并且跟随有三个“1”和所寻址的链标识号(例如，7比特号)的11比特帧ID。例如，使用在例如5比特中编码的链标识号允许标识和指定多达64个从设备链，其中每个链包括例如多达63个从设备。
[0288] 在一个或多个实施例中，可以将特定的“第一”消息(本文中被称为“初始化帧”)发送到通信总线30中的从设备201、202...20n，以将它们的“成员”设置在某个链中并设置其在链中的相对位置。作为接收初始化帧的结果，从设备将被置于从在通信总线30上接收的广播帧中读取旨在用于它们的数据的状况。例如，从设备在某个“第一”消息中读取的比特的数目对于所有从设备可以是相同的，并且在总线的实施方式处进行限定(例如，硬编码值)。
[0289] 在一个或多个实施例中，针对链初始化帧的ID可以是例如“1_0110_0000_00”。
[0290] 在一个或多个实施例中，从设备可以从初始化帧读取例如三字节的数据，例如第一字节指示它所属于的链，第二字节指示其在链内的位置，第三字节指示被寻址的从设备。因此，可以使用单个初始化帧来初始化有限数目的从设备，这取决于初始化帧的数据字段的字节中的维度以及从设备被正确地初始化所需的数据量。例如，如果初始化帧的数据字段是例如64字节长并且从设备需要例如3字节的数据以用于正确地初始化，则可以在一个CAN FD帧中初始化多达21个从设备。
[0291] 在一个或多个实施例中，唤醒模式(WUP)可以被实现成特定的“第一”消息。唤醒模式的ID可以被选择为满足ISO11898-2的唤醒模式要求，例如在1Mb/s使用TFilter(短)。在通信总线以较低比特率操作的情况下，可以使用TFilter(长)。
[0292] 在一个或多个实施例中，保留的WUP ID可以是“1_000_111_0000”。可以在唤醒帧的可选数据字节中重复或增强WUP。
[0293] 在一个或多个实施例中，主设备10可以通过发送“第二”消息(可以被选择为CAN FD帧)来请求来自特定从设备20i的数据。“第二”消息的CAN FD ID可以包含从设备ID(例如，9比特从设备ID)，以及将这种帧标识为“第二”消息的比特和将这种帧标识为单播帧的比特。
[0294] 在一个或多个实施例中，如果标识了所谓的“单播”帧(即，仅被寻址到某个从设备的帧)，则在总线30中使用的CAN FD ID的最高有效位(MSB)可以等于“0”，并且如果标识了所谓的“广播”帧(即，被寻址到所有从设备的帧)，则其等于“1”，“广播”帧还包括链初始化帧和唤醒帧。应当理解，分别参考值“1”和“0”仅仅作为示例：一个或多个实施例实际上可以采用互补选择(例如，分别为值“0”和“1”)。
[0295] 在一个或多个实施例中，作为单播帧不包含任何数据的结果，被寻址的从设备可以传送默认诊断数据，如在实施方式中所定义的。否则，在单播帧包含数据的情况下，这种数据将是根据ST SPI4.1协议的SPI命令。
[0296] 在一个或多个实施例中，接收包含如上定义的SPI命令的单播帧的从设备将回复由ST SPI 4.1协议编码的“第二”消息所请求的数据。
[0297] 在一个或多个实施例中，主设备10可以通过在CAN FD ID字段中发送包含从设备ID的帧来寻址从设备20i。可选的数据字节可以包含ST SPI SDI(ST串行外围接口串行数据输入)帧。
[0298] 在一个或多个实施例中，从设备20i可以通过在通信总线30上发送反应消息(例如，诊断响应帧)来回答所接收的“第二”消息。可以将反应消息选择为CAN FD帧。反应消息的CAN FD ID可以包含从设备ID(例如，9比特的从设备ID)，以及将这种帧标识为反应消息的比特和将该帧标识为单播帧的比特。
[0299] 在一个或多个实施例中，反应消息的数据字节可以包含ST SPI SDO(如由ST集团的公司开发的串行外围接口串行数据输出)帧。在由从设备接收的“第二”消息不包含在帧数据字段中的数据的情况下，从设备可以用CAN FD帧(其数据字节可以仅包含全局状态字节(GSB))对所接收的“第二”消息进行回答。
[0300] 在一个或多个实施例中，可以在设备数据表中使用和指定不同的默认回复。
[0301] 在下面的表2中示例性地示出了实施例中的帧ID(例如，CAN FD标准帧ID)的可能用途。
[0302] 表2-帧ID概述
[0303]
[0304]
[0305] 在一个或多个实施例中，协议控制器可以实现如之前所描述的CAN FD协议。
[0307] 如已经指出的，贯穿本说明书讨论的“第一”消息基本上对应于如常规地在基于消息的协议(诸如，例如CAN总线协议)中传送的广播消息，其中由一个设备在总线上传送的消息被(所有)其他设备(同时)接收，其中这些后者设备能够根据由这种广播消息传达的操作数据部分来实施相应的操作。类似地，尽管由一个(主)设备在总线上进行所谓的“物理”广播，但是贯穿本说明书讨论的第二个消息实际上作为请求消息被“逻辑地”寻址到其他(从)设备中的个体(从)设备，从而从设备被请求以通过向主设备(在某个时间间隔内)发送相应的响应(诸如，例如诊断消息)来做出反应，只要主设备向从设备分配相应的、非冲突的响应间隔，就能避免这种响应的可能的冲突。
[0308] 因此，第一消息可以被视为真正的“广播”消息；相反，当通过一个(主)设备在总线30上进行物理广播时，第二消息可以实际上被视为“单播”消息，只要它们在逻辑上被寻址到从设备中的个体从设备。
[0309] 在一个或多个实施例中，一种方法可以包括：
[0310] 经由总线(例如，30)耦合第一设备(例如，10)和第二设备集(例如，201、202...20n)，
[0311] 将第一设备配置成主设备以在总线上传送：
[0312] a)第一消息，其携带操作数据消息部分集，该操作数据消息部分集指示用于由第二设备集中的第二设备实施的操作，和
[0313] b)第二消息，其被寻址到第二设备集中的第二设备，第二消息传达标识第二消息被寻址所至的第二设备中的相应的第二设备的标识符，请求在相应的预期反应间隔内对第一设备做出相应的反应，以及
[0314] 将第二设备配置成从设备：
[0315] c)以在总线上接收从被配置成主设备的第一设备所传送的第一消息，读取操作数据消息部分集中的相应的操作数据消息部分，并且根据所读取的相应的操作数据消息部分来实施相应的操作，
[0316] d)以在总线上接收从被配置成主设备的第一设备传送的第二消息，并且通过在总线上将反应消息传送到被配置成主设备的第一设备，而在相应的预期反应间隔内对其做出反应。
[0317] 在一个或多个实施例中，被配置成主设备的第一设备可以在总线上传送初始化消息，该初始化消息包括初始化数据，该初始化数据指示来自被配置成主设备的第一设备的在总线上传送的第一消息中的操作数据消息部分，该操作数据消息部分专用于被配置成从设备的第二设备中的相应的第二设备；并且被配置成从设备的第二设备可以接收来自被配置成主设备的第一设备的在总线上传送的初始化消息，并且可以根据初始化数据进行初始化，以读取在操作数据消息部分集中的专用于该第二设备的相应的操作数据消息部分。
[0318] 在一个或多个实施例中，一种方法可以包括将被配置成从设备的第二设备集中的第二设备布置在第二设备的子集中，其中被配置成主设备的第一设备可以在总线上传送包括子集标识索引的第一消息，该子集标识索引标识第一操作消息专用于的第二设备的子集。
[0319] 在一个或多个实施例中，被配置成主设备的第一设备可以以恒定速率在总线上传送第一消息。
[0320] 在一个或多个实施例中，作为相应的看门狗定时器到期的结果，在第二设备集中的第二设备可以切换到故障安全状态。
[0321] 在一个或多个实施例中，作为从被配置成主设备的第一设备接收从第一消息和第二消息中选择的消息的结果，第二设备集中的第二设备可以将相应的看门狗定时器复位。
[0322] 在一个或多个实施例中，第一设备可以对于所请求的来自第二设备集中的第二设备的相应的反应未在相应的预期反应间隔内到达第一设备敏感，和/或可以触发相应的看门狗错误信号，该看门狗错误信号指示第二设备集中的第二设备，来自该第二设备的相应的反应未在相应的预期反应间隔内到达第一设备。
[0323] 在一个或多个实施例中，总线可以包括差分布线总线。
[0324] 在一个或多个实施例中，系统可以包括经由总线(例如，30)耦合的第一设备(例如，10)和第二设备集(例如，201、202...20n)，其中第一设备和第二设备可以分别被配置成主设备和从设备，并且主设备和从设备可以被配置成利用一个或多个实施例的方法来操作。
[0325] 在一个或多个实施例中，用于作为第一设备经由总线(例如，30)耦合到第二设备集(例如，201、202...20n)的设备(例如，10)可以被配置成在总线上传送：
[0326] 第一消息，其携带操作数据消息部分集，该操作数据消息部分集指示用于由第二设备集中的第二设备实施的操作，和
[0327] 第二消息，其被寻址到第二设备集中的第二设备，第二消息请求在相应的预期反应间隔内对第一设备做出相应的反应，第二消息传达标识第二消息被寻址所至的第二设备中的相应的第二设备的标识符。
[0328] 在一个或多个实施例中，用于作为第一设备经由总线耦合到第二设备集的设备可以对于所请求的来自第二设备集中的第二设备的相应的反应未在相应的预期反应间隔内到达第一设备敏感，和/或可以被配置成触发相应的看门狗错误信号，该看门狗错误信号指示第二设备集中的第二设备，来自该第二设备的相应的反应未在相应的预期反应间隔内到达第一设备。
[0329] 在一个或多个实施例中，用于包括在经由总线(例如，30)耦合到第一设备(例如，10)的第二设备集(例如，201、202...20n)中的设备(例如，20i)可以被配置成：
[0330] 在总线上接收第一消息，该第一消息携带操作数据消息部分集，该操作数据消息部分集指示用于由第二设备集中的第二设备实施的操作；读取操作数据消息部分集中的至少一个相应的操作数据消息部分；以及根据所读取的至少一个相应的操作数据消息部分来实施至少一个相应的操作；
[0331] 在总线上接收相应的第二消息，该第二消息传达将设备标识为相应的第二消息被寻址所至的第二设备中的第二设备的标识符，相应的第二消息请求设备在相应的预期反应间隔内对第一设备做出相应的反应，并且在相应的预期反应间隔内对其做出反应，其中来自设备的反应消息在总线上被传送到被配置成主设备的第一设备。
[0332] 在一个或多个实施例中，用于包括在经由总线耦合到第一设备的第二设备集中的设备可以被配置成作为相应的看门狗定时器到期的结果而切换到故障安全状态。
[0333] 在一个或多个实施例中，用于包括在经由总线耦合到第一设备的第二设备集中的设备可以被配置成作为经由总线接收到来自第一设备的消息的结果而将相应的看门狗定时器复位。
[0334] 在一个或多个实施例中，用于包括在经由总线耦合到第一设备的第二设备集中的设备可以包括HW通信和协议控制器(例如，201)，该HW通信和协议控制器包括在其中实现的专用硬件。
[0335] 在一个或多个实施例中，用于包括在经由总线耦合到第一设备的第二设备集中的设备可以包括光辐射源驱动器，优选地交通工具灯驱动器。
[0336] 在一个或多个实施例中，交通工具(例如，V)可以配备有根据一个或多个实施例的系统。
[0337] 在一个或多个实施例中，在根据一个或多个实施例的系统中在总线上(例如，30)可传送以将消息从第一设备(例如，10)传送到第二设备集(例如，201、202...20n)的信号可以包括：
[0338] 第一消息，其携带操作数据消息部分集，该操作数据消息部分集指示用于由第二设备集中的第二设备实施的操作，和
[0339] 第二消息，其被寻址到第二设备集中的第二设备，第二消息请求在相应的预期反应间隔内对第一设备做出相应的反应，第二消息传达标识第二消息被寻址所至的第二设备中的相应的第二设备的标识符。
[0340] 在一个或多个实施例中，传送第一消息的信号可以以恒定速率发生，该第一消息携带专用于被配置成从设备的第二设备的操作数据消息部分集。
[0341] 在不影响基本原理的情况下，在不脱离保护范围的情况下，细节和实施例可以相对于仅作为示例描述的内容变化，甚至显著地变化。
| 标题 | 发布/更新时间 | 阅读量 |
|---|---|---|
| 面向中低频正弦信号的频率故障注入器 | 2020-05-11 | 414 |
| 一种物联网仪表时钟定时装置 | 2020-05-11 | 53 |
| 一种食品安全检测方法 | 2020-05-11 | 336 |
| 伺服转台防飞车系统 | 2020-05-13 | 892 |
| 智能水龙头手势感应出水方法及系统 | 2020-05-13 | 414 |
| 一种车灯控制器及用于该车灯控制器的监控方法 | 2020-05-08 | 950 |
| 一种飞机伺服作动系统开车前自检方法 | 2020-05-12 | 443 |
| 主输入输出子模块及其诊断方法、可编辑逻辑控制器 | 2020-05-13 | 551 |
| 一种定时器时钟检测系统 | 2020-05-11 | 128 |
| 一种USB开关重启控制装置 | 2020-05-08 | 805 |
高效检索全球专利专利汇是专利免费检索,专利查询,专利分析-国家发明专利查询检索分析平台，是提供专利分析，专利查询，专利检索等数据服务功能的知识产权数据服务商。
我们的产品包含105个国家的1.26亿组数据，免费查、免费专利分析。
分析报告
专利汇分析报告产品可以对行业情报数据进行梳理分析，涉及维度包括行业专利基本状况分析、地域分析、技术分析、发明人分析、申请人分析、专利权人分析、失效分析、核心专利分析、法律分析、研发重点分析、企业专利处境分析、技术处境分析、专利寿命分析、企业定位分析、引证分析等超过60个分析角度，系统通过AI智能系统对图表进行解读，只需1分钟，一键生成行业专利分析报告。
QQ群二维码
意见反馈
意见反馈