|
作者：梓 元节能
第一章 系统构架概述
对于这个构架，我们已经开发了3年，从最初的《校园节能》到《无线组网》再到《smart school》再到《smart OS》我们已经经历了4个版本的变化了。在这4个版本里面，我们在不断变换着自己的工作重心，试图让各种不同的设备相互通信。但是每一次都是在10个 设备左右就出现了各种奇葩的问题，导致我们的协议系统崩溃。无法让各个设备之间进行兼容或者因为兼容的问题导致我们需要做大量的重发开发工作。这些看似简 单的工作却要消耗我们大量的时间来进行验证作业。我们已经累了，真的不想为每一个设备因为要调用其他设备而独立的进行开发了，所以我们开始了自己的内部的 标准化之路。
我们希望使用类似微软的RDP（远程桌面协议）来对各个设备进行访问。当一个设备需要解读其他的设备时，只需要你将需要接入的设备的RDP协 议加载到你的通信协议系统中，就可以完成对于该设备的加入操作。相关的调用过程你可以按照自己的思路来进行开发。我们希望让自己的开发作业变得标准化，不 想为每一个设备都进行独立的作业！这样的效率实在太低下并且因为通用性的原因，让我们为了让一个系统可以稳定的动作而不等不做出各种各样的让步。导致系统 的设计远离了我们的初衷。
为什么要有这样的ML_network？
因为我们发现对于单品设备在这个地球上基本很难卖出了，你不可能要去用户每购买一个智能设备就安装一个APP！我们需要有集成方案，用户可以使用一个APP就可以管理所有的设备。但是用户不是流水线上的产品，有统一的需求。所有对于每一个用户其使用基本都是定制开发。如果没有一定规模的智能硬件可以相互通信，做定制开发玩搭积木的有效简直就是胡扯！为了实现基本的类似IFTTT（if this than that 如果**就**），我们就需要在一个最基本的系统里面有一个传感器 、执行器和控制器。这三者需要互联！相互通信并且为了配置的方便我们希望有更多的设备可以相互接入。
如果只是单纯的10个设备互联，我们可以使用轮询的方式实现，但是我们需要考虑未来的接入能力，我们希望我们的网络是复杂的结构，我们想到了蚂蚁算法，我们找到了一种高效而有简单的方式来实现对整个网络节点的管理，当然这个算法需要泡在32位的单片机上才不会显得吃力。
如果有这样一个ML_network 我们可以做什么？
我 们现在是一家关注与校园能源管理的公司，我们希望在公共能源管理上面有所为！为学校师生提供基于时间、人员密度、日照、温度、课程计划等多维度的能源管理 方案。当我们去做这些时，我们发现学校用户并不是每一个都需要所有的设备的，他们可能需要裁剪，只是提取其中的某一部分来进行应用。实现比如：1、天黑有人开灯，人来灯亮；2、当人员数量超过X数值时，开启全部照明，否则仅开启一部分；3、当22点以后，请及时熄灯。如果教室内有人则提示请及时离开。
通过在教室内布置不同的传感器和执行器，我们有理由实现用户的各种需求并为他们提供长久的能源管理服务。我们需要对我们的设备能源管理逻辑的本身进行监管，以提高我们的利用效率，并试图在合同能源管理中有一份属于自己的地盘。
如果我们有照度传感器，当你设备开灯后，而照度值没有改变，你可以判断出照明设备损坏，可以向用户推送相关的维护服务。这也许就是互联网下的020的变种。
如果我们有人员运动传感器，在夜间我们起夜是使用柔和的光线来为你照亮前方的道路。
如果我们离家在外，家里的老人超过12小时无运动迹象，我们可以及时向你推送相关消息，可能我们来晚了，但我们还是来了。
我们有很的想法，但是当我们止步不前时，很多东西都会变成别人的成果！
我们这么做的目的是什么？
我们希望像我们这样一类只会写C代码的人，能够在智能家居或者居家养老这类相对比较定制化的市场里面有一席之地，我们通过购买已经开源的硬件产品。自己修改代码实现自己想要的功能，或者通过RDP来调用相关接口实现对于设备的远程读取或控制，为客户实现定制开发，施展自己的才华从而获得利润！
未来的智能硬件，一定会向着个性化定制的方向移动！对于智能硬件的制造将会是巨头们的游戏，我们平民就学会使用并创造价值即可。如果不理解我们可以想一下电脑。做电脑的就那么几家公司，但是靠电脑吃饭的就有很多！
对于智能硬件，开源并协助开发者快速投入市场将会是智能家居或者居家养老、安防等定制领域的风口！
为了建立起ML_Network，我们需要哪些设备？
我们需要开关量执行器，使用AC switch 或者继电器来进行控制；我们需要有PWM的调速控制，实现对风扇或者电机的调速控制。我们需要人员运动传感器、时间、日照、温度传感器；我们需要一个总控设备来建立起属于用户自己的控制逻辑。
如果你认为这个ML_Network对于你有作用，我们希望与你合作！我们寻求知识产权、软硬件开发、物料与方案供应、生产等相关流程的协助。
如果您认为您可以帮助到我们，欢迎关注我们的微信公众号：我们将在微信公众号里面推送更多相关ML_Network 相关的开发进度及我们需要的实际需求。
第二章 通信协议构架说明
关于通信协议，我们做了很多的尝试！因为通信协议的问题让我们的设备开发在经历了一段时间的积累后因为协议设计的局限性导致后期的设备属性变得异常复杂。一个设备要想和另一个设备通信，需要对其中的一个设备通信协议进行修改以便匹配对应的逻辑关系。
我们不想每次都要重复以前的劳动，也因为这个原因，我们在不断进行着改版的测试。
这一次，我们想到了RDP的方式，每一个功能模块都以同样的接口形式出现。方便使用同一的标准来进行规范。方便后期的多设备互联通信。
协议的基础构架如下：
项目名称
空间大小
备注
发送类别
1byte
用于指示发送端的类别码，在协议中相当于关键字用来识别使用什么样的协议模式来进行解析
发送序列
1byte
用于区别同一类别码中不同的设备ID，防止因为系统中的设备过多发生冲突
发送序列号
1byte
用于指示发送包的序列号，防止在双向通行时重复接收
发送数据包长度
1byte
一个数据包的最大长度为32byte，可以进行组包发送。数据从发送类别到LRC前的数据长度
接收类别
1byte
用于指示接收端的类别码
接收序列
1byte
用于指示接收的设备ID号
RDP1 keyword
1byte
用于指示本指令的具体命令
RDP1内容
N byte
该出为协议的具体内容部分
RDP2 keyword
1byte
用于指示本指令2的具体命令
RDP2内容
N byte
RDP2 协议具体内容
RDPN keyword
1byte
用于指示本指令N的具体命令
RDP N内容
N byte
RDPN 协议具体内容
LRC校验
1byte
用于确认协议是否完整，从协议头到RDPN的所有数据异或和
为什么ML_Network 需要有**类别、**序列？
对于一个网络而言，我们需要对网络里面的每一个成员分配一个唯一ID，使用类别+序列的方式可以实现分类管理，比如我们将ML_Network的成员分为主控、路由、执行、传感器这几大类。设备里的成员需要知道使用什么样的协议格式来继续处理，而类别正好回答了我们的问题。使用序列的目的是为了区分同一系统里面因为有多个同类别的设备，防止设备控制冲突产生。
之所以使用收发双向，是为了在通信协议中建立起收发应答机制，同时加入序列号的目的是为了防止重复执行的问题出现。
ML_Network中RDP的内容长度是怎么进行区分的？
我们使用sizeof（）来测量一个结构体的长度，在解析完一个RDP后，返回一个长度，计算偏移量后确定是否还要继续或者退出解析。在早期的版本中，我们有一个内容长度的指令来进行偏移，这一版本中我们去掉了，主要是用时间来换空间。提高数据包的利用率。
ML_Network中的RDP的结构内容是怎么划分的？
Typedef struct
{
U8 ioSwitch :1;
U8 ioRelay :1;
}is_xxxio_rdp;
Typedef struct
{
U8 key;
U8 (*fun)(u8 *inBuf);
}is_xxxFun;
Typedef struct
{
U8 classID;
U8 indexID;
//U8 index ;
//U8 *struct;
}gs_Rdp;
按照上面的结构，我们将每一个RDP里面的放置一个KEY，以便程序快速的查找相关的RDP协议指令。
在ML_Network中我们将如何让设备进行相关的注册和通信控制？
关于注册：
在ML_Network中，如果一个设备想要控制另一个设备，必须将自己的类别和序列加入到gs_Rdp中，以便获得相关的许可。
关于控制：
接收方对比了许可buf后，会判断是否可以进行相关的操作，如果可以则会根据接收类别码跳转到指定的协议构架函数中，通过调用is_xxxFun结构体的函数和key来找到合适的解析函数。
在完成解析函数的查找后，会进行相关的控制指令操作，并随后对该数据包进行应答操作。
我该如何获取ML_Network 协议解析源码？
关注我司微信公众号（扬州梓元节能：yzzyjn）并在公众号中回复自己的收件人邮箱号后我们将在第一时间内将相关的源码发送到您指定的邮箱中，我们期望与您合作，共同将ML_Network生态系统建立起来，实现对设备的互联互通！
第三章 设备注册
对于一个系统级别的产品，因为其数量相对庞大。我们需要使用一个统一的编码规则来进行相关类别设备的管理工作。
在本协议中，允许存在的类别数量为256种。下面按照一定的规则来进行相关设备编码的说明。
项目名称
空间大小
备注
厂标
2byte
用于识别是哪一家企业生产的
代理区域
3byte
厂家对于设备进行区域控货管理使用
物料类别码
1byte
用于确认设备所属的类别，建立起基础的产品分类
物料细分码
2byte
各厂家自定义区域，用于对软硬件版本号的识别或做它用
产品流水
4byte
各厂家生产流水号
防伪码
8byte
该区域可以和315网站联动或厂家自建防伪编码规则
建立起这样的注册编码原因是为了实现对厂家产品的精确管理。实现对生产厂家和代理商的管理工作。
为什么要建立厂标？
对于ML_Network 我们最终会将其联网管理，我们的主机在未来将具备远程升级的能力！我们可以根据厂家的编码去寻找对应的新版本驱动文件进而实现对ML_Network中的设备精确控制与管理。
建立该标识也是为了后面的验证与防伪工作。我们希望在这个系统里的每一个成员都能够和睦的相处。并且通过大数据清楚的知道什么类别的设备用户使用频次最高，用户的使用习惯行为是怎么样的，进而有针对性的进行研发工作。
为什么有代理区域码？
建立这个代理区域码的目的是为了实现对代理商的控货管理。同时可以根据平台反馈回来的数据进行区别实现对各个区域间的差别化分析，以便有目的性的进行研发与推广作业。
为什么有物料类别码？
建立该物料类别码的目的是为了实现设备在联网注册时可以快速的找到对应的解析程序。同时也用于规范各个厂家间的基础功能版本。
为什么有物料细分码？
建立物料细分码的目的是为了方便各个厂家对于自身产品的软硬件版本管理，维护人员快速找到问题的原因及提供及时的维护建议。
为什么有产品流水？
建立该流水号的目的是为了厂家实现对产品的溯源管理，通过流水可以查找产品的是什么时候由谁生产或质检出来的。进而有针对性的进行产品品质的管理工作。
为什么有防伪码？
我们不想自己的系统被别人无情的山寨，我们希望通过联网的方式，当设备注册的时候通过互联网将防伪码发送到各个厂家的平台上，有各个厂家来授权是否通过验证。使用这样的方式是为了实现ML_Network 的健康发展，我们从内部建立起属于自己的产品品控体系。为自己的生态系统建立一个有效的保障与管理机制。MicrosoftInternetExplorer402DocumentNotSpecified7.8 磅Normal0
第三章 设备注册
对于一个系统级别的产品，因为其数量相对庞大。我们需要使用一个统一的编码规则来进行相关类别设备的管理工作。
在本协议中，允许存在的类别数量为256种。下面按照一定的规则来进行相关设备编码的说明。
项目名称
空间大小
备注
厂标
2byte
用于识别是哪一家企业生产的
代理区域
3byte
厂家对于设备进行区域控货管理使用
物料类别码
1byte
用于确认设备所属的类别，建立起基础的产品分类
物料细分码
2byte
各厂家自定义区域，用于对软硬件版本号的识别或做它用
产品流水
4byte
各厂家生产流水号
防伪码
8byte
该区域可以和315网站联动或厂家自建防伪编码规则
建立起这样的注册编码原因是为了实现对厂家产品的精确管理。实现对生产厂家和代理商的管理工作。
为什么要建立厂标？
对于ML_Network 我们最终会将其联网管理，我们的主机在未来将具备远程升级的能力！我们可以根据厂家的编码去寻找对应的新版本驱动文件进而实现对ML_Network中的设备精确控制与管理。
建立该标识也是为了后面的验证与防伪工作。我们希望在这个系统里的每一个成员都能够和睦的相处。并且通过大数据清楚的知道什么类别的设备用户使用频次最高，用户的使用习惯行为是怎么样的，进而有针对性的进行研发工作。
为什么有代理区域码？
建立这个代理区域码的目的是为了实现对代理商的控货管理。同时可以根据平台反馈回来的数据进行区别实现对各个区域间的差别化分析，以便有目的性的进行研发与推广作业。
为什么有物料类别码？
建立该物料类别码的目的是为了实现设备在联网注册时可以快速的找到对应的解析程序。同时也用于规范各个厂家间的基础功能版本。
为什么有物料细分码？
建立物料细分码的目的是为了方便各个厂家对于自身产品的软硬件版本管理，维护人员快速找到问题的原因及提供及时的维护建议。
为什么有产品流水？
建立该流水号的目的是为了厂家实现对产品的溯源管理，通过流水可以查找产品的是什么时候由谁生产或质检出来的。进而有针对性的进行产品品质的管理工作。
为什么有防伪码？
我们不想自己的系统被别人无情的山寨，我们希望通过联网的方式，当设备注册的时候通过互联网将防伪码发送到各个厂家的平台上，有各个厂家来授权是否通过验证。使用这样的方式是为了实现ML_Network 的健康发展，我们从内部建立起属于自己的产品品控体系。为自己的生态系统建立一个有效的保障与管理机制。
第三章 设备注册实现方法
为了实现对从设备的注册管理，我们需要建立起类似FAT文件系统来实现对文件的读取与写入操作。系统注册文件按照固定的格式来进行划分，在先阶段一个数据块划分出14个设备ID，第一个字节用于表示所属类别，第二字节用于表示本系统中该类设备总量，第三个字节为相关详细的ID，其中00表示无意义，一个块的最后一个字节用来表示下一个链表的偏移地址。
为了实现对设备的管理，我们需要在本机里面做好记录，以便主机可以快速的查找到对应的设备ID号，在通信的阶段我们将使用本机的设备ID来设置通信地址，从设备使用主机加从设备分配ID来构建一个通信ID，主机通过这个ID来和从设备通信，从设备使用主机+0xff来和主设备通信。
设备间的通信采用双向应答的方式来进行。
在ML_Network的初始阶段，我们采用的最基本的方案来实现，在本模块中仅实现了对设备的注册和注销管理，并不对设备的合法性进行检验并对设备的原始数据进行读取。
为什么ML_Network 使用两个不同的设备ID来进行通信？
我们使用RFID来进行通信，为了降低各个联网设备的通信压力，并保证数据传输的可靠性，固我们对每一个设备都分配了一个独立的ID号，本机在默认情况下仅监听该ID号的数据。如果一方需要对另一方通信，则需要找到对方的ID号来进行通信，在完成发送后需要切换到本机的ID号进行监听。
ML_Network 如何实现数据交互？
1、发起方主动发起数据，确认发送成功；
2、发起方切换模式进入接收状态；
3、接收方解析数据包并生成相关的应答数据包；
4、接收方切换为发送模式，将数据包发送成功。接收放并不会使用自动重发机制，有发起方通过软件协议自行确定。
ML_Network 中的ID号是该如何进行解析？
我们使用16位的设备ID号来进行数据传输，分为4个区位，15-8位地址码，用于在组网中来使用蚂蚁算法快速的找到通信的设备位置坐标，7-4位主设备ID号，3-1为从设备ID号。在这种配置模式下，一个主设备可以管理15个执行和或传感器。一个路由设备可以管理同时管理6个主设备。在一个系统里面最大允许存在254个路由设备。00xx为空地址。Ffxx为系统主控设备。
在这样的体系构架下面，如果仅使用多个主控设备可以彼此相互通信来实现传感器的互联，实现对运动传感器的误动作排除和或通过主控设备来桥接，对非本主控设备的管理。
我该如何获得ML_Network 的注册和注销源码？
关注我司微信公众号（扬州梓元节能：yzzyjn）并在公众号中回复自己的收件人邮箱号后我们将在第一时间内将相关的源码发送到您指定的邮箱中，我们期望与您合作，共同将ML_Network生态系统建立起来，实现对设备的互联互通！
ML_Network 事件处理机制
对于常规的控制逻辑而言，在我的映像中应该有两种情况，一种是基于时间的事件，比如什么时间做什么事情，我们可以当做闹钟来处理。另一个是标志事件，比如：天冷了请注意保暖。拆分来看，天冷是标志，请注意保暖是一个通知事件。对于闹钟事件，百度百科给出的定义是：既能指示时间，又能按人们预定的时刻发出音响信号或其他信号。我们可以简单的认为在什么时候做什么事情。
对于一个闹钟事件状态机而言，我们需要定义的内容如下：
1、告诉设备我需要安排一个事情：什么时间、什么周期
2、告诉设备如果运行到这个时间点了，我们该处理什么事情。
3、如果我不想这个时间按照计划发生了，如何取消。
对于一个周期性的事件而言，我们首先需要思考的是这样一个事件的大体描述是怎么样的？比如在我们的应用中会有提示音事件，我们需要提示音在运行到我们设定的时间后就自动的取消掉。又或者是按键扫描事件，我们需要以固定的频率来进行轮询，不间断来进行进行操作。对于这类OPM 单触发模式的事件而言，我们需要设定的内容很少：
1、给我安排了一个什么样的事情
2、这个事件大约需要执行多久才可以取消
对于一个时间范围事件，我们需要设定的在什么样的时间尺度下进行观察和在什么样的时间周期中进行观察。其次是如果这个时间范围合适，我们该做什么事情。对于这样的一个事件我们需要设定的内容如下：
1、事件开始的时间：
2、事件结束的时间：
3、时间的参考标准是：1、系统时钟；2、RTC时钟；
4、什么事件。
5、取消该事件的办法。
标志事件的处理办法。
抽 象的描述这个事件其实很简单，比如：天黑开灯。对于我们而言，我们从没有必要考虑事件的反面该如何处理，不是不考虑，只是我们没有必要把任何一个事情都认 为只有两面，不是正就是反。其实在事件的处理过程中我们可能需要面对的事情要比这个复杂很多。对于一个标志事件我们需要考虑的的内容可以分为如下几个部 分：如上所述，如果天黑我们是否要一直都保存灯亮，还是我们只是在天黑的那一刻开灯即可。这本身就是一个很复杂的逻辑。
对于标志事件，我们在很多情况下处理的是OPM（单脉冲）模式，只是在事件发生的那一刻执行一次即可。但也有可能需要连续的保持，比如处理报警类事件时，如果事件没有正确的处理，我们将需要将事件长时间的保持。
对于OPM模式的事件：
我们需要处理的内容如下：
1、对事件标志位使用情况进行初始化并在将该事件绑定在对应的标志位上；
2、做出一个合适的接口来使外界来触发该事件发生；
3、做出一个接口来使外界取消该事件的发生。
对于长时间维持事件，我们需要在标志位没有清除前始终保证该事件的可靠运行。相对于OPM的模式，我们在执行完一次该事件后我们不会立即清楚掉标志而是继续保持该标志，直到其他事件将该标志位清除为止。
对 于采用事件标志位的方式来进行控制，在没有跑系统的程序中可能是一种浪费，因为如事件的执行本身没有长时间过程的话，完全可以直接调用而不用进行复杂的关 联操作。使用信号的方式来进行处理的目的主要是为了方便控制逻辑层的编写。将执行成与业务成分离有助于后期的扩展和或方便快速的对指令的本身做出应答。Make devices running at right ,make your life better!
|
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
淘帖
顶
踩
