简介

   这是一款基于MCU+Android的硬件架构开发的二类医疗设备，这种架构有利于实现快速敏捷的开发，并且保持功能的稳定。

前述

   5月份从上海回来，稍微有空，然后接收一个朋友委托设计了一款医疗设备，然后在9月去深圳作了现场测试、验证，并且通过了EMC公司的摸底，所以设备基本上已经成型了。
         这是设备的正面：

这是设备的背面：
出于对朋友设备技术的保密的目的，我仅仅从以下几个大的方面大概的来谈谈本次研发的收获；

关于采用MCU+Android架构的原因：

   系统采取的是 Android板卡+MCU(Cortex-M3内核)来实现的，其中：
   Android负责UI界面操作、本地SQLite数据的保存；
   MCU负责具体的传感器(检测开关/光耦、气压、转速、用户物理按键)的检测/读取，各电机的调速/行程位置控制、电磁阀的控制等等；
   可以看到在这个系统架构中各部分负责自身最擅长的工作，之所以采用这样的组合是因为：
   (1)如果单纯地用Android开发所有的功能，则需要额外的在Android中实现大量的驱动，工作量很大，并且由于Android不是硬实时操作系统(诸如UCos、VMWare、FreeRtos)，对于电机的操作、控制的时间精度有限，时间片分配最大延迟的不确定性可能会导致很大的控制误差(从人工成本角度来看不划算、从实现效果的角度来看不理想)。
   (2)如果单纯地用MCU来开发所有的功能，则需要的基于MCU来进行界面开发，效率低下不说而且展示效果很差(8位黑白)；以前有些项目突发奇想地采用MCU+FPGA方式来实现(3X6bit)彩色界面，但展示效果依然无法与成熟的AndroidUI开发生态效果相比较，而且实现更加复杂、更新维护也更为困难。
   因此在采用MCU+Android以最高性价比(能取得的效果/开发工作量)实现产品的同时，MCU进一步通过通信(网口、串口等)监测Android部分APP是否正常工作，如果APP没有正常工作就通过预留的后台守护Service重启对应的APP；如果预留的后台守护Service也死掉，就采用复位流程对整个设备进行复位。
   从上家公司离职后的最近一年多手下没有啥人可以指挥了，委托这个项目的朋友也只能在机械结构上出力，而我这边负责了原理图/PCB的设计-打样-验证、MCU的编程、Android的编程、设备使用流程逻辑的完善以及设备通过EMC摸底能够在四个月内完成也是仰仗了采用上述硬件架构的好处，专门的部件集中于其专注的应用领域，只要把控好交互状态机的设计，就能很高效率地、很好地实现稳定(这个是基础)的功能表现。而且这种做法也广泛的在之前的产品(IOT数据采集基站<带本地显示和交互>、医用滴漏灌注设备<有交互界面>等)使用，总是一如既往的便捷、高效、便于维护、升级并且稳定。
   我以前项目接触过的其它一些平台:诸如ZYNQ(FPGA+ARM)的单芯片平台虽然可以实现更好的效果，但是支出(时间支出、硬件成本支出)都远远地高于上述架构，而且涉及到FPGA编程，这方面人才难以培养(是MCU编程人员培养成本的数倍)，一旦流失很难再招聘到合适的开发人员，就算招聘到开发人员然后熟悉开发业务也需要很长的时间，所以除非涉及到硬实时的大规模数据处理、或精确到0.1us级别的高精度控制，否则均不宜采用类似ZYNQ之类的炫技类作死方案。
   当然也有人执迷于采用MCU+Linux/Windows主机的方案，但从界面设计能达到的最好效果、开发敏捷度、以及开发效率等诸多角度来看QT、VB都是远远比不上Android来的快的。
   总之，我见过的除非已经达到触类旁通境界一些工程师除外(开放型工程师)，否则一些越有经验的人就越喜欢给自己画一个圈子，自己打死都不肯往圈子外走一步，别人不进这个圈子就鄙视、进了这圈子就蔑视(闭合型工程师)；熟不知真正合格开放型工程师应该根据设计产品/系统的需求去选取、学习更为合适的硬件方案、软件方案，而绝非偏安一隅、缘木求鱼。

关于医疗设备的一些内部应用逻辑的基本规则：

   凡是医疗设备就需要严格涉及两个功能方面：
   其一，正常功能的运行；其二，设备故障的检测；
即在设备使用传感器、开关输入数据的来运行正常功能的同时，还需要对传感器、开关与其备份传感器、开关进行比较来判断设备是否出现故障，但需要注意一个原则：
   1.自检的相位与工作的相位相分离；
   2.在工作相位中，即使功能代码、故障监测代码涉及到对同一传感器、开关的状态读取，也仍然需要将功能代码、故障监测代码放在两个独立的线程中运行(即使两种代码会重复地访问同一传感器的数据、同一开关的状态)，这样做有利于简化MCU程序的设计。

