15 April 2010
For many years, software product manufacturers have made their systems “open” in order to bolster access to their product and permit third party users to tailor the products to meet an ever-growing range of applications.To define an “open product” let’s first look at its opposite: a closed product. A closed product performs a specific task, in a specific way and is not accessible internally by the user. Therefore, the open product is one that can be used generally, in a manner defined by a user and permits full internal access. These statements define the extremes but in practice most products fall somewhere between the two. However, the expectation of a user is that an open product will offer great flexibility and allow them to fully meet their customer’s specification with one product. So just how “open” does a product need to be for this to be achieved?With today’s multi-tasking operators, customer specifications are calling for more and more integration of systems, especially in control room environments. The control room software has to be capable of handling a whole plethora of sub-systems and the resulting data types. These not only have their own unique way of interfacing with the control room staff, but also have different requirements to enable the system to be maintained and expanded in the future. Traditionally a control room was there to allow the operators to run production. This meant the control room software was designed to support production sub-systems such as controllers, I/O systems and PLCs. However, the data types found in CCTV and access control systems are quite different, as are the types of data coming from building controllers (HVAC) and Telemetry outstations. The more open the product the more of these data types it will be capable of handling directly.Likewise when it comes to data presentation, the product manufacturer will have provided the functions that most production systems require. But how do you allow the control room operator to define his favourite camera recording sequence, or to use a bizarre chart display? For that matter, what if you need to process some data using steam tables? An open product will allow for all these to be added by the user inside the product. They will then become an extension to the base functions accessible via the standard product menus, and hence configured and maintained inside the product framework using the supplied product tools.When it comes to long term system maintenance, often not done by the person who designed the original solution, the more open the product, the more access a designer will have to define the way it is used by others. A maintenance engineer can add another valve, or pump, or camera to the system at low risk and without the need to understand the intricacies of the original design. Likewise the same applies to any new third party company having to add a new type of sub-system. The ability for a product to be open enough to be configured from any external source, such as directly from a PLC configuration or a database, is of great cost benefit when it comes configuration and maintenance.So, if you are struggling to handle the functions, data types or the methods of operation or maintenance defined in your customer’s specifications, remember that a truly open software product will allow you to meet these needs more readily. I’ll leave you to judge just how open you now believe your favourite software product to be.
Print this page | E-mail this page
This isn't a paywall. It's a Freewall. We don't want to get in the way of what you came here for, so this will only take a few seconds.
Register Now