1. Overview
2. j5 System
3. Specific Requirements in the Power Industry
4. Power Use Case

j5 System

j5 is an Enterprise Application Interface (EAN) that addresses the needs of Power Sites in the area of critical data capture and analysis. The application is the market leader in Industrial Control Room Logbooks and is offered by many process control engineers such as Invensys and Aspen Technology and is used by hundreds of companies worldwide. (Examples are Calpine, GWF, Inland Energy, Siemens). The j5 system is a complete Power Logging System Package unlike home developed systems that use Excel, Wikis and general purpose database systems.

For more information on the j5 system, please see the St James Software Web Site at http://www.sjsoft.com.

Specific Requirements in the Power Industry

The Power Industry is unlike any other process control industry for a number of reasons:

• Power Sites are often heavily controlled by the regulatory bodies and must offer proof of compliance for a large number of their operations.
  
  This means that there is a high dependency on logging, audit information and reporting. Every log entered into the system must carry with it, a full auditing facility so that it is clear who made a change, what the change was and when the change occurred.
  
  There is also often a need to collect real-time information and store it within the logbook. This log information is particularly important at shift changeover.
  
  
  
  
  There is a need to store large amounts of information and to be able to store that information for many years. Because of this, the logging application must store the information in a standard relational database like Oracle or SQL Server and the application must also support various kinds of advanced queries like one-touch searches and advanced Boolean searches.
  
  To manage the regulatory requirements, there is a need for a powerful scripting facility which must also be controlled by an in-built scheduler.
  
  There is also a need for the system to enforce operational proceedures. This means that the system must either allow or inhibit different users from carrying out certain actions at defined critical times. For example, at the end of a shift, the supervisor is required to modify and approve the shift report and certain data entry points can only be modified by the supervisor.
  
  Having captured the data in the regulatory reports, the system must distribute the reports either via email (pdf, excel or html) or printed out on the system printers at the pre-defined time of the day. Often, too, special reports must be created and sent out when a critical event occurs.
  
  
  
  
  
• Often a Power Utility will comprise many different power stations in a wide geographical area. In cases like this, there is a central head office where a centralized management and support body is tasked to manage and control these many power stations.
  
  This puts a further demand on the Logging Software, since, although each power station is different in detail, the central body requires certain procedures to be enforced in a uniform manner across all the sites so as to more efficiently manage the whole process with a limited technical and managerial staff.
  
  In cases like this, the logging software, in addition to supporting standardized procedures across all the different sites, must also support a facility to upload the information back to the central head office.
  
  Additionally, because the central engineering department is required to maintain many disparate sites, the sytem must support remote log ins and on-line configuration modifications as well as the ability to roll back changes where necessary.
  
  
• There is an ever increasing requirement to improve the efficiency of the process. This often means that more data needs to be collected to ensure that the system is running at maximum efficiency.
  
  In many cases, the data to be collected is not available from a SCADA system and field operators must collect the data during pre-defined inspection rounds. This puts further demands on the Logging System which must support (i) a system of creating and maintaining the inspection rounds (ii) the downloading of these round definitions, (iii) PDA devices that will work in an industrial environment and (iv) the uploading and integration of the collected data into the logbooks or handover logs and shift reports.
  
  
  
  
  
• There is an increased emphasis on the reporting of accurate information, both internally and for external compliance authorities.
  
  The logging system must provide the necessary facilities to support the demanding requirements of the Power site. Generally, this means a logging application must
  (i) be able to collect real-time and historical information from the DCS or SCADA system,
  (ii) have an advanced means of capturing manually entered information and
  (iii) have an elegant means of co-ordinating this information together so that the information can be stored and distributed to the relevant parties or compliance bodies.
  
  
• There is a special need to accurately allocate different events to pre-defined reason codes and associate these reason codes to equipment in the system.
  
  To achieve this, the logging system must support a hierachial structure so that when operators need to allocate an event to a particular piece of equipment, they can “drill down” through a series of combos to the equipment of interest easily and quickly.
  
  
  
  
  

• There is a need for a plethora of different logging facilities. Often these facilities are “non-standard” and are specific to the site.
  
  The logging system must have a time-proven architecture and it must provide massive flexibility to meet the needs of the vastly different applications. These applications can range from standard (but demanding) applications like Handover Logs and Equipment Maintenance Logs to specialized applications like Trip Analysis Logs, Out of Service Logs, Emission Logs etc.
  
  
  
  
  Typically, this kind of flexibility is achieved through a logical and scalable architecture coupled with a powerful but separate facility for the presentation and business logic. This enables new applications to be quickly designed, implemented and commissioned and then added to the structure.
  

• Finally, the configuration of these logging applications should be via a simple and logical GUI interface or Wizard and provide sufficient flexibility to include industry specific components like real-time links.
  
  
  
  
  
• There is an arduous security requirement to ensure that only authorized personnel may access the system. Often this means that a user may only access (or change) specific fields within specific logbooks.
  
  To support this, the logging mechanism must typically provide
  (i) support for LDAP authentication and
  (ii) a comprehensive authority based system based on user groups. This authority based system must not only cater for the properties of the group but must also be time sensitive. (For example, a user may not alter logs in a shift that has already been closed).
  
  Finally, the system must be easily maintainable so that users and groups can be easily added or removed using a Wizard or GUI.
  
  
• Due to the critical nature of the process, there is a need for cast iron reliability and often 24x7 support.
  
  To meet this need, the providers must
  (i) provide a comprehensive reliability strategy that includes an automatic self testing and and Version Control Procedures with audited bug traceability,
  (ii) open access to the tracking of any problem and
  (iii) support programmes that provide 24x7 access to qualified engineers and developers.