We can all agree that the PCB manufacturing industry has needed a robust real-time, comprehensive shop-floor communication standard for many years. The most useful standard would include detailed bidirectional machine-to-machine communication as well as shop-floor to IT computerization communication. Now, finally, a solution is available: the Open Manufacturing Language (OML). It is an open communications specification managed through a community of industry members and designed to support the evolving Internet of Manufacturing. OML makes vendor/platform-independent, normalized data accessible across the entire shop-floor, opening up the potential for Industry 4.0 and Smart Factory 1.0 solutions. Although it has and is being originally developed by Mentor Graphics, the specification is free and has no proprietary restrictions on use and further development.
How OML Fits Into a Modern Factory
OML can be applied from even the lowliest of processes on the shop-floor to the largest enterprise IT systems and production-support infrastructures. OML simplifies the integration of IT systems with factory equipment and processes, allowing the use of a rich variety of reliable, real-time data. With OML, factories can not only collect and exchange data between processes and systems, but they are also able to control processes and even entire lines through commands from computerized systems, a key factor of Industry 4.0.
OML provides a common data language between all systems, avoiding the need for changes and reducing the risk of these post-development integration side effects. It also makes sure that in so doing that every user of the data sees the exact same view of the data, with all of the data normalized in the same way. This enables different areas of production and production support operations to work together with a common view of any issues or requirements that may arise, avoiding operational conflict. The OML specification supports the protection of sensitive data, such as customer or business specific data elements that should not be openly available.
OML can be applied from even the lowliest of processes on the shop-floor to the largest enterprise IT systems and production-support infrastructures.
The Building Blocks of OML
OML is message-based. A message is simply a parcel or packet of data exchanged across the network. OML messages are exchanged using a simple protocol. OML supports several communication patterns using the protocol.
Applications can subscribe or listen to specific OML events and receive them in real-time from the factory floor. For example, an OML event provides the current production status of equipment.
Events provide for “loosely coupled” system architectures, meaning that one part of the system is not tightly dependant on another part. A loose coupling is generally favored because it allows the whole system to be more flexible to change and easier to maintain.
OML events also provide reliable delivery by using an acknowledgement from applications. If an application does not respond, OML ensures the event is not lost and is either sent again later, or in a worst case, a recovery can be made.
OML request/response messages provide OML applications with real-time control of equipment or processes at the shop-floor. These messages are bidirectional. Control can be initiated by the OML application toward an OML process on the shop-floor; for example, specific equipment or lines can be stopped. Control can also be initiated from the OML shop-floor process toward an OML application. For example, the shop-floor process can check if a specific PCB is allowed to enter specific equipment every time a PCB enters the process.
The protocol to exchange OML messages is the Transmission Control Protocol (TCP). OML messages are exchanged with standard network sockets. TCP is the underlying protocol of many Internet applications. TCP is a mature, open standard with support for creating the communication sockets available across all major programming languages and platforms. TCP also meets the low-level performance and reliability requirements of OML.
Software Development Kits
A software development kit (SDK) enables a software developer to work more effectively with specific platforms and development environments. SDKs are already available for OML. For example, using the .NET platform from Microsoft, a developer using the popular Visual Studio IDE can simply reference an OML .NET assembly, and within a few lines of programming code, immediately start to communicate with any other OML-based applications in the factory. SDKs are also available that support the popular Maven build system for Java. These SDKs typically provide real working sample application code and OML simulator environments. A good SDK will allow software developers to focus their time on building the value-added logic for their application, safe in the knowledge that the SDK is managing the OML communication layer.
Applications for OML
OML represents a low barrier to entry for applications that require the use of real-time data acquired from both automated machines and manual processes. Existing solutions can be enhanced and new solutions created, for which the return on investment can be compelling. The following are some simple examples that illustrate the scope of the usage of the OML specification.
The role of a dashboard is to bring a continuous summary of key points about the operation into a single simple display that can alert even the casual observer to issues that require attention. The measurement of effectiveness of a dashboard is to have accurate and timely information. Accuracy of data has historically been a huge challenge, at least when pushed beyond the most simple of parameters. For example, a count of the number of PCBs passing through each process may be an easy parameter to measure across the whole shop-floor through the use of sensors and then report using a dashboard. However, without OML, it is exceptionally difficult for the real use of data from each of the various machines and processes to include such things as peak and average production rate, minimum cycle time, stop events with reason and duration, production modes such as changeovers, pass and fails, top 10 defect list, production WIP bottlenecks, first-pass yield, repair cycle counts by PCB, etc., with like-for-like comparison of data in different formats and protocols.
At each production process location, standard OML is typically provided by a dedicated producer application. This makes the data available continuously to any OML application that requires it; in this case, the example OML dashboard web app shown in Figure 1. Development of the web app is simple because it only needs to work with one language, OML. The scope for the content and analysis is huge because data can be coming from literally any production process to be capable of supporting many useful KPIs. OML producer applications can be developed for each type of process location using the specifications of OML. The data most often used for dashboards is a record of events so that whenever anything happens on a machine or process, it is communicated to the OML dashboard app, from which current status and historical trends can then be reported.
The principle of poka-yoke control is to ensure that processes are not allowed to operate where it is known that the operation is likely to result in a defective or incomplete product. The reason for the OML stop controller to prevent the process from operating can come from several triggers, such as the needed materials were not set up and verified, the machine program was not confirmed, or a trend analysis of data from quality focused dashboards identified a high risk of an issue.
OML data can be used to enforce compliance of management practices, as well as being a part of process setup and active quality management systems.
OML can be used to record the events associated with the setup of materials. The assignment of materials to unique feeder IDs, as well as the staging of the feeders on to the SMT machines in the positions designated by the machine program, can all be recorded by the OML material verification controller by collecting all of the appropriate OML events. After the completion of the material setup, information about the consumption of materials and any spoilage can be read from the machine, then fed to ERP.
This information can be used by a factory-wide computerization to supply materials to the various machines and processes when needed, rather than pushing all materials out in advance. The reduction in the need for advance materials is possible through the visibility of the actual material consumption and spoilage for each reel to automatically ensure the accurate inventory record of physical stock against the ERP database and eliminate unexpected internal shortages.
As an extension to the previous example, the setup confirmation of materials, plus the gathering of material consumption data from the machines, provides the opportunity for materials traceability. An OML trace adapter service can collect information into a database to create a clear record of material allocation that has been used on a lot, job, or work-order basis.
Adding in an additional piece of information, the reading of a unique serial number from each PCB as it enters each process, the information can be refined to provide more exact traceability for each PCB. The OML trace adaptor service can easily put together event records for each PCB as it passes through each of the shop-floor production processes to create a complete product build record of materials used.
The use of a unique PCB-ID when read at each process can also be used by another OML control for routing. A primary function is to confirm that, as each PCB arrives at each process, the process has been correctly set up and the process is the correct next process for the operation of that PCB. This prevents the omission of a process or even the duplication of processes. The routing control can also be used to manage repair loops so that any PCBs that have failed a test process cannot pass to the next planned operation until they have been inspected, repaired, and re-tested. Routing control can use the same bidirectional capabilities as poka-yoke to enforce the routing decisions.
In addition to the control of the routing, OML routing control can be used to monitor and report the number of PCBs between processes, as well as record the times for which each PCB has been in any process or has been between each process. Analysis can be performed on the shop-floor product flow to expose any bottlenecks, which can be a key indicator on the OML dashboard.
Closed-Loop Line Control
A final example of the many more applications for which OML can be used is closed-loop control on a production line. Information can be taken using OML from an automated inspection process and can then be analyzed by an OML closed-loop analysis solution. For example, if an inspection was made on each PCB by an automated visual inspection (AOI) machine, the drift of placements made as measured by their x and y position, as well as rotation, can be calculated as a trend, and processed through a 6-Sigma algorithm to identify at what point the trend is out of control that a defect might soon be made.
The result of the analysis could be a message on the OML dashboard to say that attention is needed. Or, the OML interface can again be used to communicate back to the SMT machine that has been identified as being the cause of the drift to automatically modify program parameters and compensate for the trend, which allows production to continue without risk of defect.
With OML, any operation’s software development team can create computerization systems such as those suggested by Industry 4.0 and Smart Factory 1.0. The specification of OML is available to anyone free of charge when registering on the OML community website at:
BY MICHAEL FORD, SENIOR MARKET DEVELOPMENT MANAGER, AND DAN BAILEY, SENIOR SOFTWARE ENGINEER, MENTOR GRAPHICS