Unplanned Downtime Event Tracking

Downtime is the time an asset is unavailable to perform its function. This does apply to any technical asset regardless of its complexity. For manufacturing organizations, downtime is often more then jsut an inconvenience and often does translate directly into lost revenue.

When it does come to downtimes, there are two broad categories.

Category one is planned downtime. This is downtime caused by planned activities such as Maintenance, changeover, repairs, updates or other activates which require the asset to not operate.

These downtimes are required to ensure a save a reliable operation of the asset and are one of the processes which an organization has to combat the second category.

Unplanned downtimes are the second category and they are the bane of any production process.

Unplanned downtime is typically classified as an unexpected disruption or failure of an asset or process. It will increase costs, does threaten promised delivery of finished goods. On top, it often causes downstream problems that will magnify its consequences.

There can be a a wide range of reasons for unplanned downtime such as:

Therefore, manufacturing organizations always have a high interest in tracking these downtimes as a first step towards the achievable goal of reducing unplanned downtime.

A manufacturing company has five assets all controlled via PLC systems of different make and model.

Each asset has a signal which indicates the different states of the asset and is transmitted as an integer. Further does each asset include at least one additional signal which provides a reason code/ error code.

The company does us Litmus Edge for collecting data from the PLC controllers of their assets. Currently only one Litmus Edge is used to record the data of all five PLC controllers.

Using Litmus Production Record Database, the company has deployed a data model for recording downtime events. Recorded are beside the start and end date and time also the asset and the reason code / error code which was present at the time of the unplanned downtime. The event is identified by a combination of the asset, start time and reason code.

The raw data are all send a process tag to Litmus Production Record Database and the internal event monitoring capability is used, making it not necessary to deploy custom code onto each Litmus Edge.

An unplanned downtime is one of the integer values returned by each asset for its state. Therefore, for each asset a trigger is setup to monitor the state signal for the respective integer value. Once the trigger is true, the start time is recorded, together with the asset identification and the reason code / error code.

Some assets have additional signals which provide a sub category and are also recorded. Assets which do lack this signal, have this not recorded.

If the state of the asset does transition away from the unplanned downtime state, the event is closed and the end time recorded.

Further does the organization make use of a custom build query, which scans the recorded events and adds a human readable translation for the reason code / error codes in plain text to the event. This was custom build, as each asset has its own "translation" of what does which number stands for.

Also does the organization make use of a custom build solution on top of their data visualization system, which allows operators and shift supervisors to open a recorded event and add comments, as well as change the reason code / error code. This is useful, as the asset may report one problem as being the cause for the downtime, but later up on fixing the issue, it is identified by technicians that a differnet problem was the true root casue and the reported error was jsut a symptom.

As data are not overwritten in Litmus Production Record Database but appended as new occurrences, this provides a clear history of the event and can for example be used to work with the vendor of the asset to improve their own asset monitoring.

The picture below shows a graphical representation of the data model.

The orange box shows the Node Name and therefore the name of the Data Model.

This model does not make use of further hierarchy levels, as they are not adding to the event representation.

Green Boxes show Items recorded. The Purple boxes are the Item which are also the Identifier for a Downtime Event. These Identifiers are what users will typically use to retrieve the data.

Data Models can be created using the Litmus Solution Litmus Production Record Data Model Configurator.

The picture below shows, which tags have ben defined on Litmus Production Record Database to be used for both event trigger monitoring and as data for the recorded event.

The orange box represents the device, which is related to the devices defined on Litmus Edge, as Litmus Edge is the data source sending the data using the MSSQL integration and the flow provided by the Litmus Solution Litmus Production Record Tag Message Conversion Flow

The blue boxed represent the tag names while the green box is the item and the purple box the data type. All of the tags are defined as process data and not meta data.

Tags can be created on Litmus Production Record Database using the Litmus Solution Litmus Production Record Tag Configurator.

The picture below shows the two main events which are responsible for starting and ending a downtime event.

Every time the asset goes into an unplanned downtime, the event is recorded.

The human readable translation of the reason code and if available category code are inserted through a custom query which is scheduled to update every downtime event which has them missing.

Comments are provided by the operator through a custom application which allows to open a downtime event and add a comment.

The event monitoring configuration can be defined on Litmus Production Record Database using the Litmus Solution Litmus Production Record Internal Event Configurator.

The picture below shows how flexible the data recording for each event can be.

The last event, highlighted in red, shows how a user added an update to the reason and category, as the asset itself reported a problem with the hydraulic system. But when fixing the issue, it was discovered that it was a problem with the electronics.