Bridging the enterprise

Tony Prylowski has applied his 20 years’ software experience to develop object oriented databases, which help find a way across the enterprise gap that exists between shop floor control and management systems.

Linking plant floor control systems to management information systems (MIS) and enterprise resource planning (ERP) systems has become the Holy Grail for many organisations who have aspirations of competing in the new e-business economies.

Improved efficiency, precise delivery times and lower manufacturing costs are achievable if this link can be established. The desire for such integration has been in existence in some quarters for the last two decades but the correct technologies and standards have never really existed to make this link happen.

Another inhibiting factor has been the cultural differences between the engineers who design the control and automation systems, and the systems analysts who have designed MIS and ERP systems. Neither has appreciated, nor has had the motivation to bridge the Enterprise Gap.

The Gap also exists technologically because control and automation systems are complex entities that are not easily mapped into the two dimensional rows and columns world of MIS and ERP systems. These systems are suited to this tabular structure since they incorporate relatively easily modelled systems such as sales orders, purchase orders, financial systems, and materials management all of which are of a transactional nature. ERP systems today do not have the ability to take information from a process and usefully present that in any of their modules.

The emergence of object technologies and products based on it are starting to alleviate the bridging of the Enterprise Gap, compared to legacy proprietary systems or relational database management systems.

Moore’s Law, which states that processor speed doubles every 18 months, is ever decreasing cost of memory devices combined with ever increasing capacity disk drives, allowing newer object based systems to thrive. Software functions and features are being developed quicker than ever before, because of the benefit of code reuse brought about by object design techniques.

Companies that designed proprietary systems in the 1980s did not have this abundance of technological arsenal at their disposal. Consequently they were reliant on the use of special file structures with compression techniques to squeeze large amounts of data onto, for instance, a 20MB hard drive. Decoding algorithms were therefore required to retrieve the data quickly, at times at the expense of the integrity of the data, something unacceptable in the pharmaceutical industry. These legacy systems do not coexist with the new object paradigm.

Another technology, which has failed to deliver the seamless integration of plant floor data to MIS or ERP systems, is relational database management systems (RDMS). Relational databases have rows and columns within a tabular structure. If the table is not large enough to accommodate the number of plant items being collected, then another table must be created.

As the number of tables increase, the joins between tables increase. When it comes to free form querying the database, performance degrades rapidly. This degradation in performance is exacerbated as the tables become larger within the database itself. Specialised tuning of the database is required and is not consistent with every application. In a typical relational database today there are up to 500 database tuning parameters to be considered when attempting to deploy such a solution. Relational Database Management Systems are not suited to the complex relationships and data structures that are prevalent in plant floor automation systems. SQL does not provide any standard time based query facility, which is fundamental in most production control systems.

The best way to address the Enterprise Gap is to use a completely object orientated strategy, ranging from object orientated standards such as OLE for process control (OPC), to an object orientated database management system (OODBMS) to collect and store all of the complex information in a plant.

The first object-orientated element to bridge the gap should be OPC, which in a short time has emerged as the standard that eliminates driver problems. In the past many companies used a lot of resources developing drivers to allow their hardware systems to communicate with software packages such as Scada systems. With the advent of OPC vendors supply an OPC Server for their piece of equipment, which means that any OPC client application can easily and seamlessly connect to that Server.

The second major technological advancement that helps bridge the Enterprise Gap is OODBMS, which provide a direct mapping of information from the plant floor to MIS and ERP systems. Complex data structures that may represent equipment or processes can easily be accommodated within an OODBMS. Direct relationships between objects can be easily declared at runtime avoiding the ‘join’ issue prevalent in RDMS.

Performance of OODBMS in the context of collecting and querying time-based information is significantly faster, because the information is stored in and appended to that object. One of the key aspects of any plant information database system is the ability to trace how products have progressed through the manufacturing process by virtue of a batch or lot ID.

In an object-orientated database where objects have the ability to have direct relationships with each other, it is easy to create complex models of a plant whereby the various process or equipment entities are treated as objects.

Equipment objects can be linked together to pass key data like batch ID from object to object in association with the actual process data. Querying is therefore an extremely simple and fast process.

Many OODBMS offer ODBC interfaces so that SQL queries and reporting tools may be used to interrogate the database. The mapping of object information into a tabular structure through ODBC can defeat the purpose of deploying an object-based solution.

To overcome this there is a specification within OPC called historical data access (HDA) that is a standard mechanism to extract historical type data from database management systems. Again this is using a purist object orientated approach that include the ability to do time based queries.