Manufacturing execution system software

IS refers to the software packages and databases that provide the functionality to implement the business processes. These include such packages as Enterprise Resource Planning (ERP), Manufacturing Execution Systems (MES), Electronic Document Management Systems (EDMS) and Maintenance Management Systems. 

Manufacturing Execution System (MES) An MES is a manufacturing software application, not an MIS system. MES focuses on execution and management of production processes. MES provides synchronization of the following as they are used to make the product labor, machinery and equipment, tooling, other resources (e g., power, raw material, and work in process inventory). MES usually operates in time increments from sub-shift to real-time. MES applications can serve as interfaces between MRP scheduhng applications and machine controllers. They also collect quality and production data. 

At Argonne an IBM 704 operating system was constructed to increase the throughput and alleviate the saturated state of the machine at a time when funding for the next computer system was not yet in sight. At the time no operating system was available from the manufacturer and commercial software was virtually nonexistent. After a study of the few monitor or executive systems in use or under development at SHARE (the IBM 704 Users Group) installations in 1960, an early incomplete version of The... 

Although the traditional point of reference for safety interlock systems is a hard-wired implementation, a programmed implementation is an alternative. The potential for latent defects in software implementation is a definite concern. Another concern is that solid-state components are not guaranteed to fail to the safe state. The former is addressed by extensive testing the latter is addressed by manufacturer-supplied and/or user-supplied diagnostics that are routinely executed by the processor within the safety interlock system. Although issues must be addressed in programmable implementations, the hard-wired implementations are not perfect either. 

When a pilot system is used for validation, it is preferable to perform an IQ on the system to verify that it actually satisfies the hardware requirements of the software. If an IQ is not performed on this system, at a minimum the details of the hardware (manufacturer, model, serial numbers configuration) should be recorded as part of the OQ. There absolutely needs to be a record of the test bed hardware in case the validity of testing on the pilot hardware is called into question at a later date. Full OQ testing can then be performed on the pilot system. Execution of the OQ on a pilot system does not mean, however, that use of the final hardware systembecomes a plug-and-play affair. There still needs to be full confidence that the system performs in a satisfactory manner on the final hardware. 

Factory Acceptance Testing (FAT) is conducted within a simulated environment to demonstrate that the system meets the URS and FDS. The FAT will only be conducted if the software is a new development or major adaptation of the standard product. The FAT is the first opportunity for the pharmaceutical manufacturer to test the system in its entirety. The scope of the testing should be wide enough to ensure that most problems can be identified and rectified within the development enviromnent. Where tests are not dependent on the operating environment as, for example, in data entry validation, the FAT may serve as the validation record for that function. However, in order to adopt this approach, formal test specifications must be developed and approved prior to executing the tests, and results must be clearly recorded. 

The goal of this chapter was to show that a successful validation exercise, just like any other major project, must be built on sure foundations. Since validation involves documentation and testing of various kinds, the question arises as to whether this activity on its own is sufficient to demonstrate innate fitness for use. In the case where software forms a central part of the product being validated, such as a modern analytical instrument, manufacturing machine or other integrated software/hardware system, such activity is fundamentally limited to those parts of the code executed in the course of normal operation. This will often leave the majority of possible pathways through the code unexamined and bereft of the necessary evidence. 

Pulse Sequences. - A cross-platform development environment for NMR experiments (ODIN-Object-oriented Development INterface) was presented. It allows rapid prototyping of new pulse sequences and provides a common programming interface for different system types. With this object-oriented interface, the programmer is capable of writing applications to control an experiment that can be executed on different measurement devices, even from different manufacturers, without the need to modify the source code. Due to the clear design of the software, new pulse sequences can be created, tested, and executed within a short time. The software focuses mainly on NMR imaging, but can also be used with limitations for spectroscopic experiments. 

---