The approach of this thesis

Component technology offers several benefits for vendors of process-management and process-control systems. Components provide interoperability, portability, and location transparency, enabling the development of coherent functionality on distributed platforms. The clear separation between interface and implementation, inherent in software components, has been traditionally characteristic of automation entities, as well. The function blocks within distributed control systems are connected to process inputs, outputs and to each other with messages, represented in the design as graphic signal wires. The compositions of function blocks make up automation modules, one for each control circuit. If the function blocks – and, more importantly, several upper level automation entities – are implemented as software components, they can be more flexibly composed together, into component systems or frameworks, which can be developed and deployed in parallel.

From the point of view of an end-user or a manufacturing company, component technology provides a means to capitalise on scale when customising application systems either by developing or by buying components to be used in several applications. This is

beneficial with user-interface components (ActiveX Controls or JavaBeans, for example) which can already be plugged into the user interface of a control or process management system. Components are also a way to make the user interfaces of automation and process management systems compatible with office automation and business information systems, based both on desktop and browser technologies.

Batch-manufacturing companies may also be interested in embedding strategic knowledge on products and production in special automation components. These domain or application-specific components can be developed in the manufacturing company. After testing, they can be integrated into a generic control or process management system by using the component interfaces of the system.

By composing components, manufacturing companies, system integrators and process- unit vendors are also able to develop larger functional entities than single components. They can develop domain-specific component frameworks and integrate them into control or process management systems. This requires, however, more development resources than component development and is normally not possible for a manufacturing company or a process unit vendor alone.

It seems thus possible that, in addition to the four component markets described in Chapter 9.2 (components and generic frameworks, tools, application systems, services), also a fifth market, that of domain-specific component frameworks may eventually emerge in the automation domain21. Specialised expertise in the control domain can be combined with software design technology, for example with design patterns, in developing and deploying reusable component frameworks.

The frameworks can then be marketed both to system integrators, process equipment vendors and manufacturing end-users in a business-to-business market. The market volume is relatively small but, on the other hand, the customers are, unlike in the consumer market discussed in Chapter 9.2, accustomed to paying well for productive solutions.

The providers of domain-specific component frameworks within automation, can also create new market opportunities, especially in cases in which the computational infrastructure and generic component functionality is already in use. The platform of the

21

There are already some early examples on this in the domain of telecommunications, most notably ACE (Schmidt, 1998).

framework of this thesis, the COM component model and the NT operating system is one example. EnterpriseJavaBeans is another, emerging platform. Furthermore, the end-user companies have to have specific needs, which cannot be fulfilled with traditional systems without compromising the business goals of the companies.

On the above premise, there seems to be potential in the batch control domain for software vendors, who would operate in the fifth, domain-specific framework market:

• To co-operate with system integrators in developing component frameworks (for example intelligent unit allocation or exceptional condition handling) which enhance a commercial system (for example InBatch, VisualBatch, or OpenBatch, discussed in Chapter 2). When commercial control systems gradually develop into a more software-component-based direction it will become easier to incorporate component-based frameworks in them.

• To co-operate with process equipment vendors in developing process unit specific (on the Unit Supervision and Process Control levels of functionality) frameworks. These could be marketed to end users as embedded parts of so- called intelligent process units.22

• To co-operate with technology-oriented manufacturing end users, the so-called early adopters, using both of the approaches above (developing enhancing frameworks or process unit specific frameworks). This could possibly also succeed in joint operation with a system integrator or process equipment vendor. As indicated above, the fifth market will be, in the beginning at least, a mixed software product and service market. The potential market volume and the correct timing for market entry has, of course, to be thoroughly investigated, and both the technical risks, discussed in Chapter 3.2, as well as business risks analysed and managed. The component technology provides, however, interesting opportunities to start in a small way, in a

22

The development from physical process unit vendors to equipment entity (see Chapter 2.2) vendors has been common long before the emergence of component technology which can, however, further intensify the development.

focused manner, and to first select the gains with high potential, as discussed in Chapter 9.2.

Batch process management has been appropriate as an example domain for the new experimental framework of this thesis, due to the relative familiarity of the process management (sub-)domain via the S88.01 (ISA, 1995) standard. Within Batch Process Management, the market potential is mainly in enhancing the existing systems, which have strong market positions.

It is, however, probable that process unit specific frameworks will prove to be commercially more significant in terms of new products and services. The reasons for this are:

• Several process unit vendors are already committed to making their process units truly autonomous, sometimes even intelligent (having local decision-making capabilities). Enclosing the control knowledge of a specific physical unit into a respective equipment entity may be a decisive competing factor for a process unit vendor.

• It is often beneficial, also, for manufacturing companies to encapsulate process knowledge, for example business critical recipes. Within pulp and paper industries, the recipes used in coating kitchens, are paper-grade-specific trade secrets, not to be exposed to control system or process unit vendors. Components and component frameworks also enable this kind of encapsulation.

• Unit Supervision component frameworks can be built on the basis of inexpensive solutions at Process Control level, because several control device and PLC vendors provide their solutions with OPC-servers (OPC, 1998).

• Component-based frameworks are easier to integrate into the new component- based upper level management execution (MES) as well as into enterprise resource planning (ERP) and management (ERM) systems than the conventional, non-component systems.

Multi-agency in the automation domain is useful when fulfilling the need to distribute knowledge and provide problem-specific decision-making capability. Which architectural concepts will be competitive is more difficult to anticipate. It seems possible that agentified component frameworks can take their place beside pure multi-agent systems. One reason for this is that the use of multi-agency is embedded, hidden in the framework.