Manufacturing Equipment System and CEP
I just finished a proof of concept for a manufacturing customer on how to use a inference engine to process events coming from a Manufacturing Equipment System. Without breaking any confidential information, I just want to highlight the use cases, the proposed architecture, and give some example of rules.
At the high level, the business use cases are real time fault detection and equipment monitoring. Equipments are tools running on the manufacturing floor. The manufacturing tools process parts. After a certain amount of work processed, a tool needs some maintenance and any parts assigned need to be inhibited so the MES can route these Work In Progress parts to equivalent tools.
Tool can generate alarms, and the system can take preventive action and/or alert people to avoid bigger problem. So for fault detection a rule looks like:
if Alarm_id == 36 then inhibit parts running on tool initiating the alarm, and send email and SMS message to floor manager
I have to complete this rule set with correlation, filter out and removing consequential alarms rules to avoid generating too much actions.
When {
alarm1: Alarm(category == TrackBlocked);
alarm2:Alarm(category == ScannerEmpty; equipmentId == alarm1.equipmentID; this != alarm1)
} then {
Retract alarm2;
}
For equipment monitoring, the manager wants to monitor limits of product to tool. Once thresholds are reached we can trigger a maintenance request on tool, and reroute parts scheduled to the tool. Events are sent at each job completion. Job means the processing of a manufactured part on a tool. At each event the rule engine updates counters, and verifies thresholds. If thresholds are met
The architecture has to integrate corba, and Java RMI.
The CEP server code is simple and uses JRules POJO rule session to insert events in working memory. The performance is to process 1 event per second, and manage a sliding window of one hour. (configurable). So the code is managing a sorted list of events and removes older events no more part of the time window. This is very simple and good enough for this simple event and time window management, as high volume and performance goals are far from what low latency CEP engines are used to process.
What is interesting on this project was the classification of the application as event based processing, and so entering into the CEP space, even if we are not really working on stream of events, or using any SQL like language or computing aggregation. This is a classical alarm filtering and correlation application where an inference engine can do a good job.
At the high level, the business use cases are real time fault detection and equipment monitoring. Equipments are tools running on the manufacturing floor. The manufacturing tools process parts. After a certain amount of work processed, a tool needs some maintenance and any parts assigned need to be inhibited so the MES can route these Work In Progress parts to equivalent tools.
Tool can generate alarms, and the system can take preventive action and/or alert people to avoid bigger problem. So for fault detection a rule looks like:
if Alarm_id == 36 then inhibit parts running on tool initiating the alarm, and send email and SMS message to floor manager
I have to complete this rule set with correlation, filter out and removing consequential alarms rules to avoid generating too much actions.
When {
alarm1: Alarm(category == TrackBlocked);
alarm2:Alarm(category == ScannerEmpty; equipmentId == alarm1.equipmentID; this != alarm1)
} then {
Retract alarm2;
}
For equipment monitoring, the manager wants to monitor limits of product to tool. Once thresholds are reached we can trigger a maintenance request on tool, and reroute parts scheduled to the tool. Events are sent at each job completion. Job means the processing of a manufactured part on a tool. At each event the rule engine updates counters, and verifies thresholds. If thresholds are met
The architecture has to integrate corba, and Java RMI.
The CEP server code is simple and uses JRules POJO rule session to insert events in working memory. The performance is to process 1 event per second, and manage a sliding window of one hour. (configurable). So the code is managing a sorted list of events and removes older events no more part of the time window. This is very simple and good enough for this simple event and time window management, as high volume and performance goals are far from what low latency CEP engines are used to process.
What is interesting on this project was the classification of the application as event based processing, and so entering into the CEP space, even if we are not really working on stream of events, or using any SQL like language or computing aggregation. This is a classical alarm filtering and correlation application where an inference engine can do a good job.
Comments