SDS、DeviceNet和CAN Kingdom之比较
经过5年在分布式控制系统领域专注发展，KVASER公司从1989年开始从事CAN领域的研发工作。对于分布式控制系统，CAN不是一种完整的协议。始终需要“高层协议”。1990年，KVASER开始开发以下目标的协议：系统设计员可以按照自己的意愿设计他们的CAN系统，但是仍然使用独立开发的“标准”�？�。第二年，CAN Kingdom第一个版本发布。当前的版本是3.0。霍尼韦尔（Honeywell）和艾伦 – 布拉德利（Allen-Bradley）公司都认识到了对高层协议的需求，并各自推出了“智能分布式系统”（SDS）和DeviceNet。
经常有人问我们CAN Kingdom、SDS和DeviceNet之间的区别。由我们来比较我们自己的高层协议和其它两种协议似乎不大合适，但是因为尚未有其他人发布这种比较，我们决定进行这种比较：这三种协议并不是真正的竞争关系。有人提问“哪种CAN高层协议最好？”，者就像在问“哪种交通方式最好：汽车、船舶还是飞机？”。答案取决于要解决的问题。在KVASER公司，我们目前在不同的项目中用到了所有这三种协议。事实上，DeviceNet和SDS（以及J1939）�？榭梢约傻紺AN Kingdom系统中（但是反之则不行）。
概述
DeviceNet、SDS和CAN Kingdom都是基于ISO11898 CAN通信协议并且电路符合CAN规范。这意味着符合任何一种协议的�？槎伎梢粤拥酵桓鯟AN总线。但是，当符合不同协议的模块连接到同一个CAN总线时，经常会发生问题（由于应用层对报文的不同解释）。CAN Kingdom有一处重要的原理与SDS和DeviceNet不同：CAN Kingdom假设启动时存在组织系统的一个节点（King），而SDS和DeviceNet不做这种假设。King的存在能够简化复杂实时系统的设计工作和减少所需的�？樾鞴娣短蹩睿ㄍǔ３莆芭渲梦募保�。
SDS在把输入/输出设备（例如通/断开关、距离感应器等）连接到PLC时非常有效，因为SDS从根本上来讲是主机和远程输入/输出之间的点到点通信。
DeviceNet基本上是一种开放的总线系统，系统中所有模块都有使用总线的相同权力，并且使用总线仅受一些规则限制。�？樯杓迫嗽笨梢园淹ㄐ趴刂颇芰桓渌？椋ɡ缭谠ざㄒ宓闹�/从模式中交给主节点），但是DeviceNet本身不强制�？榻姓庵中形�。当用在遵循DeviceNet子集“预定义的主/从连接集”的输入/输出设备时，DeviceNet的特点与SDS非常接近。
CAN Kingdom协议着重于生成、链接和控制系统，不包含诸如数字和模拟等设备的配置文件。CAN Kingdom的基本概念是，当�？榱拥较低呈备久挥腥ㄏ藿腥魏尾僮鳎荒艿却醋訩ing的指示。所有的CAN优先级/标识符均为King所有。在启动过程中，King会配置每个�？椋？橹械南鸦蛏韵蠓峙溆畔燃�/标识符。King类似于主节点，但是仅作用于系统配置期间。King可能不参与不同�？橹性诵械挠τ贸绦蛑湓诵惺钡耐ㄐ�。在完成配置和一致性检查，并且每个�？橐丫咽盏降闹甘敬娲⒃诜且资Т娲⑵髦泻螅ǔ？梢砸瞥齂ing。
节点号
CAN不需要任何物理地址（例如节点号）来进行通信。这是CAN的一个重要特性，因为这样�？榫臀扌杈弑腹赜诠ぷ髟谄渲械南低车娜魏沃�。然而，在系统配置期间（通常也是服务期间），必须对特定的节点进行寻址。出于这个目的，必须保留至少一个CAN优先级/标识符，并且必须为每个�？榉峙湟桓鼋诘愫�。对于发往和来自�？榈呐渲煤头癖ㄎ模奖愕淖龇ㄊ前训刂泛徒诘愫沤泄亓�。CAN Kingdom、DeviceNet和SDS都使用这种技术。可以有几种方式分配节点号，以下是一些建议：
DIP开关
- 缺点：很有可能发生人工错误和连接点损坏导致的错误。通常没有检验和来检测错误。开关通常必须与四周环境进行隔离，需要螺丝刀或类似工具来使用开关。开放式开关的设置很容易被意外改变。
- 优点：操作人员无须任何服务仪器即可查看节点号。
通过连接器引脚进行编码
- 缺点：很有可能发生人工错误和连接点损坏导致的错误。通常没有检验和来检测错误。只有在打开时或通过外壳上的窗口才能查看连接器的设置。需要文档来说明如何编码连接器中的设置。可用的组合很少。连接器引脚比较昂贵（特别是密封连接器中的引脚）。
- 优点：编码存储在线缆中，而不是模块中。替换�？槭保履？榻诎沧笆被竦媒诘愫�。无需服务仪器即可获得节点号。
存储在内部存储器中
- 缺点：连接到系统之前，必须使用工具把节点号编程到模块中。如果�？橛幸桓錾形丛谙低持惺褂玫哪辖诘愫牛赡芸梢栽诎沧澳？槭敝匦路峙浯私诘愫�。
- 优点：节点号无需任何窗口或连接器引脚。通常节点号连同检验和一起存储在非易失存储器中。因为存储空间只需几个字节，所以成本低廉。存储器还可以存储其它参数。与连接器和开关相比，存储器发生故障的概率较小。
存储在连接器的存储器中
- 缺点：市场上尚未推出包含存储器的连接器。连接器中需要一个或两个额外的引脚用于读取来自连接器的信息。
- 优点：与内部存储器相同。如果同时在连接器和模块的非易失存储器中存储节点地址，可以获得非常高的安全性（防止�？榉糯砦恢茫Ｄ？樵诎沧爸拔扌枇拥椒褚瞧�。
三种CAN高层协议都没有为节点号设置指定方法。SDS和DeviceNet规范都描述了�？橹锌氐氖褂煤褪褂媚承┕ぞ咄ü鼵AN总线进行设置。来自Allen-Bradley的第一个DeviceNet模块（Flex-I/O）使用开关。来自Honeywell的SDS�？槭褂媚诓看娲⒔诘愫牛ǹ梢酝ü鼵AN进行改变）。默认节点号是125 – 允许的最大节点号（Honeywell的第一个SDS�？槭褂�0作为默认节点号，这导致新节点连接到系统时具有最高优先级的报文。这种设计后来得以改变。）。DeviceNet规范允许�？榘哑浣诘愫糯娲⒃诖娲⑵髦小Ｄ系慕诘愫攀�63 – 也是允许的最大节点号。
SDS不对重复节点号进行任何测试或检查。SDS始终假设每个输入/输出�？槎加幸桓鲋骰飧鲋骰匦虢兴行枰募觳�。通过读取所有设备的供应商号和序列号，可以检查是否存在重复的节点号。如果存在重复节点号，可以由主机改变输入/输出�？榈慕诘愫牛蛘呖梢怨乇障低�。如果系统中有多个主机，主机之间必须进行某种通信来确保输入/输出节点号唯一。
在DeviceNet中，每个�？槎挤峙溆幸恍┯畔燃�/标识符来用于其报文。这些标识符是节点号的函数（在DeviceNet中称为MAC ID）。重要的是，�？椴坏檬褂孟嗤腗AC ID（因为它们随后将使用相同的CAN ID进行传输，这违反CAN规范）。一个启动时例程（称为“重复MacID检查”）保证系统中不会存在重复的MAC ID。如果一个节点使用系统中已经存在的MacID，那么在进行重复MAC ID检查时，将从已经在使用这个相同MAC ID的�？槭盏奖ㄎ母嬷扒肜肟芟撸 �。
在CAN Kingdom中，所有优先级/标识符在启动时均由King拥有（除了一个接收标识符“King的报文”）。每个�？槎颊焯癒ing的报文”。这样，在得到King允许之前，没有任何节点可以进行任何通信。King可以在分发标识符和其它设置参数之前进行系统的一致性检查。如果检测到任何�？榫哂邢嗤慕诘愫牛琄ing可以为它们重新分配节点号或者禁止它们继续使用总线。如果检测到King不知道的�？榛蚨У慕诘悖琄ing可以拒绝启动系统。CAN Kingdom使得系统设计员能够设计出对于终端用户具备“即插即用”能力的安全系统。
SDS和CAN Kingdom都假设一些类型的机器控制系统带有至少一个可以检查系统的监控节点。通常，如果一个节点对于系统处于未知状态或者建议的�？槎В舳飧鼋诘憬廖抻么�。即使所有�？槎家汛嬖冢谴υ诖砦蟮奈恢茫舳低骋彩呛廖抻么�。如果节点号存储在总线连接器中，那么检查任务将得以简化。每个连接器都代表系统中的一个特定位置。因为每个节点号都与一种模块类型匹配（或者甚至是一个特定的单独�？椋钥梢约觳槌鋈魏挝恢么砦蟮哪？�。通过同时在连接器和�？橹写娲⒔诘愫牛梢允侗鹣低持腥魏挝抟饣蛴幸獾母谋�。而且，在�？榇酉低持卸е埃够岢鱿至酱谓诘愫殴收�。
比特率
在CAN网络中，所有�？槎忌柚贸上嗤谋忍芈屎苤匾�。除了短接CAN总线之外，破坏通信的最简单方法是安装一个比特率极小和设置错误的节点。通常，这样做的结果是所有其它模块都离开总线。SDS、CAN Kingdom和DeviceNet都建议不同的方法来避免这种情况。
SDS提出的一种建议的实践是“自动波特”。由主节点通过最低可能地址来设置比特率。所有其它�？槎冀觳樽芟呱媳忍亓鞯谋忍厥奔浯敛⑾嘤Φ厣柚闷浔忍芈省＝ㄒ榈谋忍芈视兴闹�：125k、250k、500k和1M。
DeviceNet指定三种比特率：125k、250k和500k。但是没有任何保护措施来防止错误的比特率设置。即使没有指定，一些DeviceNet模块使用自动波特。
CAN Kingdom没有指定任何预定义的比特率或自动波特。但是规定，在通电后的前200毫秒期间，�？楸匦胍�125 kbit进行被动侦听（固定设置或指定设置）。通过这个过程，始终可以通过这项固定的设置发现错误编码的�？�。被动通信表示�？橹徽焯鼵AN通信，但是不允许在总线上传输显性位。然后，设置成错误比特率的节点再也无法破坏总线上的通信。CAN Kingdom还指定如何改变比特率。
优先级的使用
CAN中的总线访问优先级通过报文的前11位或29位（称为“标识符字段”）给出（更精确地名称应该是“优先级字段”，因为总线访问优先级是指定的唯一服务）。11位标识符称为标准标识符，29位标识符称为扩展标识符。SDS和DeviceNet指定标准标识符的使用。CAN Kingdom可以使用标准标识符，也可以使用扩展标识符。
SDS允许125个�？榱拥酵纾扛瞿？槎几胍幌盗斜晔斗ㄓ肫浣诘愫畔喙兀�：
接收标识符，（N·8）到（N·8+7）
传输标识符，（N·8+1024）到（N·8+1031）
其中N = 节点号。
下方列表显示SDS中指定的用于125个节点号中一部分的优先级/标识符的范围：
节点号 起始主机/主节点 结束主机/主节点
0 0-7 1024-1031
1 8-15 1032-1039
.
63 504-511 1528-1535
.
124 992-999 2016-2024
125 1000-1007 2024-2031
SDS中未指定1008-1023的使用。使用设备或对应主节点没有占用的优先级不会干扰任何SDS设备的行为。
Device Net允许64个节点，使用更复杂的方法来分发优先级/标识符。标识符分成三个组，分别表示高、中和低优先级。在DeviceNet网络中，每个�？檎加靡幌盗忻扛鲎橹械挠畔燃叮ò凑障铝泄剑�：
组1：M·64+N M=[0..15]
组2：M+1024+N·8 M=[0..7]
组3：M·64+1536+N M=[0..6]
其中N是节点号，在DeviceNet中称为MAC ID。
上述方案不会包含所有CAN优先级/标识符。剩下的[1984..2031]保留用于将来的组4。
方案形成CAN标识符字段中的位模式：
| 标识符位 | 标识符使用 | ||||||||||
| 10 | 9 | 8 | 7 | 6 | 5 | 4 | 3 | 2 | 1 | 0 | |
| 0 | 组1 报文 ID | 源MAC ID | 报文组1 | ||||||||
| 1 | 0 | MAC ID | 组2报文ID | 报文组2 | |||||||
| 1 | 1 | 组3报文ID | 源MAC ID | 报文组3 | |||||||
| 1 | 1 | 1 | 1 | 1 | 组4 报文ID | 报文组4（保留给将来使用） | |||||
| 1 | 1 | 1 | 1 | 1 | 1 | 1 | x | x | x | x | 无效的CAN ID |
分发给不同节点的标识符如下：
节点号 组1 组2 组3
0 0,64,128,…960 1024-1031 1536,1600,1664,..1920
1 1,65,129,..961 1032-1039 1537,1601,1665,..1921
.
.
62 62,126,190,..1022 1520-1527 1598,1662,1726,..1982
63 63,127,191,..1023 1528-1535 1599,1663,1727,..1983
每个节点拥有31个标识符，但是其中三个保留用于连接建立，一个保留用于“重复的MAC ID报文”。
这样，标识符被分发给系统中的所有�？�。组1和3是发送标识符（因为它们包含源MAC ID），但是组2可以是发送标识符或接收标识符。也就是说，组2标识符的属主可以选择使用此标识符接收报文以及给予权限向另一个�？榉⑺捅ㄎ�。因此，一开始仅分发发送标识符。但是它使得接收方构成通信。显然，必须有一种机制用于建立连接，确定每个�？樯夏男┍晔斗糜诜⑺突蚪邮毡ㄎ�。事实上，有两个步骤：未连接报文管理器和预定义主/从连接集。
未连接报文管理器（UCMM）
UCMM是模块互连的建议方法。有两个组3报文保留用于此目的。一个用于未连接的显式请求报文，一个用于未连接的显式响应报文。一个想要与另一个模块建立联系的�？榉⑺臀戳拥南允角肭蟊ㄎ模谑葑侄沃邪硪桓瞿？榈腗AC ID。当另一个�？樵诒ㄎ闹屑觳獾剿腗AC ID时，通过未连接的显式响应报文进行响应。这个过程中，建立了双向通信，两个�？槎蓟嵛ㄐ欧峙湟桓隹障械挠畔燃�/标识符。通过这种双向通信，可以读写�？橹腥魏慰捎玫男畔�。�？榭梢杂行矶嗾庵至右桓龌蚨喔瞿？榈耐ǖ�。在DeviceNet中对此没有任何限制。UCMM的结果是，�？楸匦胱急附邮�63条不同的未连接的显式请求报文（任何可能的其它节点都有一条报文）。
上述过程反映出DeviceNet的基本思想是一种开放型总线。一些资源（优先级/标识符通道）通过节点号分配给�？椴⑶夷？橥耆刂普庑┳试�。系统属主可以尝试联系安装的�？椴⑽潞偷厍肭竺扛瞿？槭褂米芟呦低车哪承┳试矗亲钪盏木龆ㄈㄊ贾赵诟鞲瞿？槭种�。所有这31个优先级/标识符都用于�？榉⑺捅ㄎ模衅渌畔燃�/标识符可以自由地用于接收报文（当�？橹幸丫⒑眯畔⑹褂寐肪逗螅�
预定义的主/从连接集
UCMM过程要求所有模块接收63个优先级/标识符（系统中每个其它可能�？槎加幸桓觯┎⑼瓿纱罅抗芾矸�。这个任务需要大量计算机功率和RAM/ROM，对于带有集成的CAN控制器的小型8位处理器来说要求太高。为了能够在DeviceNet中使用这种简单的设备，有一种替代方案称为“预定义的主/从连接集”。一条组2报文被保留用于此目的。通常，优先级/标识符字段中的所有MAC ID都是源MAC ID，但是这对于组2中的标识符并非总是适用。组2提供了使用低成本CAN设备（能够通过部分特定模式只使用接收标识符）的可能性。然后MAC ID可用于过滤。通过保留的组2报文，�？榭梢郧肭罅硪桓瞿？榻⑺腿ㄗ渥�2报文中的两条。接受请求时，目标�？榘颜饬礁霰晔斗怀山邮毡晔斗肭竽？橄衷诨竦昧礁鲂碌谋晔斗糜诜⑺捅ㄎ�。这个过程建立了一个需要较少计算机资源的通信通道。
CAN Kingdom
自从CAN诞生以来，人们一直希望有一种完全开放的高层协议，能够立即使用连到总线上的任何模块，然后开始在系统中象完美的同伴那样工作。我们还远未实现这种解决方案。一个重要的问题是标识符的分发。SDS和DeviceNet都采用方法把分发包含在规范中。SDS实现方法简单，但是带来较高的系统性能成本。DeviceNet更灵活，但是过程更加复杂，并且每个节点只有一些标识符可供使用。仍然留下这样一个大问题：“�？樵跹烙肽男┢渌？榻型ㄐ牛俊�
CAN Kingdom使用与SDS和DeviceNet不同的方法。系统中的一个节点（King）负责组织系统。King具备关于系统体系的所有知识以及系统如何工作。King在启动时拥有所有标识符，然后将这些标识符分发给�？�。因为King知道连接方案，它会为�？榻⑺偷拿刻醣ㄎ姆峙湟桓龇⑺捅晔斗？榻邮盏拿刻醣ㄎ姆峙湟桓鼋邮毡晔斗�。这个过程有三个主要优点：�？槲扌刖弑腹赜谙低车娜魏沃�、可以以最有效的方式使用CAN优先级、为其它高层协议（例如SDS和DeviceNet）设计的�？橐部梢约傻紺AN Kingdom网络中。
应用层
SDS和DeviceNet都为许多不同的设备指定了规范概要，包括发送到�？榈男形褪萁峁购痛幽？榻邮盏男形褪萁峁�。因为两种协议中都没有定义任何系统负责节点，所以需要这些规范概要。
在CAN Kingdom中，始终有一个系统负责节点（至少在系统第一次启动时）。与指定最后应如何设计模块不同，CAN Kingdom指定怎样调整�？槔绰闶导实南低承枰ɡ缤ü钊绫忍芈�、节点号和优先级等系统数据概要来进行指定）。
表格形式比较
下面以表格形式比较SDS、DeviceNet和CAN Kingdom的一些特性。
比特率
| SDS | DeviceNet | CAN Kingdom | |
| 可能的比特率 | 125k, 250k, 500k, 1M | 125k, 250k, 500k | 任何比特率（服务比特率为125k） |
| 防止错误比特率�？� | 是 | 否 | 是 |
| 自动波特 | 是，指定 | 可能，但是未指定 | 可能，但是未指定 |
| 是否可由高层协议改变 | 否。仅自动波特。 | 是。 否（如果由开关设置）。 |
是。 |
节点号
| SDS | DeviceNet | CAN Kingdom | |
| 可能的节点号 | 0-125 | 0-63 | (0) 1-255 |
| 默认节点号 | 125 | 63 | 无 在服务模式中设置或从连接器读取。 |
| 防止重复号 | 否/是（高层协议支持主机进行检查）。 | 是（重复MAC ID检查）。 | 否/是（高层协议支持King进行检查）。 |
| 是否可由高层协议进行改变 | 是。 | 是 否（如果由开关进行设置）。 |
是。 |
优先级/标识符等的基本信息
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 通电时�？橛涤械挠畔燃�。 | 8 + (8) | 31 + (63) | 0/1 + (2) |
| 用于常规用途的优先级。 | 无 | 每个�？�26个。 | 任何尚未占用的优先级。 |
| CAN远程发送请求 | 否 | 否 | 是 |
| 扩展CAN | 否 | 否 | 是 |
| 系统控制优先级 | 否，通过选择节点号来赋予优先级。 | 3个组（包含16、5和5个给出的优先级），可以从中选择。 | 是，由系统设计控制。 |
| 空闲优先级 | 无 | 无 | 全部 |
| 通过预定义的设置开始 | 由高层协议固定。始终采用预定义的设置。 | 不受高层协议支持。任何�？槎伎梢酝ü？橛涤械�27个优先级/标识符自由执行希望的操作。 | King可以命令�？橥ü醋苑且资Т娲⑵鞯纳柚每计舳�。 |
| 通电时自动启动 | 是（自动波特调整后），通过设置请求位 | 任何模块都可以通过�？橛涤械�27个优先级/标识符自由执行希望的操作。 | 是（如果之前已得到King允许）。这是一种退化的Kingdom。 |
| 启动时预定义的优先级/标识符并保留给�？槭褂�。 | 启动时：8Tx, 8 Rx 源主机：N*8-N*8+7 |
目的主机：
1024+
N*8-N*8+7启动时：2 Tx, 3 Rx
Grp1:N+M*64M=0-15Grp2:N*8+1024+M M=0-7
Grp3:N+1536+M*64M=0-6启动时：前200毫秒期间：0 Tx, 2Rx0和2031。
然后是前面King设置的任何号。
N= 节点号，其中N可以是系统中�？槭褂玫娜魏谓诘愫拧�
M=DeviceNet规范中定义的报文标识符。
系统控制
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 重置模块 | 不可以 | 可以，从建立的连接进行。 | 可以 |
| 把�？榉峙涓� | 可以，1个组。 | 不可以 | 可以，255减去系统中的�？槭� |
| CAN接收掩码设置 | 不可以 | 不可以 | 可以 |
从系统分配优先级/标识符
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 为新连接分配优先级 | 不可以 | 可以，通过连接对象，最多26个生产者对象。 | 可以。仅受空闲优先级数量和�？榇娲⑷萘肯拗�。 |
实时支持
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 实时时钟（RTC） | 不支持 | 不支持 | 支持 |
| RTC精度 | 1纳秒至1小时 | ||
| �？橹涞腞TC偏差 | 一个位长之内。 | ||
| 限制优先级/标识符重复率 | 不支持 | 不支持 | 支持 |
| 定时的高层协议生产 | 支持，10、24ms [0..255]为单位 | 支持，1ms精度 | 支持，按照RTC精度。 |
| 在时间窗口内生产 | 不支持 | 不支持 | 支持，按照RTC精度。 |
| 发生消费事件时进行高层协议生产 | 不支持 | 仅在“预定义的主/从连接集”中。 | 支持，在高层协议层。 |
应用程序支持
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 高层协议中的函数和数据结构（概要）。 | 支持，通过Honeywell定义的设备。 | 支持，通过ODVA定义的设备。 | 没有规定。 |
| 是否支持从应用层元素构建新的数据结构。 | 不支持 | 支持，可以有一个合集对象 | 支持，高层协议包含工具来构建新的数据结构（通过把元素链接到通用对象）。 |
| 优先级位中是否可能带有数据。 | 支持，但是由高层协议固定 | 不支持 | 支持，任何位序列都可以链接到一个内部数据结构 |
| 高层协议是否支持大于8字节的应用程序数据结构 | 支持，最大为255字节，每次最多传输4字节 | 支持，长度不限。每次传输7或6字节 | 没有高层协议支持。 |
| 块传输 | 不支持 | 不支持 | 支持，不限长度。每次传输6字节 |
| 多路复用的数据 | 不支持 | 不支持 | 支持，通过把标识符扩展到数据字节中。 |
�？楸晔斗⒉�
| 属性 | SDS | DeviceNet | CAN Kingdom |
| 管理员 | Honeywell | ODVA | EAN International, UCC |
| 供应商Id号 | 16位，0..65535 | 16位，0..65535 | 包含在产品代码中。 |
| 设备类型 | 5*8位 | 16位，0..65535 | 包含在产品代码中。 |
| 产品代码 | 无，参见ASCII信息。 | 16位，0..65535 | 40位EAN-13代码。 |
| 序列号 | 32位 | 32位 | 40位 |
| 软件版本 | 12位ASCII | 16位主版本号，16位副版本号 | 包含在EAN-13代码中，或者另外的EAN-13代码。 |
| ASCII信息 | 日期 4字节 类别 32字节 供应商 32字节 设备 32字节 |
产品名称（0到255字节） | 未指定 |
总结
SDS
- 把小型设备连接到主控制器的简单有效方法。
- 主控制器完全控制所有�？�。
- 如果没有主控PLC，不支持模块之间的通信。
- 仅支持标准CAN。
DeviceNet
- 开放式系统，其中的每个�？槎际且桓霰镜刂鹘诘�。
- 系统设计员无法一直控制模块（本地主节点）。
- 对于�？橹涞拇洌С稚�/消费者模型。
- 一个�？橹锌勺杂墒褂玫挠畔燃妒肯拗莆�27。
- 有一个小型内核（但是仅在预定义的主/从连接集中）。
- 仅支持标准CAN。
CAN Kingdom
- 系统设计员始终可以通过King完全控制所有�？�。
- 对于�？橹淠？榈拇洌С稚�/消费者模型。
- 可以控制CAN总线上的实时行为。
- 充分利用CAN协议中的优先级功能。
- 可以为一个模块分配任何数目的优先级。
- 支持在高层协议中进行数据结构转换。
- 小内核，通常只有500-1500字节码和24-48字节的内存。
- 支持标准和扩展CAN。
