我们最近签订了合同,为检查过程自动化和集成数据收集。像许多系统一样,大部分数据已经由控制系统收集,然后由操作员手动记录并交给另一个人输入企业资源规划(ERP)系统。
作为我们解决方案的一部分,我们创建了一个数据结构,根据请求包括额外的数据,并为记录集创建了一个惟一标识符。然而,尽管人工数据收集过程多年来一直是准确的,自动化系统收集的数据却被报告为不准确。
最初,控制系统内的通信受到怀疑,但我们能够证明通信是可靠的。然后,我们的评估转向了收集数据的现有编程逻辑,我们发现的是“意大利面条代码”的教科书示例。看似简单的数据集成项目现在变成了代价高昂的重写。
编程方法和设计实践很重要;并非所有人生来都是平等的。好的实践不会凭空出现。在他的《专业软件开发》一书中,Steve McConnell指出了有效组织和无效组织的平均分布的期望。实际上,他观察到无效组织与有效组织的比例是10:1,他将此归功于有效软件开发实践的缓慢采用。
McConnell的观察和研究集中在软件开发社区,而不是控制和自动化。然而,多年来,可编程逻辑/自动化控制器(plc /PACs)已经融入了传统的软件开发能力。这包括对面向对象编程实践的某种程度的支持。在系统集成社区中,采用有效的软件开发实践同样缓慢。所有这些都在一定程度上导致了客户的怀疑:他们是否能指望任何地方的情况会更好。是的,他们可以,也应该。
有效的软件开发方法将结合某种程度的面向对象编程和抽象,既模块化又可伸缩。应用这些实践的程度是非常重要的,特别是在初始设计中。为了制定有代表性的工作范围,了解客户的目标和目的是很重要的。更高程度的抽象、模块化和可伸缩性将导致更多的设计时间,并反映在成本上。然而,未来的修订可能会随着时间的推移而发生,涉及的内容将会少得多。虽然这些实践是基础的,但并不是每个解决方案都必须在相同的程度上执行。
我们可以将这些原则应用到一个简单的虚构例子中:面包店的1号线。在设计阶段,mixer1被确定为一个模块。通过抽象,我们创建了一个通用的Mixer对象。我们考虑其他混合器,并寻找所有人共享的公共属性,包括启动、停止、前进、逆转、排放、混合时间等选项。函数仍然封装在对象中,而属性是公开的,可由程序逻辑调用。然后将对象命名为程序中的特定实例。
一个伪代码的例子:
Mixer1 =混合器对象
Mixer1。开始
Mixer1。MixTime = 40
Mixer1。放电
经过一段时间后,1号线被修改,包括一个额外的混合器,以处理增加的生产要求。有了已经定义的Mixer对象,处理修改就容易得多了。这说明了一定程度的可伸缩性。所有相同的属性现在都可用于mixer2。
Mixer2 = mixerobject
Mixer2。开始
Mixer2。MixTime = 20
Mixer2。放电
额外的功能也更容易处理;客户确定所需的停留时间。然后修改通用混合器对象以包括驻留时间属性,然后它对引用该对象的特定实例可用。
Mixer1。DwellTime = 10
Mixer2。DwellTime = 15
现实世界的解决方案要复杂得多,并且涉及到有助于项目整体成功的其他规程,其中定义良好的项目管理方法是必不可少的。这篇文章关注于软件开发的某些方面,这些方面同样适用于传统软件应用程序开发和现代控制解决方案的程序逻辑。
因为它是无形的,一个开发良好的软件设计过程的价值可能很容易被低估。但是一个糟糕的设计过程随着时间的推移可能会带来更大的成本。
拉里·阿舍(Larry Asher)是本科控制公司。的认证会员控制系统集成商协会.有关Bachelor Controls的更多信息,请访问其简介工业自动化交换.