前段时间和朋友聊我公司所从事的业务，其实每次将公司业务都挺难讲清楚，一方面大部分人对数字化没有概念，无论非行业内人员，还是行业内人员，另一方面，更主要的要是我们从事更是数字化转型中更为偏离普通用户的部分：数据采集。 我用了很多比喻，很多角度来解释，朋友都没有听明白，他一直在问我到底是什么样的业务。 这个其实真有点问住我了，我们从事的是什么样的业务呢？我一直强调我们其实更主要的在做非标业务，就是非标设备的数据采集，其实倒是也没这边简单。
所有的业务过程中都涉及设备、工具，我公司最主要的业务就是从设备、工具中用各种方式、方法来收集数据。所以也有朋友说我们做的就是别的大公司、或是正常公司都不愿意从事的业务，因为工作量大，废脑力，很吃经验，当然最主要的是：不赚钱。 这几个方面的，其实就很像非标业务。所以我也经常给别人说我是从事非标设备的数据采集。但是非标设备本身就具有定制化的特点，本来非标业务就已经很难被理解，而我们经常从事的就是在这种定制化的产品上再去建立定制化的数据业务，所以经常会面临无数据通讯协议、无数据接口、无程序源码的“三无”设备，然后我还在非标业务再叠一层更不懂的“数据采集”，所以导致能理解我们公司业务的也越来越少。 经常会遇到很多和我合作了好几年的，也会经常问我，你们能做什么业务，或是这个业务你们能做吗？
对很多业务相关、销售、或是从事某个行业的人来说，可能很难理解我一直说的非标业务的数据采集是什么，会不断的问我你们公司能做什么，这样他们要是能有相关的业务类型的时候，能帮我推荐一下，但是我每次解释完后，他们就更不懂了，感觉我们好像什么都能做，又好像什么业务都做不了，在行业内有句话就是：“如果你公司什么都能做，那就意味着你什么都做不了”，这句话我也十分同意。但是我的确是很难解释清楚。 我经常会有用各种我们曾做过的客户案例来解释我们能做什么。
我会说我们做过多个园区的空调集控，就是把好几个园区内的所有空调的数据，如：空调模式、运行状态、温度、风量等等进行采集，而且还可以对这些空调进行控制，例如控制空调的开关机、温度等等。有朋友就说：“哦，你们是做空调控制的”。但是实际上不是这样理解的，空调数据控制只是我们项目的一种实现而已，其实这个项目本质是想做什么？负荷控制。电力在用电高峰的时候，例如夏天最热和冬天最冷的时候，这时候整个发电能力已经跟不上用电的需求，电力负荷控制就通过技术和管理手段，对电力系统的用电负荷进行调节和优化，以实现电力供需平衡、保障电网安全稳定运行，核心目标是在发电能力与用电需求之间实现动态平衡，避免因负荷过高导致电网过载、频率波动或停电事故。所以这个项目可以被用在电力负荷调控系统、虚拟电厂等多种项目中。在这种业务模式中，我们项目可以作为其中“电力负荷调控”部分。 但是除了用在这种业务方向上，空调集控的系统还可以做节能。我有次和前同事聊天的时候，他就说这种应该是节能，我说出发点是负荷控制，但是的确节能也能走通，他说节能其实比较难走通，因为空调能调节空间其实没那么大。我说其实并不是，你想想，夏天的时候，大部分办公室经常会开在21度，甚至以下，其实调到23度，大部分时间也没特别的影响，但是从节能的角度来说，这点电能可是不少。 就这个我还特别写过一篇内容《空调集控。。。。。。。》。如果从这个角度来解释，是不是大家以为我做的是电能负荷控制里面的空调响应部分，但实际上这个只是我们做过的一个项目业务方向而已。
我还会给他们解释我们通过改造和实施，将一个泵站改造成无人值守泵站，并可以远程可以实现泵站的启动、停止、以及对泵站的内河、外河水位进行实时采集、检测和告警服务。同时为了保障运行安全，通过接入摄像头实现现场实时画面的监测。那这种系统解决的业务是什么呢？在长江等这种江河夏天进入汛期的时候，各地都会进入汛期响应。这时候泵站所值守的河道也会被纳入汛情监测的一环，需要实时上报。这时候这种无人值守泵站就通过数据的采集，实现汛期汛情的实时汇集，同时通过远程控制，也实现了汛情的及时响应。这时候的系统业务就主要是作为汛期联动系统的一个业务环节，在这种模式下，业务系统就是：汛期监测指挥平台的一个分系统。 另外，泵站对上的汛期监测的一个环节，但是在平时，都是作为农业生产最重要的一个工具。旱季的时候，通过开启泵站，实现河道农田的浇灌；雨季的时候，开启泵站，实现农田、居住地等的雨水排涝。这时候它实现的其实就是泵站的最主要用途：农田水利。这种业务方向就是将泵站作为一个独立系统，业务名一般是：无人泵站管控平台。
在现在流行的数字化产线业务中，对数字化产线的所有设备进行监测和控制，将相关的设备采集数据和生产信息进行关联，形成设备数据、生产信息数据的过程化监控。而生产信息一般和MES系统等生产系统相连接，所以通过对生产设备的监控即能生成MES的设备联动，也就是数字化产线。设备的监控部分逻辑其实也是数据采集的内容，常说的设备运行状态、设备的故障信息等，这些都是产线设备最基本的数据，重要的设备数据是可以支撑生产信息系统，或是可以辅助生产人员进行生产。设备的数据采集、监控部分其实就和我们所做的业务相关。在生产制造型的企业中，我们曾对多个企业的产线设备做数字改造，例如，对于机械加工类的企业，机械加工的工艺流程一般分为：原材料检验、原材料入库、原材料粗加工、精加工、零部件尺寸检验、表面处理、产品装配、成品检验几个工序，而其中粗加工中经常又包括：车床加工、铣床加工、CNC加工等；精加工包含CNC加工、线切割加工等工序；表面处理包括：氧化、着色、抛光等；装配包含：零件组装、激光打标等工序；这整个过程中，原材料检验很多厂就存在原材料数量多、规格多样等多种问题，这时候我们一般采用的是计算机视觉方案，如：对那种整箱的小件原材料零部件采用图像识别进行点数，然后对于每个原材料零部件采用拍照等手段是进行外观检测。粗加工、精加工中大量使用的车床、铣床、CNC等设备，这些设备都会直接联网采集数据，这些数据会一步步的关联到MES系统中相应的生产工序，这样直接记录了每个工序的工作量、工作时长，同时对每个加工的产品进行统计，必要的时候，在这其中的工序自动加入产品过程检验工序，多产品进行抽检。在最后零件组装成产品后，又会根据业务特点，有专门的设备对产品进行抽检或是全数检验，而这些检验报告、检验数据一样会直接进行采集和同步，作为生产过程的重要数据进行保存。 这样的业务，在不同的公司和项目中又有不同的名称，有些项目称为SCADA系统，有些称之为数据采集系统，在部分制造企业中，还会将这部分工作内容作为MES系统的一个扩展能力，称之为是产线设备数字化改造；对于我们来说其实做的是同一个业务。 不一定是这种产线业务，目前所有企业基本都会遵循流水线业务的思想，例如在航修业务中，业务一般会被分为：修理前故障检查、分解、清洗、故障检测、修理、装配、调整试验、检验、包装等工序步骤；在这整个业务过程中，我们依然会针对于每个工序特点，对相关的测试设备、修理设备进行数据采集，将数据和MES系统、LIMS等系统进行业务数据共享，对我们来说这种就还是数据采集业务的模式，这种业务系统在部分企业内被称为SCADA系统。 再例如在部分测试业务占极大比例的企业中，例如目前流行的航空航天企业，工程试车是其很重要的一个工序和业务，试车中涉及大量的试车数据，这些试车数据的采集和分析是试车业务的一个最重要的内容，我们也为曾为某些公司提供对这类业务中的设备进行数据采集，将数据采集汇集之后，为客户提供数据分析的工具和分析方法，客户可以在系统提供的分析方案的基础上通过分析工具自主进行进一部分分析，最后将分析后的数据映射到试车产品的相关部件中，这些数据整体提供给仿真工具，仿真工具就可以直接使用这些数据进行仿真分析，为工程试车提供有效的数据支撑。这种业务系统在很多企业中被称之为：TDM系统。
因为公司本身具有硬件研发的能力，对于硬件的对接，硬件数据采集平台化等方案已经精通，所以我们也曾想过将部分遇到的业务场景和需求产品化，作为公司产品对外销售，因此我们曾试水了母线槽测温产品、单导设备、采集工控机等产品，其中母线槽测温产品可以参考《母线槽测温产品》、《单导设备》。但是目前看来效果很不理想，主要原因看来是硬件产品销售的渠道和方式和项目技术服务类有很大的区别，我们对于这种销售场景并没有什么经验。但是我始终觉得这两个产品是我们在解决客户业务场景问题中很契合的两类产品，例如母线槽测温产品我们解决了母线槽测温产品中部署、安装的问题，为客户提供了一种极其方便安装、部署方案，在母线槽测温施工过程中至少减少90%以上的工作量；而单导设备中其实针对一种较为特殊的场景：信息数据安全场景。可能是这类场景业务空间太小，当时我在宣传产品的时候，很多朋友都在询问这东西具体干什么用的。这两类产品虽然没有推广出去，但是在我们很多项目中，我们都将其作为一种可选场景为客户提供更多的方案选择。
我经常这样不断的说各种行业的业务，各种案例，但是依然解释不了最简单的问题：我公司业务是什么？ 我每次只能说，其实我们是构建了一种模式、一个平台，可以对各种标准协议设备、非标设备的数据进行采集，这种方式并不是仅局限于一种行业、一种设备、或是一种业务中。例如，我们接入储能设备，就可以实现EMS；我们接入充电桩，就可以实现xx快充平台；在电网中，我们的业务系统就被称之为SCADA系统等等，所以行业内有没有我们相似的做的好的竞争对手，只能回答是：有很多，但是也没有。因为各个行业的做的比较好的业务系统头部企业都是我们的竞争者，但是我们特点就是不只是做这一个行业，这个行业只是我们为其提供数据的一个业务方向，这些业务方向在拿到底层的数据后，可以做各种的转换和业务方向方向。同理，我们也会因为各种业务方向，转换成多种的业务系统。 例如我们会做无人机相关的业务，在我们看来，无人机也是一个设备，对它的飞行数据、状态数据、画面数据进行采集，那属于是数据采集的范畴，对无人机的航线进行规划、给无人机下发任务单，让它执行飞行任务，这就是业务系统。我们通过对无人机的控制，上层业务平台实现巡检、应急、物流运输等业务系统。 再例如我们也会对很多工厂的设备进行改造或是采集，然后再依据其工厂的业务特点，再建立MOM系统为其提供业务支撑，这种参与的就是工业数字化转型以及多年来一直所说的工业4.0。 我后面有仔细思考过我们做的内容是什么，怎么更为准确的概括描述我们的业务，有一天我突然意识到，也许我这样介绍更为准确：人机协同。我们是提供多种手段，多种技术方案，将人和机器之间的协作更为顺畅、便捷，减轻人员对于这种重复、易出错的工作内容，还有些人工不便于抄录、无法频繁记录的数据进行采集，使用这些数据构建完整的业务流程，以便于实现整个业务的流畅性。 业务的流畅性我认为是人机协同的最终目标，同样也是我设计各种系统方案的追求目标，这种流畅性我个人将其概括为三个方面：业务的连续性、系统的无感性、数据持续性。
所有的业务活动，无论是生产活动、产品测试还是发货、销售等，每个业务到下一个业务，都可以按既定的工艺、顺序、职责进行。这种业务的连续性在绝大部分公司的生产经营活动中都有着明显的体现，不同的管理也是在促进这种业务的连续性。例如：当客户需要订购一批产品的时候，可以找公司的相关的销售人员，销售人员做产品的介绍；销售人员对于客户所关心的相关性能、指标等问题进行解答，客户满意后，客户开始签订合同。合同确认之后，客户按合同约定支付合同款，销售通知生产部门按合同约定的开始进行生产，生产部门管控整个生产过程，保障生产业务的连续性和产品质量；生产完成后，将产品交由仓储部门。当订单所有的产品都生产完成后，仓储部门将客户需要的产品进行装箱、打包，发给客户。这整个生产过程，从上一个工作内容，到下个一工作内容，都是可以找到承接部门和承接人，每个部门或是人员只需要完成自己工作职责，然后依据业务流程推动即可，就是大部分生产型公司的连续性业务。 相同的道理，在系统实现中，这种业务的流畅性就需要体现到系统中，客户咨询的时候，相关的问题、技术资料需要可以随时很方便的知悉；客户确认签合同的时候，公司合同模板会自动调出来，将咨询时候的客户信息进行组合，直接生成合同给客户签署；签完合同之后，合同直接流转到财务、法务那边确认，当客户按合同支付合同款后，生产会收到生产通知，合同的内容被拆解为生产产品，然后进入各个工序进行生产加工等等。这整个过程在系统实现中是连续的，现在一直所说的企业数字化改造，其本质也是这样业务流转的连续性。 回到人机协同方面，业务的连续性主要体现在生产过程中，生产订单进入系统之后，依据工序顺序，收到需要生产、加工的内容和数量，通过设备实现这个工序的生产和加工后，生产订单流转到下一个工序，然后再每个工序中，获取加工过程中设备的生产数据、加工数据，然后数据和每个工序关联。这个过程就实现了人机协同中业务的持续性。这个持续性就体现在：设备的数据、操作人员的生产数据是和业务流程关联的，通过业务的流程连续性，从而实现了人机协同数据的连续性。
在人机协同中的设计过程中，需要尽可能减少业务系统的操作，尤其是数据的录入。我曾在《系统设计原则》的内容中提到”若无必要，勿增实体“的简单性原则， 其实这里的系统无感性就是这种原则在具体业务场景中的一种落地实现。我们在人接协同的设计方案中，一定要尽可能减少系统的使用。以数字化工厂建设为例，很多厂商在数字化建设方案中，都会在MES系统、MOM系统等方案设计中，加入扫码功能，实现所谓的”一码流转“，这其实就是想要实现的系统的无感性操作，只是这种无感性操作大部分被实现成一个”鸡肋的便捷性应用“。我们就以这种很常见的扫码工序流转方案为例，很多系统设计的扫码工序流转，就是本工序的操作员在拿到上一工序的原料之后，打开MES系统，找到自己的工单模块，然后进行扫码，这时候工单会自动进行开工动作。其实我们仔细来想像这个过程，整个过程是否真的有必要进入系统、到工单模块再进行开工操作？绝大部分生产制造型的企业，流水线工位上就是做一个或是几个固定工序，在那边进入的物料、原料除了那几个工序，也不可能干的别的事情，这样进入系统就显得毫无必要。我们曾在一家制造型公司做产线改造的过程中，提出的方案就是用RFID的方案（因为那些物料基本为大件物料，扫码是个很费劲的工作，而且很可能码被遮挡，要想翻过来物料可能要借助工程设备）我们在这个工位的进料的产线边上安装了RFID的读取设备，物料在进入产线后，会自动被读取物料信息，然后直接依据物料信息做这个工序的开工，并统计生产数量等信息；同时开始采集加工设备的数据，将加工设备的数据和进入的物料数据进行关联，整个过程操作人员无需打开系统，也无需关注什么动作，依然还是没上系统前的操作方式，完成他的工序加工工作。只有当工序加工出现错误的，或是加工设备出现异常的时候，会在工位的操作电脑上弹出异常，要求人员针对异常信息进行补充说明，并且让员工确认是否需要更高一级的技术人员的协助。一个长期正常运行的产线，出现错误的可能性是很少的，所以我们的系统对绝大部分车间人员都是无感的，经常还以为我们系统是产线设备的功能，会打电话给我们让我们去看看他们产线设备出错了，让我们去看看设备。 这里需要特别说明的是：系统的无感性并非是全部强调全部使用全自动产线、机器人产线等方式，诚然，使用这种智能产线是实现系统无感性最佳的手段，也是很多方案喜欢推广智能产线方案，但是实际上很多企业没有能力建设这种智能产线；而且有很多行业业务特点决定了他们不能实现智能产线，这也是为什么我在人机协同的部分来讲系统的无感性的原因，如何在人机协同的业务中实现系统的无感性，是一个需要设计能力的事情。
数据的持续性是和业务连续性配合的内容，是对业务连续性的数据反馈。一个业务依据流程运行，数据会在每个业务活动中持续不停的产生，这些产生的数据应该随着业务流程的推动而形成的一种连续的数据，透过这些数据可以反推出业务活动的状态。在人机协同的业务场景中，这种持续的数据是反馈人机协同效果重要指标。现在企业大部分都采用流水线式的工作模式，这种流水线的连续性在数据上的反馈就应该是数据在随着人员操作、设备运行而呈现出一种持续、连绵不断的数据特征。以生产过程中的人机协同为例：当物料进入此道工序的时候，这道工序接收到物料之后，就应该是触发工序接收到物料的数据，这个数据应该被实时的反馈到人机协同的系统中；随着物料进入加工、生产，设备的实时生产、加工数据应该被采集并体现出来，这个数据有助于生产人员、管理人员及时确认设备状态、确定系统分析正常运行，依靠于这些数据，也能够实时的反馈出业务运行状态。这种设计方案如果配合以仿真能力和3D展示能力，就是数字孪生的应用方向。 这里特意强调数据的连续性作为人机协同的一个重要方向，就是因为还是在很多数据采集或是各种的人机协同业务设计方案中，很多方案为了降低开发难度和设计方案，会将系统设计为一种“结果提交”的方案，就是在对设备采集的过程中，会对设备的数据进行本地化存储，等到设备运行结束后，再通过人工或是自动的方式将其结果数据进行一次性反馈。这种方案在设备运行期间，除了操作人员之外，其他人员是无法获取到生产的数据情况，对于特殊行业的生产来说，工序的生产过程中可能会持续几个小时，这几个小时候其实就是处于一种生产监管的“真空地带”。如果缺乏数据的连续性仅仅带来的是“分段式的监控”，也许对于不要求实时性监管的行业影响还不算大，但是现在随着生产过程复杂度的提高，越来越多工序和生产过程需要多个生产单位、多个设备之间相互配合完成，这个过程就要求人机协同的过程并不只是一台设备、一个生产单位之间的沟通，而需要时集群式的配合、调度。其实这种思想已经在石油、化工、电力等这种自动化发展较早的领域已经广泛使用，PCS系统本质上就是用不同生产单位、设备的协同控制，只是这种是因为自动化的需求而产生的特定行业的实现。对于从企业层面来说，管控整个生产、制造、研发过程的这种“PCS”系统并未出现，但是我们在人机协同的设计中，提前将数据的持续性作为一种设计目标，实现企业层面的工艺、设备、生产单位协同才有实现的可能。
这一篇本来是在和朋友聊天的时候，他们很好奇我们一直做的业务内容，说是有机会帮我介绍介绍业务，但是每次介绍完后，他们都是一脸茫然，所以写本文用于公司业务的推广。后面说到是人机协同部分的内容，想着是将自己这些项目的经验做出一个经验方案的总结，也算是一种分享，由此这篇内容看上去好像是由两部分相关性并不强的内容组成。Aayway，希望这篇文章对于大家能有所启发。
