Appendix IV
Little JIL Process Language
1.0. General
In the area of plant hazard analysis and safety instrumented system, business process definitions are tremendously helpful in process analysis and system automation. It is obvious that in order to contemplate how best to support the clear understanding of risk assessment processes, and how to use this understanding to support an orderly discipline of engineering of these processes, a clear and effective engineering of processes should provide strong support for better engineering of the systems that support the processes. All these needs are the major reasons behind development of process definition languages. Also, process definition languages have good role in coordination. Therefore, process definition languages are also useful in process efficiency improvement, and automation. Most real world business processes are large and complex, so good coordination for capturing, analyzing, and automating data requires huge coordination among these factors. Naturally, a good process definition language needs to have central focus on coordination. A few distinct advantages of process definition languages have been listed as follows:
1.0.1. Better Coordination and Communication
It is needless to mention that all members of a team coordinate their efforts effectively to get a fruitful result from the effort. In order to do this, it is important for each team member to understand their roles in the overall process, and to perform that role in a manner that is consistent with the overall process. Realization of all these demands a strong focus on the value of clear descriptions of the processes to be coordinated for all human and automation efforts.
1.0.2. Better System Analysis
There is every possibility that team members will commit mistakes to reduce the system efficiency. One way to circumvent the situation is to deploy a skilled person and improve control system. This is not always possible. Similar results can be achieved by modifying the process itself. This is more so in cases of large and complex processes. A simple example may shed some light. After thoroughly scrutinizing a process, it may be possible to find some activities that could be done parallel, hence improving the efficiency of the system (e.g. in order to start a boiler it is necessary to start ID fan prior to FD fan. So, first start the control oil and lube oil pumps of ID fan, then start ID fan and PARALLELLY start the control oil and lube oil of FD fan so, for starting FD fan some time can be saved. An important issue is exception handling, which when recognized earlier in analysis phase, then with proper planning many inefficiencies can be circumvented through proper planning and taking precautions beforehand. This is important for safety assessment systems.
1.0.3. Continuation of Process Improvement
As a part of good engineering practice, it is natural to invite a constant flow of new ideas to improve the functioning of the team and team efforts. Obviously, detailed, precise, and complete process description seems most useful as the focus of these activities. Also, such process description becomes a key to judge the pros and cons of any proposed modification, phasing and batching of proposed modifications, as well as to identify if there be any conflicting issues related to the proposed modification.
1.0.4. Improvement of System Performance and Efficiency
Deployment of more people and inappropriate automation at times can lead to inefficiencies like “too many cooks spoil the broth.” Practitioners in many domains have recognized that extra people can actually reduce efficiency and productivity. Naturally, the efforts shall be there to improve the performance of the system by utilization of superior processes which can help elucidate how project work should be phased and sequenced, where parallel activities should be expected to help, and what the various members of teams should be doing at various times [3]. Detailed but precise, clear process descriptions help to identify the bottlenecks and inefficiencies. Therefore, process descriptions are always major tools to improve system performance and efficiencies.
1.0.5. Supports Development and Reinvention
Any incremental improvements are always welcome. However in many cases there are issues related to radical changes for system improvement. Now, prior to implementation of such changes it is necessary to thoroughly evaluate the system. Similarly, it is essential to have detailed but precise and clear definition of the process so that modified system can be fit in.
1.0.6. Efficient Application of Automation in All Respect
Augmentation of automation is always a natural tendency to improve efficiency and productivity. However, such augmentation must be proper. Otherwise inappropriate application or wrong automation will be not only be ineffective, but could be counterproductive also., Automation can provide improvements when automation activities closely match tasks and activities in existing processes. Thus, in all such cases, detailed but precise and accurate description of the process cannot be overestimated.
1.0.7. Support and Training
A clear, precise, and complete description of the team's processes is absolutely essential as a part of training for a newcomer joining the team. Such descriptions should specify what each participant is expected to do, what each can expect from the others, and the overall nature of the team activity [3]. Also, process descriptions at times are used as simulation unit during training to have a feel about actual working environment. This also requires detailed but precise and clear description of process.
It is better to take a survey about the various requirements for a process definition language before taking a call on Little Julia input language (JIL) process language.
1.1. Requirements of Process Definition Language
There are a number of personnel belonging to different disciplines, involved in large processes, so analysis of process descriptions can help each of the concerned personnel to know respective jobs better and can interact with others in more efficient way. Also it is possible to identify the system bottlenecks, inefficiencies, process defects, and faulty coordination. Well-defined business processes also lay the foundation for potential automation and e-Business exchanges by way of IT systems across organizations [2]. Apparently this approach is simple and straightforward but in reality it is not so. Major challenges comes from actual definition of such large and complex processes with required details. Proper coordination is also a big issue. Major issues related to process definition languages which are meant to be used in computer shall include but not limited to the following:
1.1.1. Clear and Understandable
Rigorous efforts are put to make software languages clear. Similarly, efforts are also necessary to make the process definition language clear and well understood.
1.1.2. Detailing
Computer languages have the specification of arbitrary levels of detailing. In most cases, iterative hierarchical decomposition is used for doing this. Thus, similar approach and specification is called for in process language also.
1.1.3. Resource Management
Control flow and activities have been given major thrust in most of the process languages. This is possible only when equal and more importance have been allotted to various resources such as personnel, systems, and other physical entities. Proper specification resource capability, policies for resource allocations are major semantic issues in actual process definition language.
1.1.4. Exception Handling
When looking at the issue, as the name suggests, may seem that it is a rare issue but in reality it is not so. In many cases, exceptions may dominate business scenarios. This could be well understood from the following example: Fire from an explosive atmosphere or leakage in nuclear installations is rare, because during design process a lot of importance are put handling such exceptions. Therefore, process definitions must put proper importance to the specification of exception management and exception handling strategies.
1.1.5. Rigorous
Process languages will be used in computers, which executes programs in coding languages with rigorous semantics. Therefore, such requirements of language must be considered as bases for the specification of processes as well.
1.1.6. Process Variations
On account of different reasons, there could be variations in a processes. So, the process definitions language must have flexibility to cater to such process variations. In reality, addressing this issue requires large-scale process reuse through both planned variation points and property observing mechanisms [2].
1.1.7. Control and Data Flow
Data flows and data-driven information systems are main enveloping information and vital for process definitions. The definition of the activity aspects of processes cannot be isolated from process data. Control and data flow improves process understanding, enables process analysis, and guides unambiguous process implementation and deployment, so reconciliation of these are important.
There are a few numbers of such process definition languages such as business process modeling notation (BPMN) or extensible markup language (XML). Little JIL is one of the most promising process definition languages, which shall be discussed in this part of the discussion.
1.1.8. Systematically Broad
In computer software languages, there are a few familiar features such as artifacts, scoping, looping, if-then-else, and sequencing, etc. So, it seems reasonable to have such software language approach in process definition languages also.
1.2. What Is Little JIL Process Definition Language
Little JIL is a process definition language to coordinate the activities of multiple people and software tools operating in a distributed environment and sharing data and resources (all those discussed previously). It is different from usual programming language normally used for computations. Various aspects of Little JIL language shall include mainly:
• Coordination diagram: The graphical representation of process steps. It also serves as the skeleton to which various annotations about other aspects of the process can be attached.
• Artifact space/model: This is the collection of data types (using Java), which are used by the objects during the process execution.
• Resource model: The resources shared by the interfacing agents during execution of the process.
• Agents: Java programs.
1.3. Juliette
It is an interpreter. Little JIL operating environment consists of:
• Editor: This is visual-JIL used to create the process in the language.
• JSim: It is the simulator for Little JIL.
• Little JIL checker: Used for syntax and semantic checking.
• Jul: This is interpreter for process execution.
Now it is time to explore to see why it is popular as process definition language.
2.0. Little JIL Process Definition Language
From the preceding discussions, it is clear that any process definition language has some requirements to be fulfilled so that the same can be used as process definition language. Little JIL is one of such process definition language which is powerful. So, in this part, language shall be looked into with a little depth for proper understanding of the same.
2.0.1. Little JIL Explanation
Little JIL could be conceived as a programming language for coordination in processes. This high-level language possesses formal graphical syntax and rigorously defined operational semantics. The focus of Little JIL processes is coordination of autonomous agents, shared resources, and information flow. All such coordinations are done with the help of graphical notation. The steps and sub-steps are the focal points for coordination, with scoping mechanism for control, data, and exception flow. The steps also provide interface for agent and resource assignment. Steps are organized usually in a hierarchy, but can have the possibility of recursion and concurrency. Agents are: autonomous entities, human, and software program. Assignment of tasks to agents is a part of Little JIL, but how agents perform the task is not part of Little JIL. Also, resources are external entities but these are monitored and controlled, as the resource needs are specified in little JIL. Information/data, (information/data – type, characteristics and manipulations are external) are propagated between agents to complete their jobs.
2.0.2. Basis of Little JIL
Little JIL is based on two main hypotheses:
• Coordination structure is separable from other process language issues. Although it offers rich control structures, it relies on separate systems for resource, artifact, and agenda management.
• Agents, who execute the process, know how to perform their tasks with benefit from coordination support. Therefore, each step has an execution agent responsible for performing the work of the step. This approach has proven effective in supporting the clear and concise expression of agent coordination.
2.0.3. Little JIL as Computer Language
As discussed above, there are a few characteristics a process definition language when used in computer needs to meet. These are rigorous, detailed, broad semantic, and clear understanding. These characteristics are met in the following ways by Little JIL:
• Rigorous: Little JIL's semantics are defined in terms of finite state machines [3].
• Detailed: Little JIL uses hierarchical decomposition as the primary vehicle for supporting the iterative, incremental elaboration of details [3].
• Semantically broad: A Little JIL process definition consists of three components, viz. artifact (see Fig. APIV/2.0.3-1), resource, and coordination structure.
• Clear and understandable: Diagrammatical representation to support clarification of the coordination structure.
2.0.4. Approaches [3,4]
Little JIL has been developed in a factored approach that allows the core coordination language to be simpler and easier to understand, develop, and use. This kind of approach also allows a few aspects of process definition to be developed and evolved in independent ways. The design of Little JIL coordination features was guided by following primary principles:
• Simplicity: Concerted efforts have been made to keep the language simple and to get clarity, ease-of-use, and understandability.
• Expressiveness: Software and workflow processes are semantically rich domains, and a process language, one tightly focused on coordination [4]. The language is highly expressive to reflect a variety of semantics. The language allows users to address entire the range of concerns relevant to a process and to express their goals in a clear manner.
• Precision: The language semantics are precisely defined for automatic execution of process programs. Such precision supports the analysis of process programs. Analysis is a key to assuring that process programs indeed have properties that are desirable for process safety, correctness, reliability, and predictability [4].
• Flexibility: Little JIL is designed to give process programmers the power to choose what level of flexibility to give to the process's agents [4]. This is important for the cases where more than one sequencing is acceptable, or when a different set of steps may be acceptable.
• Separability: Little JIL relies on separate systems for certain functionality that is not deemed central to the expression of coordination structures. This makes the core coordination language simpler and easier to understand, develop, and use [3].
2.1. The Language
As stated earlier, Little JIL language has hierarchical structure and is a tree of step types, each of which can be multiply instantiated at runtime. Each leaf represents the smallest specified units of work and the tree's structure represents the way in which this work will be coordinated. As processes execute, steps go through several states. Typically, a step can be posted only when it is assigned to an agent who starts the step. Any of these said step is either successfully completed or may be terminated due to an exception.
2.1.1. Representation
Typical Little JIL language representation has been shown in Fig. APIV/2.1.1-1. As shown in the figure, there are a number of badges that make up a step, as well one step's possible connections to other steps.
• Interface badge: To the circle at the top of the step to this interface badge, an edge from the parent may be attached. The circle is filled if there are local declarations such as parameters and resources associated with the step. Otherwise it will be empty. Filled in blue circle to indicate some attributes.
• Step name: Just below the interface badge.
• Prerequisite badge: The triangle left side of step is a called the prerequisite badge. The badge appears filled if the step has a prerequisite step/condition and an edge may be shown that connects this step to its prerequisite.
• Post requisite badge: Similar as previous and shown in the right side.
• Badges in box: There is a box below the step name. Within the box there are two badges. As shown, from left to right are: the control flow badge, the exception handler.
• Control badge: This indicates the order in which sub-steps are to be executed, and to which the sub-steps are attached.
• Exception handler: Red Cross (X) to which exception handlers are attached.
The edges that come from these badges can be annotated with parameters (passed to and from sub-steps). This is also shown in the figure under reference. In case, when there is no sub-step/exception handler, respectively, then the badges previously described (control flow or exception handler) are omitted (refer to blank boxes at the bottom side). It is possible for an exception to have a null handler, in which case the continuation badge alone determines how execution proceeds.
Figure APIV/2.1.1-1 Little JIL language representation. Figure courtesy of Professor L.J. Osterweil–University of Massachusetts. A.G. Cass, B.S. Lerner, E.K. McCall, L.J. Osterweil, S.M. Sutton Jr., A. Wise, Little-JIL/Juliette: A Process Definition Language and Interpreter; http://laser.cs.umass.edu/techreports/00-66.pdf.
Non-leaf step: There are four non-leaf step kinds provide control flow. These are:
• Sequential: It is similar in representation to control flow go sequentially (analogy: For starting a large fan/pump, one needs to carry out a number of steps sequentially such as starting of control oil supply, lube oil supply to close inlet or outlet damper, etc. before giving starting command to the fan).
• Parallel: To indicate parallel action (analogy: starting of ID fan and starting of control and lube oil supply to FD fan).
• Try: This may be stage-by-stage protection in a system. (analogy: first to start an auto means to combat a fault, if fails, try operator alarm then, say, trip the machine).
• Choice: Selection of various paths to meet the target (analogy: if a pump fails automatically start any of the standby pump).
It is important to note that the language offers through “the parallel” and “choice” steps to the human user to exercise their judgment and to make choices regarding subsequent steps.
2.1.2. Little JIL – The Concept
From the previous discussions it is clear that Little JIL as a coordination language rests on four major components. The concept of Little JIL language has been as shown schematically in Fig. APIV/2.1.2-1. Major components are:
• Agent – actor (taking action)
• Step – the activity
• Artifacts
2.2. Important Issues of Little JIL
There are a few important issues related to Little JIL process definition, which have been enumerated as follows:
2.2.1. Requisites
These are mechanisms for checking before and after a step is executed to ensure that all the conditions needed before a step are satisfied and also the step has been executed “correctly.” A prerequisite is a step that must be completed, prior to starting of a step, to which it is attached. Similarly, a post-requisite must be completed after completing the activities of the step, to which it is attached. This will be clear from an analogy: starting fuel fire in a boiler prerequisite is to check purge is complete. So, prerequisite is purge completion (and no master fuel relay) and after starting of firing to ensure flame is on, so “flame OK” is post-requisite. . The need for pre- and post-requisites appears to be common in process programs, and requisite step semantics seem different enough from other kinds of sequential steps that a special notation was introduced [1].
2.2.2. Exceptions and Handlers
As the name suggests, exceptions and handlers are used to indicate and fix exceptional conditions or errors during program execution and provide a degree of reaction control and management to handle the condition. The exception mechanisms in Little JIL are designed to be simple yet expressive. It is based on the use of steps to define the scope of exceptions and handlers. Exceptions are passed up the step decomposition tree (call stack) until a matching handler is found [1].
2.2.3. Parameters
Parameters are basically information passed from one step to the other, necessary for execution of the step to get step execution results. The parameters types, such as type definition, equality, and others, are not related to coordination. These are kept out of Little JIL.
2.2.4. Resources
Resources are entities which are specified and required during every step execution by Little JIL process definition. Resources needed by a step are specified as types only, offering flexibility for the execution of the process. This enables the use of scheduling technologies to make superior use of the resources available. As only the type of resource is specified by the step, so either human interface or automation could be used as long as the resource has the ability to meet the need defined in the resource specification. Resources may include: the agent, permissions to use tools, a database, software tools, and various physical artifacts. When software is specified as agent, then that context can also be viewed as a useful basis for defining the requirements that the software system is to meet [3]. However resource management is not part of Little JIL. Little JIL tries to minimize the requirements placed on the resource specification.
2.2.5. Artifacts
A process generally executes its functions by creating and modifying artifacts described in Fig. APIV/2.0.3-1, normally utilizing other artifacts which could be internally generated ones or inputs to the process or produced by a step. There are unique notations for the artifacts as these are required for process to identify them. Step definitions incorporate types of artifacts, so these are entities. In process applications, artifacts could be simple single ones, or could be an aggregate of artifacts [3].
2.2.6. Discussions
Little JIL does not specify parameters’ data type, resources, expressions, or imperative commands. Little JIL relies on agents to know how the tasks represented by leaf steps are performed. It is meant for specifying step coordination and NOT step execution (i.e., what steps or actions to be executed as these are process dependent). This is the precise reason in previous discussions the word “analogy” has been used in place of “example,” because in all the example cases these are executive commands.
2.3. Coordination Structure
The Little JIL coordination structure is typically represented visually as a hierarchical structure of steps as detailed in Fig. APIV/2.1.1-1. Some useful features and characteristics are as follows:
• Step name: Each step has a name.
• The badge: The badges represent step features, e.g. control flow among the step's sub-steps or the step's interface, including parameters.
• The exceptions are the step handles.
• Leaf step: A step with no sub-steps (activity to be performed by an agent, without the process).
Short details about these have already been covered in Clause 2.1.1; hence are not repeated.
2.3.1. Sub Step Decomposition
There are two sub-steps types, viz. Ordinary sub-steps and exception handlers (Ref: Clause 2.3.2). The ordinary sub-steps: this is the step execution and connection to parent step by edges with possible annotation (artifacts specifications for artifact flow) and cardinality specifications (define the number of times the sub-step is to be instantiated).
2.3.2. Exception Handler
These define the way exceptions are to be handled. The edge connection with parent has annotation with the type of the exception being handled and an indication of how to continue after exception handling.
2.3.3. Step Sequencing
Every non-leaf step has a sequencing badge as shown in bottom part of Fig. APIV/2.1.1-1.
• Arrow: The badge defines the order in which its sub-steps execute, e.g. left to right arrow indicates that sub-steps are to be executed sequentially from left to right, and is only considered completed after all of its sub-steps have been completed.
• Parallel: A parallel step indicates that parallel execution is possible. Here also it is considered completed after its entire sub-steps have completed.
• Choice: A choice step indicates agent's choice of step.
• Sub-steps: This is important for human agent and automation, for choices, try step, etc.
2.3.4. Interface Specification
Following are the features of interface specification:
• Circular icon located, top of the step bar.
• Parameter specification for the step exchanges information with its parent, and required resources for the step execution.
• Artifacts and artifact flows: An artifact is an entity discussed in Clause 2.2.5. Artifacts flow through steps can be two types:
• Hierarchical: This type is as the flow of artifacts between parent and child steps indicated by attaching to the edges between parent and child identification of the artifacts as well as arrows indicating the direction of flow of each artifact.
• Through channels: The flow of artifacts similar as above laterally or between sub-steps.
• Resources and agents: Already discussed in Clause 2.2.4—hence not repeated.
• Channels: Channels are direct named entities. Data channels are like queue. A Little JIL channel is defined as a first in first out queue. The channel construct can be used as a vehicle to coordinate and synchronize steps executing in parallel. Channels can specify steps for additional artifact of same type.
2.3.5. Requisites
Refer to Clause 2.2.1.
2.3.6. Exception Handling
A step to indicate exceptional conditions when some aspects of the step's execution fail. This will trigger the execution of a matching exception handler, associated with the parent of the step that throws the exception in this connection Clause 2.2.2 may be referred to.
2.3.7. Scope and Recursion
All steps represent a scope, specifying what artifacts are considered local to that scope. It also supports recursive execution of steps, which specifies the iterative application of a process step to specified inputs.
2.3.8. Abstraction
A step can be referred to in more than one location in a process definition. One such reference includes required details, e.g. the step's parameters and resource, and other information about the step's exception handling facilities, etc. This reference thus serves to define the step as an abstraction [3].
With this idea in mind, it is better to explore the application side of the language in plant hazard analysis automation.
3.0. Application of Little JIL in Hazard Analysis Automation
During the discussions in previous chapters on plant hazard analysis, several methods were discussed for automating plant hazard systems. In fact, in clause number 2.6.5 of Chapter IV, automated failure mode and effect analysis (FMEA) with Little JIL has been touched upon. When the entire system or process is modeled with sufficient detail, then it is possible to automate FMEA with the help of Little JIL process definition language, which has precise semantic definitions for all its language constructs. In semiconductor manufacturing and assembly line, supposing there are n numbers of subassemblies and there are n numbers of workers working together to put some subassemblies at n working stations, which are then finally assembled at a place. Now in this case, the entire system can be divided into steps and each step into sub-steps. By applying Little JIL, the entire process can be defined with the help of several artifacts (say address of any subassembly). Each artifact and step has to be precise to get a good batch of production. Now, if one worker develops power supply unit by combining unit A and B, whereas the next worker develops RF stage by putting together C and D unit. The output of these two operators is finally assembled by another operator. If there is a fault at just one operator (say first operator made a mistake in specifying C in place of A or robot who is working for workers made similar mistake), when final assembly comes out with this failure then the entire batch may have to be rejected, meaning that it has severe adverse effect on production. In such cases Little JIL can be applied for automating the process. Here, a point to be noted is that for single example of failure there could be two types of faults such as:
• Type 1: Artifact (wrong address item), step S is wrong, i.e. worker specified C in place of A.
• Type 2: Artifact (wrong address) from step S is wrong, i.e. robot by mistake brought C in place of A.
The preceding is just an example to show how Little JIL can be applied in a manufacturing process. In the example, it is only one failure mode and type has been depicted. There could be a large number of failure modes/artifact-related failure modes or can easily be turned into artifact-related failure modes. Also, if a step is done incorrectly, one would expect that failure to be evident in one or more of the out artifacts associated with that step. For detailed and effective analysis, an artifact flow graph (AFG) may be developed from by traversing the process tree with necessary algorithm. Derived FMEA information is obtained from AFG. When the system is large, one may take the help of fault tree analysis (FTA) to determine one failure mode in a complex system. Little JIL process definition can help in deriving automated FTA. Here, there are two issues:
• How to automatically extract fault tree events that could lead to a given event.
• How to use appropriate gates for arriving at the event.
For this, each type discussed in the preceding needs to be addressed, maybe separately, by Little JIL. Therefore Little JIL language can be applied in automating FMEA/FTA for finding failure modes in large and complex systems.
The main aim of this appendix is to bring readers attention to this powerful process language, which is very useful and helpful in automating hazard analysis and failure mode identifications. With this, the discussions on Little JIL is completed to look into another important issues of embedded controls which are now used in process control application including nuclear installations.
List of Abbreviations
| AFG | Artifact flow graph |
| AI/O | Analog input/output |
| BPMN | Business process modeling notation |
| DCS | Distributed control system |
| DI/O | Digital input/output |
| E/E/PE | Electrical/electronics/programmable electronics |
| FD (fan) | Forced draft (fan) |
| FIFO | First in first out |
| ID (fan) | Induced draft (fan) |
| IEC | International Electrotechnical Commission |
| I/O | Input/output |
| I/P or O/P | Input or output |
| IT | Information technology |
| JIL | Julia input language |
| MFR | Master fuel relay |
| P&ID | Piping and instrumentation diagram |
| PSA | Probabilistic safety assessment |
| SW | Software |
| XML | Extensible markup language |
..................Content has been hidden....................
You can't read the all page of ebook, please click here login for view all page.