即在功能运行、实时故障监测之间保证严格的数据、逻辑隔离。

关于MCU与Android之间的数据同步

   在MCU+Android构建的产品系统中，MCU与Android之间有大量的数据需要同步，其中：
   MCU需要向Android传输数据类数据、故障类数据，在对应的Android页面中，数据类型数据仅在正常使用页面内进行更新、显示，而故障类数据则需要在所有的页面都启作用(即无论在任何页面只要出现故障都需要弹出窗口报错)；在之前各种MCU+Android的产品中，我们团队采用两种方案，这两种方案(方案1、方案2)适用的范围不同；
   其中方案1更早提出，适用于较小的、较为简单的项目适用；方案2提出的时间较晚，适用于较大的、较为复杂的项目；
方案1：

   方案1中每个页面提供static的方法由数据接收的Service调用，这个方案的好处是构建简单，在只有少数几个页面的情况下可以便捷的应用到项目中；但存在以下缺点：
   (1)需要在service中判断数据的流向，然后调用对应的static方法以同步数据到对应页面；
   (2)针对同样的数据请求，需要针对App当前所处的不同页面来调用不同的static方法，如果不恰当的调用未曾创建页面/或者已经销毁的页面，则会导致App的崩溃，程序的健壮性差。
方案2：

   方案2中所有的需要进行数据同步的页面都继承MyBroadcastReceiver接口，并在App切换到该页面(可能是创建该页面、也可能是从堆栈中恢复该页面)时，将本页面绑定到设备包装层的delegate，这样就自动的将数据传输的指向自动的随页面的切换衔接到不同的页面的onReceive()；不同页面的onReceive()依据自身页面的情况过滤对应的数据进行更新、响应，而直接忽略其不关心的数据，从而提高了App的健壮性；其缺点为需要额外的构造设备包装层，增加了一定代码量，适用于开发具有较多页面App。
   额外地，对于需要统一存储纪录的数据可以在设备包装层onReceive()中增加额外的通过率条件进行捕获，并存储入对应的SQLite表中。

关于快速过EMC的经验

   我总结的关于EMC至理名言：“如果你有一个优秀的结构设计师，你的EMC就过了一半”，用上面的这一句话来形容毫不为过。虽然作为一个擅长电路板设计、编程的工程师但却深刻地意识到一个合格的结构工程师对EMC的重要性；
   举个例子：较早的时候我们有一个血浆分离机的项目(项目方是国企改制的私有企业，老板是结构设计出身，但知识已经很过时了)，我们负责电路板、界面以及控制算法编程，对方负责结构的设计，为了外形的美观以及成本低廉(在空间足够的情况下)，对方采用塑料外壳内喷铜漆的方式来进行外壳屏蔽，这样由于塑料外壳开模较为廉价，可以获得较低的生产成本(对方设备基本上以成本价贩卖，依赖于耗材后续销售盈利)。但非常不幸的是，在辐射发射实验有好几个频率点都超限，在配合大量的内铺铜箔改善之后依然存在1、2点冗余非常少(大概只有3~5个dB)，后来对方老板毫不意外的没有雇佣一个结构工程师来重新设计结构，而最终“无奈地”采用丑陋的钣金外壳后就一次通过了。
   但明显地，根据我们后续地产品经验，其实最为合适的结构方案是钣金内胆壳外附塑料外壳的方案就能同时实现EMC性能和外形美观的目的，并且相对于金属铸造外壳成本也非常低廉。
另外的，除了遵守一般的板卡设计准则以外，在医疗设备的设计中更应该关心接出通信线缆；因为相对于板卡上可能产生的差分干扰信号以外，由通信线缆输出的共模信号会产生更大的辐射干扰，因为板卡上的电路回路的面积(等效天线发射面积，天线的发射功率正比于发射面积)通常只有数十平方毫米、或者至多数十平方厘米，而外接的通信线缆输出共模信号并通过大地、空间、电源线回路构成的发射面积可能达到数平方米乃至更高，这样，即使几uA的共模电流产生的辐射干扰都可能远远强于数mA差模电流产生的干扰。
   而解决这个问题的关键就是在外接通信接口采用差分信号线并增加共模电流抑制器件，并且保证线缆屏蔽外壳与设备壳体的良好搭接、良好搭接、良好搭接！
   以下是工程机阶段的演示视频，港真做可以扩展的多语言界面真的很累，诶…