本文要点
- 如果将物联网项目看成是一种 IT 项目,那么注定会失败。
- 物联网项目需要三个完全不同群组的参与,分别是电气工程师、业务分析师和云开发人员。
- 设备板载是整个解决方案中的一个重要部分,它影响了项目的长期实施。
- 在物联网领域中,测试和持续集成可能会难以处理,它们在解决方案中给出了不同的工作原则。
- 对高质量的预生产或演示环境投入一些精力,它们有助于我们准确地模仿生产场景。
在向数字化转型的道路中,我们终将用到更多的互联事物。该新兴领域注重软件和数字体验,这意味着软件将会部署在更多的地方。物联网关注的是如何将资产和数据整合到现有的基础设施和系统中。为了满足客户对物联网解决方案的需求,Microsoft、Amazon 和 IBM 等服务供应商正在各自的云平台大量投资。而 Schneider、Mitsubishi 和 Siemens 等传统技术厂商也准备采取行动,计划融入到这一新的生态系统中。
我这几年来持续地参与了多个物联网项目。我意识到,客户需求与服务厂商所提供的服务间存在着很大差距。我并不是说服务提供商应该乃至可以解决所有的问题,而是尽量强调指出组织需要关注的一些领域。
第一个挑战:所有权
物联网在许多方面上与传统的企业集成类似。然而在两者间存在着一个非常显著的差异。平台集成最终是要服务于 IT 的,它几乎与业务无关(除非发生失败)。如果大家曾经参与过一些集成平台实施项目,那么就会明白我所要说的问题。要求企业赞助投资去实施 EAI 平台,这无疑具有挑战性的。因为平台并不会产生收入,难以展示如何可以节省成本。我并不是说不应该去做 EAI,只是指出平台的要求和优势是与 IT 相关的,而非与业务相关。
如果使用了物联网,那么事情就完全反过来了。一旦人们能认识到业务具有的所有优点,将会非常乐意赞助该项目。在 Axians IoT,我们通过召开一次仅针对业务的物联网研讨会解决了这个问题。研讨会由用户故事驱动,例如按使用付费、可预测的维护、设备编排等。所有的故事都分别写在卡片上,在卡片上还给出了描述、价值和风险。这样小组得到了一副牌,并在小组中讨论牌中的每张卡片,排定优先级,最终选定一张候选卡片去试行。这一方法已被证明是非常有效的,它可使每个人都参与其中,并成为产品的基石。
在研讨会中可以引入 IT,也应该引入 IT,但 IT 并非会上的主角。如果我们将物联网项目看作是一种 IT 项目,那么注定会产生失败。由 IT 驱动的物联网项目很少会取得成功。物联网项目需要与业务保持一致,并由业务驱动。其中,我们需要对如何增加收入或削减成本具有明确的认识。这就是说,其中必须涉及 IT 和 OT(操作技术,Operation Technology),以确保解决方案与现有的运行和维护过程相一致。
第二个挑战:技能集
在一个“正常”的 IT 项目中,各个资源(即开发人员,测试人员和操作人员)应对其他同行的领域具有很好的了解。有时,例如在 DevOps 中,同一资源甚至可能担当多个活跃的角色。
另一方面,物联网项目由三个截然不同的群组构成,也可以说是三种不同类型的人员组成。这些团体或角色往往不会去了解“另一面”。这并非像是十多年前 Java 和.Net 开发者间那样的水火不容,而是因为直到现在我们依然没有看到互通有无的任何好处,因此没有理由去这样做。
一方面,我们的电气工程师深入了解仪表、传感器、电阻、PLC、布线等所有的现场设备,对于任何我们想要控制或与之互动的机械、车辆或电气部件,他们也是专家。他们习惯于使用SCADA 这样的系统,专注于稳定性,仅将Raspberry PI 看成是一种可爱的小玩具。字节数组是他们唯一了解的数据格式,他们会将Float 看成是一种平常的数据类型,而事实上Float 并不是!他们无疑是核心人物,没有必要解释他们为什么在项目中是不可或缺的!
换一个角度看技能集,我们还有一些业务分析师。他们对业务有着深入的了解,并且对如何处理数据以及如何使用数据改变收入模式有着深刻的理解。处于这个位置的人,往往就是推动商业案例的人,而且他们也应该这样做。在他们看来,MS Excel 只是一种开发平台,虽然事实并非如此。他们喜欢使用Power BI。尽管他们可能不太熟悉一些领域,例如机器学习,但是他们很快就会熟悉这些领域。虽然Excel、机器学习和Power BI 似乎与其它类型的开发是密切相关的,但事实上并非如此。
最后让我们看一下云开发人员。尽管我十分想解释清楚,但是该角色十分模糊。在当前的场景下,云开发人员指的是那些精通网络、存储和集成的传统开发人员。如果这些工程师认为系统是稳定的,那么电器工程师会对此不屑一顾冷嘲热讽。尽管该角色称为云开发,但我认为,只要关注了诸如Node.js、Java 或.Net 等高级编程平台,就应将设备开发人员也包括在其中。如果项目考虑使用嵌入式系统和C 编程实现微控制器,那么设备开发人员可能与电气工程师更密切相关。
与其它任何项目一样,规划整个项目的发布和任务同样需要具有很好的领导和管理。但是考虑到各个群组具有完全不同的想法,我们需要做得更多。每个群组都必须主动去了解其它的群组。对于云开发人员来说,尤其应该这样做,因为他们与其它群组间交流存在一些不顺。云开发人员必须协调从业务/ 数据分析人员到电气工程师的需求,反之亦然。
第三个挑战:板载
在首次Sprint 时,Trello 面板上可能不会出现“如何配置设备”这一问题。当你意识到推出成百数千种设备的挑战时,我可以保证你会在同一块面板上碰壁。为满足你的需求,你可以也应该预先安装并配置设备,但是每个设备都或多或少地与其它设备类似,区分它们的是自动注册设备时所需要使用的信息。这些信息可以是MAC 地址、IMEI id、SIM 卡ID(ICCID)、证书,或是你所希望的任何组合。虽然你可以订购预先配置了密钥或证书的设备,但这往往是非常昂贵的。
但是在某些情况下,我们不需要大量板载设备,只需要在使用WiFi 的地点一次部署一个设备。物联网设备可以由技术人员安装在建筑物中,甚至可以由其中居住的居民安装。在这种情况下,我们可以考虑让设备提供一个WiFi 热点,任何人都可以使用智能手机现场配置设备。
无论使用哪种方式,板载是设备管理的一个重要组成部分,出于多种目的考虑应做分开部署,并以此作为整体解决方案的一个重要组成部分。除了管理配置过程的需求,我们可能还应考虑支持在某个时间点更换云服务提供商,或者支持从跨数据中心的灾难恢复。
在Axians,我们使用了microServiceBus.com。它支持Azure、AWS 和IBM 的物联网、跨数据中心的灾难恢复,并与Cisco Jasper 集成,为我们提供了使用SIM 卡的开箱即用的板载功能。它还支持使用MAC 地址及其他一些方式的白名单。
第四个挑战:规划更改
对于一个企业而言,部署Web 应用却不监视其运行状况,或者不修补其操作系统,这是不可以接受的。企业也不会漠不关心每台工作站和笔记本是否安装了更新的防病毒软件和防火墙。
不过出于某些原因,这看上去似乎与物联网解决方案毫不相关。人们似乎认为物联网设备能够抵御各种威胁,是运行在经得起时间考验的神奇操作系统之上的。事实并非如此!
无论大小和形状如何,设备和网关在本质上都是小型的计算机,它们的操作系统需要修补,还需要不断地更新的平台和自定义代码,以及我们所能想象到的更多依赖性。所有这些都是可以更改的。如果有人不承认这一点,那么我们大可以礼貌地点点头,然后就离开房间不再回来。
但是,设备管理不仅是远程更新和配置新设备。现有的IT 操作可能会使用System Center 或同类工具管理服务器和工作站。服务台和NOC 可能会使用像ServiceNow 或JIRA 这样的工具来升级问题、发现问题并计划发布。无论我们选择了哪种设备管理系统,都必须保持与现有流程的一致。一旦解决方案投入生产,没有人不希望面对的是一个没有人可以也不想管理的混乱系统。
除了板载之外,microServiceBus.com 还支持我们控制设备并配置更新,甚至是管理代码。它集成了ServiceNow,该工具是我们用于管理状况、问题和发布的工具。
第五个挑战:测试
对于从事各种类型应用开发的组织,测试驱动设计(TDD)和持续集成(CI)都得到了广泛的应用。但是,物联网解决方案的性质和体系结构,决定了这些测试方法是难以接受的。测试的目标是快速失败,为适应物联网的需求,我们需要跳出其中考虑问题。
为了更好地解释这些挑战,我将它们分成三类:
技能集和隔离
正如在“第二个挑战:技能集”一节中所介绍的,物联网项目通常包括三个群组,各个群组间是相互隔离的,分别具有不同的关注点、技能集,当然还有工具集。由于所做的测试是完全不同的,因此结果通常相互不符。
由于每个群组都与其它群组隔离,单元测试和模拟模型成为每个人日常生活的一部分。开发人员可能需要数个月的时间才能第一次看到PLC。而分析师则继续使用假设的数据结构,直到他们最终能看到一些真实数据。因此,我需要在此强调指出组间协商接口和文档化的重要性。
位置
物联网的分布式本质并不会简化测试过程,但是对测试和演示环境的访问的确十分有帮助。通常,企业不可能对站点设置创建副本,因为这往往需要耗费大量的设备、管道和电线,让原本整洁的办公环境一团糟。
尽管如此,我们还是要用心去创造一个很好的演示环境。不要在乎做适当的投资,要让演示闪亮美丽。假定演示并非是未来测试,而是要打动你的利益相关者。给出一个好的物联网演示,这无疑是最好的!
现场安装
我们都希望团队能拥有优秀的工程师,在设备站点或车辆上安装仪表、网关、通信和电缆。但是随着项目的推进,这些工程师可能不会继续去设置站点。此时通常是由一些不太熟练的人接手。他们对项目缺乏洞察力,也不了解企业所创造的价值观。
为了适应这种状况,我们需要给出安全可靠的安装指南和过程,常常需要给出多种语言的版本。安装指南必须经过测试!
结论
物联网驱动了大量人力物力的参与,并带来了新的机遇。但我们应确保以业务为驱动。考虑我们需要做的是什么,而不是我们能做什么。尽早给出对收益的估算,并确保向目标推进。
建立合伙关系,组建一支优秀的团队。无论人们身处何种角色和职责,鼓励他们分享自己的知识和经验。使用日常站会(Standup)建立人们间的合作,与整个团队一起规划项目,无论是长期的还是短期的。
考虑板载等现实挑战,并尽早在项目中分配任务。深入查看自身所面对的机会,并确保硬件符合要求。不要使用Raspberry Pi 或Arduino 这样的设备做概念验证。
对更改做出规划!确保选择一个可让我们远程控制设备的平台,不要把物联网设备与其它的IT 设备(如服务器,电话或工作站)区别对待。确保物联网设备始终与最新的固件、操作系统及其它软件保持同步。
参考
microServiceBus.com
microServiceBus.com®可管理 Microsoft Azure、Amazon AWS 和 IBM Bluemix 的物联网设备。该平台提供诸如部署自动化、设备调配、调试、实时跟踪和报告等服务。
AXIANS IoT Nordic
AXIANS IoT Nordic 致力于帮助中小型企业开展物联网领域业务。通过与其它 Vinci 组织的合作伙伴关系,Axians IoT Nordic 提供了一个完整的并且也是最具竞争力的端到端物联网服务,其中包括物联网设备管理即服务(Device Management as a Service)。AXIANS IoT Nordic 是 VINCI Energies 的一部分。
VINCI Energies
VINCI Energies 专注于快速推出在连接、性能、能源效率和数据上的新技术,支持数字化转型和能源转型这两大转变。VINCI Energies 是世界上最大的建筑公司之一。
作者简介
Mikael Håkansson 是 Axians IoT Nordic 的解决方案架构师和物联网专家。由于他对物联网社区所做出的贡献,使他赢得了 Microsoft 最有价值专家奖(Most Valuable Professional Award)。同时,他还参与了 Microsoft 技术顾问计划(Technical Advisor Program),并通过与 Azure 产品团队开展密切合作,服务于未来的版本和相关产品。他还投身于培训和各种演讲。
评论