物联网
每个工程项目在开发实作的过程中可能会受到诸多因素的制约,其中最主要的三大因素是效能、功耗和价格,人们通常需要对这些因素做出权衡和折衷。以这三个因素为顶点构成三角形,每个项目都有其「侧重点」,但根据产品、市场和时间会有不同的相对权重。
物联网(IoT)相关应用的潜在成长为供货商及其设计团队提供了新的机会,但也进一步扩大软硬件工程方面的挑战。硬件和软件密切相关,共同组成了平台,需要采取多种策略来最大程度地降低跨平台设计的复杂性。这些策略包括:
首先决定您的输入/输出需求是否采用固定或有限的数量和类型,或者是否需要扩展数量和提高类型的灵活性。这一决定会影响您对微控制器(MCU)和外部接口设备的选择。如果输入/输出不仅包含简单的低压数字点,还包括温度传感器、马达、甚至串行和并行格式的通讯线路,这一点就尤为关键。
很多情况下,独立于核心应用处理器的模块都具有重要意义。虽然高度整合的单芯片解决方案在电路板空间、功率和成本方面颇具吸引力,但倘若无线通信协议(protocol)、要求范围、甚至法规要求有任何的变化或扩展,都需要对设计进行重大改变,或者需要采用新的MCU和射频链路相关韧体。即便编码部分很简单(可能性不大),但MCU可能无法满足新的要求,而且需要升级,因此增加了开发时间和风险。
弄清楚选择的MCU在功率与效能矩阵中的正确位置。当您沿着所需效能的曲线往上移,将会遇到阈值点,因此不得不使用体积和功耗更大的MCU。当您沿着曲线下移时,所需资源减少,则可考虑使用体积小、功率低、价格便宜的MCU。
请确保所选的特定MCU支持各种复杂的速度、功能和功率模式,这样才能优化操作顺序,最大程度降低总能耗,应对需要大功耗的操作。
一些处理器具有专用的硬件嵌入特性,提供自动安全功能,并且不依赖任何应用软件,甚至所选的实时操作系统(RTOS)。这种方式可能会简化您所面对的安全挑战。如果您选的所有MCU都具有相同的嵌入式安全功能就更好了,因为无论选择哪一种处理器,都可以跨越物联网挑战中的这个重要部分。
随着对大小/效能要求的变化,需要对低功耗8/16位MCU进行标准化,然后采用不同的内存大小(片上内存或外部内存);也可采用一个较大的32位MCU,虽然在低阶应用时会浪费一些容量,但具有代码和驱动器一致的优势,同时还能简化物料清单(BOM)和测试过程。
在某些情况下,一台简单、低成本的单线程操作系统便已足够,但也有很多项目需要采用实时操作系统。无论采用哪一种操作系统,都需要对小型、中型和大型操作系统版本的可扩展性和可用性做出评估。必须了解清楚最小版本的大小及其相应的功能——您肯定不希望当项目完成80%时,在操作系统的能力「遇到瓶颈」。
在软件资源曲线上的一些关键点需要完成一些额外任务(开发时间,处理器资源),此时您必须做出以下选择,要么增加周边IC来为满载运作的MCU进行分流;要不选择一台指令周期更快的MCU。决策时,要分析何时需要一台功能更强大的MCU说明您将硬件任务交回软件,从而减少组件成本、电路板尺寸和功耗(原则上),但为此您可能要延长开发和除错(debug)时间。
使用「较轻的」物联网优化通讯协议,而不要选择基于客户端/服务器HTTP的因特网浏览器模型,这样可以将堆栈和处理要求减少二倍或以上,便于应对多台物联网设备及其接口设备。随着市场要求日趋严苛,还需考虑当连接要求(通讯协议、速度和完整性)提高时会发生什么情况。
这一点非常重要而且复杂,特别是当设计中包含无线应用时。如何非正式、然后正式地验证最终产品是否符合市场、技术、行业标准和法规要求,会产品影响「调整修复」周期和上市时间。如果要在产品中增加针对不同应用的功能,就需对原型测试程序或生产测试设置做出改变,这会增加工作量,同时增添不确定性和风险。采用经过许可的预认证(precertified)软硬件模块,可确保最终设计在许多方面的一致性和顺应性,但不是全部。如果有关设计和验证的任何高阶监管准则(如关于医疗产品可靠性的准则)影响到软件,都应该明了于心。如果这些准则不适用于所有产品,要清楚它们适用哪些产品。
所采用的软件技术和策略应能跨产品满足应用要求,并与物联网用户接口(如果有的话)匹配,例如防火墙、身份验证和密码。从分级列表中找出所需的安全资源,包括安全启动、身份验证、安全通讯、防火墙、篡改检测、事件报告、远程命令审查和策略管理,根据所拥有的软件资源,确保每一项的实际执行正确且可行。评估要提高各种产品的安全性是否必须采用更大或更快的MCU,制定计划验证实施的安全步骤是否可靠。
结论
随着新产品或附加产品的开发,「甜蜜点(sweet point)」无疑也需要相应地进行改变,以满足不断变化的要求,同时避免过度妥协。设计人员应纵观当前及未来的产品,选择适合的平台,尽量减少返工并提高重复利用率,确保上述变化不会对成本、进度或工作负荷造成不必要的影响。
全部0条评论
快来发表一下你的评论吧 !