code
docs
tests
The process control and industrial automation industry has for decades been struggling with a large number of unreliable data points, such as sensors, fuses and potentially malfunctioning valves and actuators. This industry quickly developed the concept of Alarm Point as an abstraction for indication that something is not working correctly. These Alarm Points could then be grouped and aggregated, along a well-defined set of rules, to provide human operators a clear view of what is going on in a plant.
The enterprise software has always assumed a much more "reliable" environment where the computers either work or they don’t. Very little thought has been spent on what happens when many independent systems interact and what the consequences are to other systems when one fails. The Alarm Point concepts becomes a natural fit for the enterprise world of today, where Alarm Points allows for fine-grained notification and view into the health of one or more systems.
In Zest, we are building upon this powerful abstraction, from decades of field experience.
An Alarm Point is of an Alarm Class and of an Alarm Category. The Alarm Class defines the severity of the Alarm Point and the Alarm Category defines which part of the system it belongs to. Alarm Category can be extended by the developer, and the package contains the SimpleAlarmCategory as an example, where a Description property has been added.
An Alarm Point also has a System Name, which should be the subsystem or application name.
Alarm Points are triggered and an Alarm Trigger may cause the Alarm Status to change. IF, and only if, the Alarm Status changes, and Alarm Event is generated. The Alarm Model used for an Alarm Point defines which Alarm Status, Alarm Trigger and Alarm Event that are possible.
Alarm Points may also have user-defined properties. These are primarily used for reporting and auditing.
The Alarm Point is the central API for applications. Alarm Points are entities and normally dormant on in the Entity Store. The Alarm Point is a small workflow state-machine, and the Alarm Model associated with the Alarm Point defines the workflow.
Sometimes it is much more convenient to hold on to Alarm Points all the time, instead of reviving them from the Entity Store every time they are to be modified. Therefor, there is a convenience class available who does all the grunt work, called the Alarm Proxy. By creating an Alarm Proxy, all the UnitOfWork handling is done for you. You still need to provide an Identity of the Alarm, which must survive restarts. The code could look something like this;
@Service
private AlarmProxy.Factory factory;
private AlarmProxy myAlarmPoint;
[...snip...]
@Override
public void assemble( ModuleAssembly module )
throws AssemblyException
{
new AlarmSystemAssembler().assemble( module );
[...snip...]
myAlarmPoint = factory.create( "This Alarm Identity", "ProActiveCRM", "Sales", AlarmClass.B );
myAlarmPoint.history().maxSize().set( 20 );
[...snip...]
myAlarmPoint.activate();
The Zest™ Alarm library comes with 3 Alarm Models which should be sufficient for most uses. These are based on decades of experience from the industrial automation industry and user feedback.
The Simple Alarm Model is the most basic one, with only two Alarm Status, Normal and Activated. The only Alarm Triggers are activate and deactivate, where activate on a Normal status will bring it to Activated status and an Activated Alarm Event is generated.
| Old Status | Trigger | Event | New Status |
|---|