PLANTCockpit D2.1 Public

The PLANTCockpit project (260018) is co-funded by the European Union under the Information and Communication Technologies (ICT) theme of the 7th Framework Programme for R&D (FP7).

This document does not represent the opinion of the European Community, and the European Community is not responsible for any use that might be made of its content.

Programme Factories of the Future PPP

Strategic Objective ICT-2010-10 Smart Factories: ICT for agile and environmentally friendly manufacturing

Project Title Production Logistics And Sustainability Cockpit

Acronym PLANTCockpit

Project # 260018

D2.1 - METHOD TO COLLECT, DOCUMENT, AND ANALYSE USER REQUIREMENTS

Work Package WP-2 Requirements Analysis

Lead Partner EPFL

Contributing Partner(s) EPFL, INTEL, SAP, TUD, FTK, POLIMI, TUT

Security Classification PU

Date 10/12/10

Version 1.0

Project - No 260018

Date 10.12.10

Method to collect, document, and analyse user requirements Classification CO

PLANTCockpit_D2_1_Public.docx ii

The research leading to these results has received funding from the European Communitys Seventh Framework Programme (FP7/2007-2013) under grant agreement no260018.

Project - No 260018

Date 10.12.10


PLANTCockpit_D2_1_Public.docx iii

Table of contents 1 EXECUTIVE SUMMARY ........................................................................................... 1 2 PREAMBLE INTRODUCTION ............................................................................... 2 3 METHOD TO COLLECT, DOCUMENT, AND ANALYSE USER REQUIREMENTS .............................................................................................................. 3

3.1 OVERALL DESCRIPTION OF THE REQUIREMENT ELICITATION PROCESS.......................... 3 3.2 COGNITIVE WORK ANALYSIS .................................................................................... 4

3.2.1 Advantages of CWA ........................................................................................... 5 3.2.2 Limitations of CWA ............................................................................................ 6

3.3 VISION STATEMENT ANALYSIS ................................................................................... 6 3.3.1 Description ........................................................................................................ 6 3.3.2 Knowledge gathering techniques ...................................................................... 10 3.3.3 Modelling tools ................................................................................................ 10 3.3.4 Summary .......................................................................................................... 15

3.4 WORK DOMAIN ANALYSIS ....................................................................................... 15 3.4.1 Description ...................................................................................................... 15 3.4.2 Knowledge gathering techniques ...................................................................... 15 3.4.2.1 Document analysis ........................................................................................ 15 3.4.2.2 Exploratory interview ................................................................................... 15 3.4.3 Modelling tools ................................................................................................ 16 3.4.3.1 Abstraction hierarchy ................................................................................... 16 3.4.3.2 Abstraction decomposition space .................................................................. 18 3.4.3.3 Concept Mapping ......................................................................................... 19 3.4.4 Summary .......................................................................................................... 21

3.5 CONTROL TASK ANALYSIS ....................................................................................... 21 3.5.1 Description ...................................................................................................... 21 3.5.2 Knowledge gathering ....................................................................................... 21 3.5.2.1 Expert Interview ........................................................................................... 21 3.5.3 Modelling tools ................................................................................................ 22 3.5.3.1 The Decision Ladder..................................................................................... 22 3.5.4 Summary .......................................................................................................... 25

3.6 STRATEGIES ANALYSIS ............................................................................................ 25 3.6.1 Description ...................................................................................................... 25 3.6.2 Knowledge Gathering ...................................................................................... 26 3.6.2.1 Interviews ..................................................................................................... 26 3.6.2.2 Observations ................................................................................................ 26 3.6.3 Modelling tools ................................................................................................ 27 3.6.3.1 (Information) Process Mapping .................................................................... 27 3.6.3.2 Information Flow Maps ................................................................................ 27 3.6.3.3 IDEF ............................................................................................................ 29 3.6.4 Summary .......................................................................................................... 29

3.7 REQUIREMENT SPECIFICATION ................................................................................. 30 3.7.1 Functional specification ................................................................................... 30 3.7.1.1 Description ................................................................................................... 30

Project - No 260018

Date 10.12.10


PLANTCockpit_D2_1_Public.docx iv

3.7.1.2 Knowledge integration .................................................................................. 30 3.7.1.3 Modelling tools ............................................................................................. 30 3.7.1.4 Viewpoint Definition template ....................................................................... 31 3.7.1.5 Requirement table ......................................................................................... 32 3.7.1.6 Use case template ......................................................................................... 35 3.7.2 Technical specification .................................................................................... 36 3.7.2.1 Definition of the application ......................................................................... 37 3.7.2.2 Objective of the application .......................................................................... 37 3.7.2.3 Involved actors in the application ................................................................. 37 3.7.2.4 Physical components considered in the application....................................... 38 3.7.2.5 The application software/support-systems ..................................................... 38 3.7.2.6 Description of the functionality of the application ......................................... 39 3.7.2.7 Information flow modelling template and guide (Swim lane) ......................... 40 3.7.2.7.1 Description of basic symbols of event and information flow modelling templates .................................................................................................................. 40 3.7.2.7.2 Event process chain diagram for workflow modelling ................................ 41 3.7.2.7.3 Information flow diagram for information flow modelling ......................... 43 3.7.3 Summary .......................................................................................................... 44

4 CONCLUDING REMARKS ...................................................................................... 46 5 REFERENCES ........................................................................................................... 46

Project - No 260018

Date 10.12.10


PLANTCockpit_D2_1_Public.docx v

Table of Figures Figure 1. Activity modelling using IDEF .................................................................... 3 Figure 2. CWA Nested Constraints (Vicente, 1999) .................................................... 5 Figure 3. IDEF diagram of the requirement elicitation process ................................. 7 Figure 4. IDEF diagram of the activity A5 ................................................................. 8 Figure 5. Mindmap template ...................................................................................... 10 Figure 6. Business and organisation part of the Mindmap ........................................ 10 Figure 7. Plant structure part of the Mindmap ........................................................... 11 Figure 8. Performance impact part of the Mindmap .................................................. 11 Figure 9. Support systems part of the Mindmap ........................................................ 12 Figure 10. Processes part of the Mindmap ................................................................ 13 Figure 11. Events part of the Mindmap ..................................................................... 13 Figure 12. Engineering assets part of the Mindmap .................................................. 14 Figure 13. Product part of the Mindmap .................................................................... 14 Figure 14. Business and organisation part of the Mindmap ...................................... 15 Figure 15. Types of Hierarchies ................................................................................ 16 Figure 16. An abstraction hierarchy of a car (Burns & Hajdukiewicz, 2004) .............. 17 Figure 17. Abstraction hierarchy of manufacturing line ............................................. 18 Figure 18. Relationships in an ADS (Vicente, 1999) ................................................. 19 Figure 19. Annotated Abstraction Hierarchy (Upton & Doherty, 2010) ...................... 19 Figure 20. Concept Map (Crandall et al., 2006) ........................................................ 20 Figure 21. The Decision Ladder ................................................................................ 23 Figure 22. Decision Ladder for the Model Human Scheduler (Sanderson, 1998) ..... 24 Figure 23. Decision Ladders showing distributed cognitive workload........................ 25 Figure 24. Control Task Analysis & Strategies Analysis (Vicente, 1999) ................... 26 Figure 25. Information Process Flow associated with bottleneck evaluation ............. 27 Figure 26. Information Flow Map applied to air traffic control strategy (Kilgore et al.,

2008) .......................................................................................................... 28 Figure 27. IDEF3 Process Description Diagram ........................................................ 29 Figure 28. IDEF3 Object State Transition Network Diagram ..................................... 29 Figure 29. Use Case Diagram ................................................................................... 31 Figure 30. Swim lane template .................................................................................. 42 Figure 31. Information flow diagram .......................................................................... 43 Figure 32. Relationship between models across the CWA phases ........................... 45

Project - No 260018

Date 10.12.10


PLANTCockpit_D2_1_Public.docx vi

Table of tables Table 1: Description of the requirement elicitation process ......................................... 9 Table 2: Viewpoint definition table ............................................................................. 32 Table 3: Requirement specification table .................................................................. 34 Table 4: Use case table ............................................................................................. 36 Table 5: Technical requirement table ........................................................................ 37 Table 6: The concerned PLANTCockpit application .................................................. 37 Table 7: Objectives of the concerned PLANTCockpit application ............................. 37 Table 8: Involved lifecycle actors of the concerned PLANTCockpit application ........ 38 Table 9: Physical components of the concerned PLANTCockpit application ............ 38 Table 10: Support systems / other systems external of the concerned PLANTCockpit

application .................................................................................................. 38 Table 11: Functionalities of the concerned Application ............................................. 39 Table 12: Basic symbols for workflow and information modelling ............................. 40

Project - No 260018

Date 10.12.10


PLANTCockpit_D2_1_Public.docx 1

1 Executive Summary This report provides the PLANTCockpit D2.1 deliverable: Method to collect, document, and analyse user requirement. The report contains the description of the approach and the related set of requirement specification templates, therefore facilitating the requirement elicitation process. This deliverable can be considered as an important input to specify functional and technical requirements that PLANTCockpit will address in the following Work Packages.

Project - No 260018

Date 10.12.10



2 Preamble Introduction The objective of the Work Package 2 is to define and specify the functional and technical requirements for PLANTCockpit. Due to the fact that PLANTCockpit addresses a representative selection of main industries and production types, the requirements analysis considers the generic issues as well as industry specific and production type specific issues. The starting point for the analysis is the definition of an adequate methodology for the requirements analysis itself which provides the basis for conducting the functional, the technical and the cognitive requirements analysis. To achieve this objective, this report addresses the Task 2.1: Specification of an analysis method that will be considered as a support for the following tasks 2.2 and 2.3.

This report is organized in a way to facilitate the implementation of requirements elicitation for each end-user. Section 3 describes the proposed methodology to collect, document, and analyse user requirements at a high and detailed levels. In this main section, each step of the approach is described and specific templates, techniques and diagrams are introduced.

Project - No 260018

Date 10.12.10



3 Method to collect, document, and analyse user requirements This section describes the proposed approach for functional and technical requirements elicitation. It also describes the set of techniques and templates that are used to capture and specify document business context (need and impact) and user requirements.

3.1 Overall description of the requirement elicitation process To carry out the Task 2.1, a requirement elicitation methodology has been proposed. Figure 3 and Figure 4 introduce an IDEF diagram, giving an overview of the approach, in which the several steps including input and output information, the associated techniques/tools/templates as control means, and the involved actors are presented. The activity modelling of the methodology proposed in this report essentially provides an input-output model with a static snapshot view (Figure 1). This framework is hierarchical in nature and thus allows a top-down decomposition of each phase of the proposed requirement elicitation process. In such a context, IDEF modelling standard is particularly suited to define and model information flows. The description of basic elements in IDEF is as follows:

- Activity: Any action that is necessary to convert the inputs into outputs. Activities are presented by boxes. Activities can be broken down into sub-activities as long as all the sub-activities are member of the subset;

- Input & Output: Any set of data-information which is transformed by an activity. Inputs enter from the left face of the activity box and outputs exit from the right face of the activity box;

- Constraint: When input and output from one activity box becomes a control to another activity box, it constraints the activity that can be controlled in that box. Thus, constraints specify the limits, range, procedures, templates, working regions permissible for the activity. Constraint is represented by an arrow entering through the top face of the activity box;

- Mechanism: Entity that makes the activity happens. This is represented by an arrow that enters through the bottom face of the activity box.

Figure 1. Activity modelling using IDEF

In such a way, this IDEF diagram (Figure 3 and Figure 4) enables the complete understanding by the reader to ensure flawless execution of the procedure from a high abstraction level. This diagram is followed by a table which summarises the requirements elicitation process by incorporating the purpose of each step (Table 1). Here, the proposed

ActivityInputs Outputs

Constraints

Mechanisms

Project - No 260018

Date 10.12.10



procedure can be broken down into five steps, as listed below: 1. Vision statement analysis (A1) 2. Work domain analysis (A2) 3. Control task analysis (A3) 4. Strategies analysis (A4) 5. Requirement specification

5.1. Functional requirements identification and documentation (A51) 5.2. Technical requirements identification and documentation (A52)

The proposed method enables the incorporation of Cognitive Work Analysis (CWA) in the specification of requirements for PLANTCockpit. The DoW identifies CWA as one of the methodological frameworks for analysing the three application partners work domains. CWA comes with a pre-existing process and a number of tools that focus on cognitive and perceptual aspects of systems design. The purpose here is to highlight these techniques and suggest similar modelling tools that may be more familiar to analysts from a software engineering background. The process overview also provides a useful structure for planning the knowledge gathering techniques and reviewing current technologies used by the target domain.

The aims of this toolkit are to:

1. Outline a structured process for requirements engineering 2. Provide guidance on knowledge gathering techniques to analysis partners 3. Provide standard tools and templates for modelling outputs throughout the process

3.2 Cognitive Work Analysis

CWA can be considered as a formative, constraint-based framework for analyzing complex work systems (Vicente, 1999).To systematically explore work possibilities, CWA focuses on identifying the constraints that shape workers purposeful goal-directed behaviour rather than cataloguing specific worker tasks and procedures. This approach is inspired by ecological psychologys tenet that complex human behaviour in operational settings can be usefully explained by analyzing the complexity of their surroundings. The original CWA framework, such as shown in Figure 2, suggested that work domain could be modelled across five levels of nested constraints (Rasmussen et al., 1990):

- Work Domain: Physical or intentional constraints that determine what can be done by a system;

- Control Tasks: Transformation of information into knowledge states required to meet systems goals;

- Strategies: Different methods for achieving control tasks; - Social: Organisation Distribution of strategic tasks across system agents; - Worker Competency: The role of expertise and situational knowledge in achieving

tasks.

Project - No 260018

Date 10.12.10



Figure 2. CWA Nested Constraints (Vicente, 1999)

3.2.1 Advantages of CWA Software requirements engineering generally starts with use cases and looks to specify functional requirements. This poses a number of challenges for large scale projects such as PLANTCockpit. Firstly it works off an assumption that business requirements have already been identified by a business analyst and can be expressed to the software design team. Secondly, software requirements rarely provide the contextual information that is necessary to inform the design of end-user interfaces. CWA can overcome both of these limitations as described in the following paragraphs.

FirstOfKind (FOAK) systems:

First Of A Kind (FOAK) systems generally offer new functionality to user roles that may not yet exist. This makes it difficult to apply conventional user centred requirements gathering techniques. By moving from the work domain level to worker level it is possible to identify the system goals and context of work that will determine end user needs.

Resilience Engineering:

CWA has been developed to support the development of control systems that take account of both the perceptual/cognitive limitations and the flexibility and intelligence of human operators. It aims to support different levels of cognitive control that can be exerted on a system, as defined by the Skills, Rules and Knowledge Taxonomy (Rasmussen, 1983).This supports the development of control interfaces that allow operators to cope with unanticipated events as well supporting efficient standard operating procedures.

Informing GUI Design:

Software requirements rarely provide the level of contextual information necessary to inform the design of end user interfaces. The rich descriptions gained through extensive knowledge gathering and modelling can directly inform the design of user interfaces that reduce cognitive workload and increase situation awareness.

Project - No 260018

Date 10.12.10



Focussing the Problem:

Many software requirements engineering processes require that business requirements have already been identified by a business analyst and can be expressed to a software architect. This can pose a challenge in large scale research projects where the initial research goals can be highly abstract. The CWA approach allows a researcher to progressively focus in on how goals can be achieved, thus supporting iterative clarification of the problem statement. At the same time the use of hierarchical functional models make is easier to separate generic cross-domain functionality from context dependent issues.

3.2.2 Limitations of CWA Toolkit Limitations:

Modelling techniques for the later phases of the framework are not well described in the literature. To overcome this we have suggested additional modelling techniques that are appropriate for the different phases.

Familiarity:

While CWA has been applied to a wide range of critical systems domains, these tools may not be familiar to the wider ICT sector. Again we have suggested additional modelling techniques that may be more familiar to developers to overcome this issue. Below we provide an amended cognitive work analysis process.

3.3 Vision statement analysis 3.3.1 Description The vision statement describes the functional purpose of the system by explaining the business need for the technology, its estimated impact and some means for evaluation. The vision statement facilitates the process of identifying a solid business need by calling out goals and what is needed to achieve these goals. It also calls out the specific Impact that the implementation of the project will have on business practices. State the scope of the implementation i.e. will impact be seen in one specific area/tool set. Each of the impact variables called out in the impact section of the vision statement template can be subjected to quantitative measurement and process improvement can be evaluated using standard statistical methods. Additional qualitative evaluation for example usability and end user satisfaction surveys can ensure that the needs of expert end users have been successfully accommodated.

The vision statement also helps to describe the associated roles and their primary goals. This should describe all potential end users of the system in terms of their job specification and responsibilities. Their current goals should be clearly described as well as an indication of how the proposed system will improve performance. A network diagram is often used to help map and visualise these users, goals and interactions.

.

Project - No 260018

Date 10.12.10



Figure 3. IDEF diagram of the requirement elicitation process

NODE: NO.: A0TITLE: Collect, document and analyse user requirements

A1

Analyse vision

statement

A2

Analyse work

domain

A3

Analyse control

task

A4

Analyse strategies

Storyboard, DoW,Brainstorming session Vision statement, Populated Mindmap (high level)

Concept Maps, Abstraction hierarchy, Interview transcripts

Decision Ladder Diagrams, Interview transcripts

Process Flow Diagrams for each View Point (VP), Information Flow Diagrams, IDEF Models, SwimLanes

A5

Specify requirement

Vision statementtemplate

Mindmaptemplate

Mgt representative from industrial demonstrator & requirements analyst

Mgt representative from industrial demonstrator & requirements analyst

Exploratory interview, document analysis

Conceptmap

Hierarchytemplate

Domain expert representative from industrial demonstrator & requirements analyst

Domain expert Interview

Interview template

End user interview, Observation of Work Practices

End-user representative from industrial demonstrator & requirement analyst

Process Flowtemplate

Representative analyst & all representatives from industry demonstrator partner

Use caseTemplate (UC)

Functional requirement template (FRQ)

Technical requirement template (TRQ)

Ucs, FRQs, TRQs

Project - No 260018

Date 10.12.10



Figure 4. IDEF diagram of the activity A5

NODE: NO.: A5TITLE: Specify requirement

A51

Identify & document functional

requirement

A52

Identify & document technical

requirement

Partners involved in the activity including end-user

Partners involved in the activity including end-user

VPs & Mindmap FRQs, UCs

TRQs, SwimLanes models, IF models

FRQtemplate

UCtemplate

TRQtemplate

SwimLanetemplate

Information Flow (IF)template

Project - No 260018

Date 10.12.10



Table 1: Description of the requirement elicitation process

Step No.

Description Purpose MECHANISMSActors (partners) involved

INPUTSSource(s) to be used(storyboard, ppt, meeting, interview, visit, )

CONTROLSTemplate (model) to be used(MindMap, ConceptMap, VP table, RQ table, UC model, SwimLane model, DataFlow model, )

OUTPUT (deadline)

Responsible

1 Vision statement To identify business needs for the technology, its estimated impact and concerns of actors involved and some means for evaluation

Management Representative from Industrial Demonstrator & Requirements Analyst

Storyboard, Brainstorming Session

Vision Statement templateMindMap Template

Vision statement MindMap (High level)

Analysis Team(As per matrix) Ensure quality control of Document

2 Work domain analysis

Work Domain Analysis involves developing a model of causal relationships between an overall system, its subsystems and their constituent components

Management Representative from Industrial Demonstrator & Requirements Analyst

Vision Statement, Populated MindMap,Exploratory Interview,Document Analysis

Concept Map/Abstraction Hierarchy Template

Concept Map/Abstraction HierarchyInterview Transcripts


3 Control Task analysis Control Task Analysis models reasoning associated with system tasks it achieves this by tracing transitions between low-level data associated with skills-based behaviour and high-level knowledge supporting knowledge-based behaviour

Domain Expert Representative (e.g. Process engineer) from Industrial Demonstrator & Requirements Analyst

Concept Map/Abstraction HierarchyDomain Expert Interview

Interview Template Decision Ladder Diagrams Interview Transcripts


4 Strategies analysis Strategies Analysis is used to describe work activity. While control task analysis defines what needs to occur at a high level, strategies analysis explains how an output can be achieved in real world scenarios.

End User Representative(s) from Industrial Demonstrator (e.g tool operator) & Requirements Analyst

Decision LadderEnd user InterviewObservation of Work Practices

Process Flow Templatese.g. Information Flow Diagram e.g. IDEF Model e.g.Swimlanes

Process Flow Diagrams for each View Point (VP)Information Flow DiagramsIDEF ModelsSwimlanes


5 Requirements Specification

Requirements Specification aims to integrate the output from all previous stages in the Analysis process together and puts forward a full description and understanding of what you want the system to do.

Requirements Analyst & All representatives from Industrial Demonstrator Partner

Concept Map/Abstraction HierarchyDecision LaddersProcess Flow Diagrams

Use Case TemplateFunctional Requirements Template (FRQ) Technical Requirements Template (TRQ)

Use Case DiagramsFRQsTRQs


5.1 Identify & document functional requirements (FRQ)

To define what PLANTCockpit is supposed to accomplish for End-User

Partners involved in the activity including end-user(COMAU, POLIMI and EPFL)

VPS & MindMap FRQ table template, UC template, ConceptMap (CM) template

FRQs, Ucs, CMs Task Leader (EPFL)

5.2 Identify & document technical requirements (TRQ)

To provide technical aspects that PLANTCockpit is supposed to fulfill

Partners involved in the activity including end-user(COMAU, POLIMI and EPFL)

FRQs, Ucs, CMs TRQ templates (PC, Obj, FU, SS) Swimlane template, Information Flow (IF) template

TRQs, Swimlane models, IF models

Task Leader (EPFL)

Project - No 260018

Date 10.12.10



3.3.2 Knowledge gathering techniques Brainstorming is often used whilst populating the vision statement template. Several sessions may be needed. A storyboard approach can also be taken to map out all of the above. The Description of Work document should also be referenced. Management representatives from each industrial use application and the requirements analyst should be involved at this stage.

3.3.3 Modelling tools The vision statement template as well as the Mindmap template (Figure 5 to Figure 14) is used as a modelling tool for this analysis stage. In each phase of the analysis an example shows how the relevant template has been applied to the manufacturing case study. In relation to the vision statement and the Mindmap we can see that the business need is to provide better support for production line management in semiconductor manufacturing facility.

Figure 5. Mindmap template

Figure 6. Business and organisation part of the Mindmap

Project - No 260018

Date 10.12.10



Figure 7. Plant structure part of the Mindmap

Figure 8. Performance impact part of the Mindmap

Project - No 260018

Date 10.12.10



Figure 9. Support systems part of the Mindmap

Project - No 260018

Date 10.12.10



Figure 10. Processes part of the Mindmap

Figure 11. Events part of the Mindmap

Project - No 260018

Date 10.12.10



Figure 12. Engineering assets part of the Mindmap

Figure 13. Product part of the Mindmap

Project - No 260018

Date 10.12.10



Figure 14. Business and organisation part of the Mindmap

3.3.4 Summary The vision statement describes the business need for an application framework. This can be thought of as the highest level functional purpose of a system. It sets the scope and calls out estimated impact on business practices and means for evaluation. The vision statement helps to identify associated users and goals and how they will interact independently with each other and with the application.

3.4 Work domain analysis 3.4.1 Description Work domain analysis involves the development of causal models that clarify cause and effect relationships between an overall system, its subsystems and their constituent components. This model is a field description based purely on the environment constraints imposed on a system that dictates its functionality. These may be physical laws (e.g. thermodynamics), legal regulations (e.g. gas emissions) or management targets. A work domain model is event independent. It defines the system purposes at multiple levels of abstraction but does not describe events or user actions carried out during work.

3.4.2 Knowledge gathering techniques The first stage to developing a work domain model is gathering information about the system. This is sometimes described as a bootstrapping exercise (Hoffman, 2005). The vision statement should provide enough information to start to investigate the relevant infrastructures, control systems and organisations that support the work.

3.4.2.1 Document analysis Documentation gathering and analysis is usually an early step in the process. Useful documents include org charts, training material, operations reports, CAD drawings, process diagrams, software manuals & technical papers. During analysis keywords, themes and relationships should be identified and recorded. Documentation analysis should suggest the reasoning of domain practitioners, leverage points in terms of opportunities and is useful in the attempt to construct knowledge models. This activity also provides the basic knowledge and vocabulary needed to be able to communicate with the target domains subject matter experts and end users.

3.4.2.2 Exploratory interview Exploratory interviews with domain experts can be used to identify important high level goals and subsystems that support them. An unstructured interview approach is generally required

Project - No 260018

Date 10.12.10



during initial meetings, as concepts about system functionality are being formed and normalised. These interviews may be facilitated through mind mapping exercises (Buzan & Buzan, 1994). However, it is important to focus on the functionality of the whole system rather than the tasks of individual actors at this early stage of the analysis.

3.4.3 Modelling tools The vision statement describes the business need for an application framework. This can be thought of as the highest level functional purpose of a system. This functional purpose is associated with the entire system but is achieved through a number of abstract functions associated with constituent subsystems. These in turn have lower level components that have purposes at a lower level of abstraction. A number of different modelling techniques can be used to extract these causal relationships within a work domain.

3.4.3.1 Abstraction hierarchy Abstraction hierarchies are particular types of hierarchy that describes means-ends conceptual relationships (Figure 15). Representing a functional system in these terms highlights the cause & effect relationships that are necessary to conduct system diagnosis and decision support (Rasmussen, 1985).

Figure 15. Types of Hierarchies

The number of levels of functional abstraction depends on the complexity of the system, but five levels have generally been found to be appropriate (Bisantz & Vicente, 1994). These levels have been described as functional purpose, abstract function, generalised function, physical function and physical form. Figure 16 shows a simple abstraction hierarchy applied to a car. This example demonstrates that the abstraction hierarchy takes a perspective on system functionality rather than attempting to model a comprehensive description. For example another functional purpose could be to transport people economically. The inclusion of this goal may introduce new sub-goals and change the arrangement of the model.

Project - No 260018

Date 10.12.10



Figure 16. An abstraction hierarchy of a car (Burns & Hajdukiewicz, 2004)

Figure 17 shows an abstraction hierarchy associated with a manufacturing line. This shows how the functional purpose of Manufacturing Product can be decomposed into more generalised functions associated with subsystems of the line until we arrive at functions associated with physical components of the overall line (e.g. regular tool maintenance). The model highlights both causal links (vertical) and goals that need to be correlated or which may be conflicting (horizontal). Often this goal balancing requires flexible human decision making to resolve conflicts.

Project - No 260018

Date 10.12.10



MFG 4.1 MFG 4.5

Low WIPon Hold

Match Wip to Tools

Proportionally

Build Batches MFG 5.2

Regular Tool Maintenance

High Availability

High Tool Usage

MFG 3.4High

Production Rate

MFG 3.1

MFG 5.1

Low Inventory

Maintain Speed of WIP

Maintain Spread of WIP

SatisfyCustomers

Manufacture Product

MinimiseBottlenecks

MFG 4.2 MFG 4.6

Causal Relationship

Correlations or Conflicts

MFG = ManuFacturing Goal** Some elements of the model have been hidden for IP reasons

Figure 17. Abstraction hierarchy of manufacturing line

Abstraction hierarchies can be easily developed using diagramming software such as Microsoft Visio. Other Mind mapping software that supports the spatial arrangement of directed graphs can also be used.

3.4.3.2 Abstraction decomposition space An abstraction decomposition space is an adaptation of the abstraction hierarchy that can be used to support work domain analysis involving physical systems. It combines a means-ends functional abstraction hierarchy with a part-whole physical decomposition of a system (Figure 18). These two hierarchies are placed orthogonally in a matrix, essentially mapping function to form at different levels of granularity. The configuration makes the causal relationships between system, sub-systems and components more explicit. Some work domains may not involve the control of a physical system (e.g. finance, design, HR etc.) or the physical system may be complex to decompose making it difficult to construct an ADS. In these cases it may be necessary to annotate an abstraction hierarchy to indicate structural or organisational aspects of the system (Figure 19.). Abstraction decomposition spaces have a matrix layout and can be developed using Microsoft Excel. However as they become more detailed it is often easier to switch to a diagramming application like Microsoft Visio that gives more control over spatial layout.

Project - No 260018

Date 10.12.10



Figure 18. Relationships in an ADS (Vicente, 1999)

Figure 19. Annotated Abstraction Hierarchy (Upton & Doherty, 2010)

3.4.3.3 Concept Mapping Concept maps are diagrams that are used to represent and convey knowledge (Figure 20). Although concept maps are not part of the original CWA framework, they provide a useful tool for understanding constraints in less structured work environments. They have been used to elicit and structure expert knowledge in a range of domains including weather analysis, emergency response teams and military command and control (Crandall et al.,

Project - No 260018

Date 10.12.10



2006). They consist of two structures: Concepts (usually boxed nodes) and Relationships (labelled edges that link concepts).

Figure 20. Concept Map (Crandall et al., 2006)

Although the form of the diagram looks generic, Concept Maps have a number of attributes that make them different from other knowledge mapping techniques:

- Expressiveness: The labelling of links is a critical feature of concept mapping. While other diagrams allow for unlabeled links or impose strict predefined syntaxes, concept mapping requires the analyst to explicitly describe the nature of relationships between concepts using everyday terms;

- Shape: The most critical concept is always located at the top of the diagram and is broken down into associated concepts from top to bottom. This is different from other knowledge mapping techniques, (e.g. semantic networks) where concepts can radiate out from the centre. This vertical decomposition is useful as it supports the later construction of abstraction hierarchies;

- Shape-Meaning Interaction: In complex domains components can have a many to many relationship. Rather than a straightforward decomposition of concepts, this approach permit cross-links to highlight such interactions and dependencies;

- Dynamics: Concept mapping should be considered a process rather than an artefact. Concept maps provide a medium for engaging with subject matter experts and modelling their knowledge. As such, a Concept Map is never truly complete but rather it reflects an understanding at a point in time. The concept map or maps produced after a session can be validated with other experts and can be used to document the session.

Project - No 260018

Date 10.12.10



Concept Maps can also be developed using generic diagramming software like Microsoft Visio. A custom concept mapping tool has been developed by the Institute for Human and Machine Cognition (IHMC) and can be downloaded here: http://cmap.ihmc.us/Download/index.php. Again, other mind maps may be used but it is essential that these can support the attributes of expressiveness, shape and shape-meaning interaction described above.

3.4.4 Summary - The outputs of work domain analysis should be a model (or models) of a work domain

that maps functional relationships in terms of system constraints; - Depending on whether the targeted domain involves control of a physical system or

knowledge work/analytics it may be more suitable to use an abstraction hierarchy or process map respectively;

- Work domain modelling should be seen as an iterative process where early models are reviewed with subject matter experts and repeatedly refined until they are considered to be valid representations;

- Depending on the complexity of the system it may be necessary to develop multiple work domain models that focus on different perspectives or levels of abstraction.

3.5 Control task analysis 3.5.1 Description Control task analysis identifies the information transformations that are required to control a functional system. While work domain analysis focuses on system constraints and causal relationships, control task analysis focuses on system events and information processing. It differs from other forms of task analysis in that it focuses on what and why information processing occurs rather than by whom and how. This approach is agent independent; in that it identifies the information processing that must occur without referring to whether this is conducted by a human or automated controller. A modelling tool called the Decision Ladder is used to trace how this can occur.

3.5.2 Knowledge gathering The document Analysis conducted in the previous phase should have provided a rich understanding of the functional purpose of the domain under study. In this phase we focus of how this functional purpose is achieved. This is generally achieved through interviews with subject matter experts.

3.5.2.1 Expert Interview Interviews with system users and owners are the most efficient means of gaining knowledge about system events and responses. A semi-structured interview process is recommended where participants are posed open-ended questions. An interview template is provided to guide the analyst through a number of important topics including:

1. Goal 2. Contradictions 3. Tool use 4. Working with others 5. Internalise 6. Externalise

Project - No 260018

Date 10.12.10



7. Help 8. Life cycle 9. Change

Where possible interviews should be recorded and transcribed to allow for detailed analysis of the subject matter. Where this is not possible it is recommended interviewers work in pairs with one leading the questions and the other responsible to note taking. Sketching of process flows, decision ladders and interfaces by both interviewers and interviewees is encouraged and these artefacts should be documented.

3.5.3 Modelling tools 3.5.3.1 The Decision Ladder The Decision Ladder can be used to model the decision-making process involved in controlling a system (Figure 21). The left hand side of the ladder represents the information processing activity (both human and automated) associated with evaluating a systems state while the right hand side shows the information processing activity involved in executing a response. The decision ladder uses two structures to model cognitive activity:

- Information Processing: - States of Knowledge:

Information processing transforms data into higher-level information, which can be evaluated against the expected system state at a particular level of abstraction. Common and routine events require relatively little cognitive work as a user will quickly develop the skills to match an alert about a state with a suitable response. This is represented as a cognitive leap across the ladder without having to evaluate the system state against higher level goals. These situations often have sufficient structure to be codified and handled by an automated agent/controller. Less frequent events will require additional information processing as a controller will need to search for an existing rule that defines the appropriate response. Novel or unanticipated events generally require further information processing where the state of a subsystem needs to be evaluated against the overall system goals. Often this will require deep knowledge of the causal relationships identified in the work domain model. In this way causal reasoning can be understood as a progression up through the decision ladder as an agent moves from skills to rules to knowledge based behaviour.

Project - No 260018

Date 10.12.10



Figure 21. The Decision Ladder

Figure 21 shows the basic structure of the decision ladder. In practice, each information processing box must be annotated with details of the specific processing activity and data sources. Figure 22 presents an example of a decision ladder applied to a manufacturing scheduling control task. In this example information processing is described by the production rules or strategies numbered 1-17 in the diagram. The details of each of these strategies can be found in (Sanderson, 1991). The decision ladder allows an analyst to identify where different strategies need to be applied. How these strategies get applied is investigated in the next phase of the analysis. While it may be possible to automate some of these strategies, the decision ladder identifies where the outputs of this information processing is required to understand the system state. This allows the analyst to identify areas with high cognitive workload and opportunities for developing artefacts (e.g. visualisations) to reduce cognitive workload and increase situation awareness.

Project - No 260018

Date 10.12.10



Figure 22. Decision Ladder for the Model Human Scheduler (Sanderson, 1998)

Figure 23 demonstrates a control task analysis applied to our worked example. In the work domain analysis phase bottleneck identification was revealed as a key functional goal associated with line management. The analysis shows how the control task associated with bottleneck management is divided between manufacturing supervisors and line managers. A decision ladder is generated for each actor and the annotations describe how they each transform the information to gain higher level knowledge about the system state. As well as describing individual cognitive work the use of two decision ladders allows us to identify where knowledge about the system state is transferred between actors. This contextual information is important as it allows us to identify the information needs of different users associated with the system. As decision ladders are used to model causal reasoning about events it is necessary to develop separate decision ladders for each critical event associated with the system. Decision Ladders can be developed using standard diagramming applications such as Microsoft Visio.

Project - No 260018

Date 10.12.10



Figure 23. Decision Ladders showing distributed cognitive workload

3.5.4 Summary - The outputs of control task analysis is a series of annotated decision ladders that map

the information processing associated with key events; - Interviews are the primary means of understanding how events occur; - As with work domain modelling, control task analysis should be seen as an iterative

process where early models are reviewed and repeatedly refined until they are considered to be valid representations.

3.6 Strategies analysis 3.6.1 Description While control task analysis defines what information processing needs to occur at a high level, strategies analysis describes how outputs are achieved in reality. As complex systems can involve coupling and dependencies between components there can often be multiple ways to complete a task. Models of strategies are used to show specifically how an output is achieved (Figure 24). The analysis should also explain why certain strategies are preferred over others in specific contexts. As well as documenting current activities, strategies analysis can be used to identify situations where automated information processing or visual encoding can reduce cognitive workload for end users.

Project - No 260018

Date 10.12.10



Figure 24. Control Task Analysis & Strategies Analysis (Vicente, 1999)

3.6.2 Knowledge Gathering Many organisations have already documented their common strategies. Where strategies are highly structured they have often been fully codified and automated. Where strategies remain under human control they have often been documented in the form of Standard Operating Procedures (SOPs), Response Flow Checklists (RFCs), and Best Known Methods (BKMs). While these can provide a useful starting point for analysis it is important to note that SOPs and BKMs may not be rigidly adhered to during real world operations. Workers frequently need to adopt new strategies to cope with unexpected events in their work. This is why observations and interview with end workers is so critical. It is also generally advised not to show workers the predefined strategies (SOPs, RFCs a, BKMs etc.) before or during interviews as this can bias their reporting of how work actually happens.

3.6.2.1 Interviews Interviews can be conducted with end users to identify the strategies they apply to problem solving in their domains. An interview template has been provided in the toolkit.

3.6.2.2 Observations Observation is another key knowledge gathering technique. Observing how work happens provides contextual information that may not be gathered or reported through interviews. This contextual information includes details about the work environment (e.g. lighting, noise, collaboration, mobility etc) that are necessary to inform the design of end user interfaces. Most modern work environments involve interaction with software and this can provide a useful starting point for analysis. An application walkthrough is an activity where a user demonstrates how they achieve a key task using their existing IT systems. It is

Project - No 260018

Date 10.12.10



recommended that a think aloud protocol is followed whereby the user talks through their thought process as they interact with the system. This allows the analyst to identify where expert tacit knowledge, which is not embedded in the user interface, is applied. It is advised to record these sessions for detailed post hoc analysis. Cam Studio is free open source software that allows you to record screen interactions with audio and is an excellent tool for supporting this work (camstudio, 2010).

3.6.3 Modelling tools 3.6.3.1 (Information) Process Mapping Process mapping is a well established practice across many engineering disciplines. At a very basic level process maps consist of a series of boxes and arrows are used to describe processes and flows respectively. These can be augmented with objects, decision points and other artefacts. While many forms of process mapping exist, differences generally relate to syntax which is often customised to suit different application areas.

Figure 25. Information Process Flow associated with bottleneck evaluation

Figure 25 shows an information flow map associated with our worked example. This shows the activity associated with evaluating the severity of an inventory bottleneck in the context of the overall line.

3.6.3.2 Information Flow Maps Within the original cognitive work analysis framework, information flow maps (Figure 26) are used to conduct strategies analysis. Information Flow Maps (IFMs) are graphical

Project - No 260018

Date 10.12.10



representations of the information processing activities and knowledge states of particular strategies. This modelling technique is not as well developed at the decision ladder or abstraction hierarchy but it still provides a useful method for formally describing the selection of a given strategy. As IFMs visually map each of the strategies identified for a given task, this allows them to be compared with representations of other strategies. IFDs are accompanied by a verbal description of each strategy being deployed.

STRATEGIES ANALYSIS

REROUTING TASK

IF 2.7.1

Topo Map of Airspace

AC Perf Model

Prpsd AC Flight

Paths

Determine Hold Location

for 1 AC

Choose 1 AC

to Hold

PrioritiesModel

Hold Location(1 AC)

Strategy 3: Tweaking One AC

Strategy 2: Rerouting One AC

AC Perf Model

UpdatedPath

(1 AC)


Choose 1 AC

to Tweak

Monitor Flight Status and Evaluate Path

for 1 AC

PrioritiesModel

Determine Flight Path Update

for 1 AC

Prpsd AC Flight

Paths

Strategy 1: Holding One AC

Choose 1 AC

to Reroute


External ACFlt Paths

Prpsd AC Flight

Paths

PrioritiesModel

AC Perf Model

ReroutePath

(1 AC)

Determine Reroute Path

for 1 AC

Figure 26. Information Flow Map applied to air traffic control strategy (Kilgore et al., 2008)

Project - No 260018

Date 10.12.10



3.6.3.3 IDEF Another option is to deploy the IDEF modelling approach to the generation of process maps. IDEF focuses primarily on function modelling. It is generally applied to understanding causal relationships in the same manner as work domain models. IDEF3 provides a Process Description Capture Method that lends itself well to describing sequences of activities and transformations and can be applied to strategies analysis (Figure 27 and Figure 28). IDEF3 provides a number of modelling formats including process description and state transition. The example below shows these modelling formats applied to an industrial painting process. More details on these techniques are available at http://www.idef.com/IDEF0.htm

Figure 27. IDEF3 Process Description Diagram

Figure 28. IDEF3 Object State Transition Network Diagram

Process maps can be developed using standard diagramming applications such as Microsoft Visio. A wide range of other commercial tools are also available.

3.6.4 Summary - Strategies analysis describes information processing in detail and identifies the actors

or automated agents who carry out this work;

Project - No 260018

Date 10.12.10



- Process flow maps, information flow maps or IDEF3 diagrams are all suitable modelling techniques for conducting this work.

3.7 Requirement specification 3.7.1 Functional specification 3.7.1.1 Description Requirements Specification aims to integrate the output from all previous phases of the analysis into a format that is interpretable to a software engineering audience. Requirement specification is frequently described as the first stage of software engineering. This is acceptable in domain specific ICT projects, where the targeted end users can be easily identified and the business requirements are well understood. However when engaging with large complex systems that feature multiple users and an evolving work environment, the previous phases are vital to clearly identify the core functionality to be supported. Modelling techniques to support this phase include scenarios, UML diagrams (use case, class, sequence & activity), and information specification templates.

3.7.1.2 Knowledge integration The models generated by the previous phases provide detailed information about the systems functionality that provides the raw material for populating standard requirements analysis models. The work domain model decomposes the system and supports the definition of objects within UML diagrams. In addition, the functional abstraction hierarchy supports the identification of attributes that can be associated with these objects. The control task analysis focuses on critical events. In this manner it can inform the development of high level use case scenarios and activity diagrams. The strategies analysis identifies how information processing occurs and by whom. As a result these analyses can support the development of more detailed use cases focussed on specific users. The detailed descriptions of strategies can also inform the development of information processing algorithms.

3.7.1.3 Modelling tools The Unified Modelling Language (UML) is a standard language for specifying, visualising, constructing, and documenting the artefacts of software systems, as well as for business modelling and other non-software systems (Fowler, 2003), (Jacobson et al., 1998). UML represents a collection of best engineering practices that have proven successful in the modelling of large and complex systems (Braun et al., 2001). UML diagrams represent two different views of a system model:

- Static (or structural) view: emphasizes the static structure of the system using objects, attributes, operations and relationships. The structural view includes class diagrams and composite structure diagrams;

- Dynamic (or behavioral) view: emphasizes the dynamic behavior of the system by showing collaborations among objects and changes to the internal states of objects. This view includes sequence diagrams, activity diagrams and state machine diagrams.

UML 2.2 has 14 types of diagrams divided into two categories. Seven diagram types represent structural information, and the other seven represent general types of behavior, including four that represent different aspects of interactions. E.g. Use case diagrams represent the functionality of the system from a users point of view (Figure 29). Class

Project - No 260018

Date 10.12.10



diagrams represent the structure of the system. An activity diagram shows the control flow within a system. Sequence diagrams represent the behavior as interactions.

Figure 29. Use Case Diagram

Requirement Specification Templates are used to document the outcomes of this phase. These are a series of forms that describe requirements associated with different use cases.

3.7.1.4 Viewpoint Definition template The proposed Viewpoint Definition template (Table 2) enables to map PLANTCockpit viewpoints. This step will provide some useful inputs for requirements analysis and later for views definition (MVC technology) in PLANTCockpit. The meaning of the template fields is described as below:

- Viewpoint ID: each viewpoint is uniquely identified in conventional manner; - Viewpoint name: every viewpoint is defined by a descriptive name in order to facilitate

identification; - Business domain & impact: domain related to the product lifecycle where end-user is

involved and impact that the implementation of the project will have on business practices;

- Purpose (needs & goals): business needs and goals to be achieved; - Actors: persons and systems who will be involved; - Role: describes the role of the actors; - Relationships between roles: relationships between the different roles and their

individual contribution to the business needs as stated above; include other relevant roles who may not be direct users of the system. RIO (Role Interaction Organisation) diagrams may be used for this activity (Monticolo et al., 2006);

- Related requirements: this field allows to link viewpoint with requirements;

Viewpoint ID should contain enough information to properly describe the contents of the document. However, keeping title short will help users and developers to quickly identify and retrieve accurate information. To facilitate sorting, a consistent separator between naming elements is proposed (_). The following rule aims to well-balance the use case ID through the type of PLANTCockpit application (A1 for W8, A2 for W9 and A3 for W10), the end-user

Project - No 260018

Date 10.12.10



name and a number:

VP___

Example: VP_A1_BMW_001 or VP_A1A2_BMW_001

Table 2: Viewpoint definition table

Viewpoint definition

Viewpoint ID

Viewpoint name Business domain & impact

Purpose (needs & goals)

Roles

Actors

Relationships between roles

Related requirements

3.7.1.5 Requirement table Here, we propose to consider three templates for the first phase of requirements elicitation such as Viewpoint Definition, Requirement Specification, and Use Case Template. Given that requirements elicitation phase can be considered as a collaborative work, it is also important to consider the various stakeholders viewpoints related to PLANTCockpit issues (as described in DoW). Thus, it will be easier to analyze requirements through identified purposes and concerns of all end-users. In the following sections, each proposed template is described in order to provide a full understanding of the reader, and to help requirements to be expressed and structured in a fixed and reusable form.

The proposed Requirement Specification template (Table 3) enables to elicit technical and functional requirements which should be addressed in PLANTCockpit. The meaning of the template fields is described as below:

- Requirement ID: each requirement is uniquely identified in conventional manner. - Requirement name: each requirement is identified by a descriptive name.

Project - No 260018

Date 10.12.10



- Version & Date: during requirement elicitation process different versions of requirements must be managed. This field contains the current version number and date of the requirement.

- Author: this field contains the name of the author of the current version of the requirement.

- Category: this field characterizes the area of requirements: business model, software, etc.

- Source: this field contains the organization of the author, i.e. user or customer. - Purpose: this field states why the requirement is necessary to achieve business goals. - Description: this field describes what the system shall do. - Specific data: this field holds a list of specific data associated to the relevant concept. - Time interval: this field indicates how long information about the concept is relevant

for the system. It can take two values: Past and Present if information is always relevant, and Present only if information has a valid period of time.

- Comment: this field contains additional information about the requirement that cannot be fitted in previous fields.

- Related requirements: this field enables the link of current requirement with others. - Domain instance: this field allows knowing if the requirement can be considered as a

generic requirement. - Classification: this field indicates how important the requirement is for end-user in

terms of priority and difficulty. It can be assigned an expression such as High, Medium or Low.

- Status: this field holds the status of the requirement in the validation process. It can be assigned an expression such as Draft, Reviewed, and Approved.

- Concerned VP: this field allows to link requirements with viewpoints.

Note:

Requirement ID should contain enough information to properly describe the contents of the document. However, keeping title short will help users and developers to quickly identify and retrieve accurate information. To facilitate sorting, a consistent separator between naming elements is proposed (_). The following rule aims to well-balance the requirement ID through the type of PLANTCockpit application (A1 for W8, A2 for W9 and A3 for W10), the end-user name and a number:

RQ___ Example: RQ_A1_BMW_001 or RQ_A1A3_BMW_001

Project - No 260018

Date 10.12.10



Table 3: Requirement specification table

Requirement specification

Requirement ID

Requirement name Version & Date Click here to enter a date. Author

Category Classification High Medium Low

Source Priority

Difficulty

Purpose

Description

Specific data

Time interval Past and Present Only present

Comment

Related requirements

Domain instance

Status Draft Reviewed Approved

Related Viewpoints

Project - No 260018

Date 10.12.10



3.7.1.6 Use case template A use case diagram is a technique for capturing the potential requirements of a new system like PLANTCockpit. It describes how the system should interact with the end-users or another system to achieve a specific business goal. Table 4 presents the use case table. To aid end-users to make use case tables and diagrams, some elements are described below:

- Use case ID: each use case is uniquely identified in conventional manner. - Use case name: the use case name provides a unique identifier for the use case. It

should be written in the verb/noun format and should be sufficient for the end-user to understand what the use case is about;

- Pre-condition: a pre-condition section is used to convey any conditions that must be true when a user initiates a use case. They are not however the triggers that initiate a use case;

- Actor: actors are parties outside the system that interact with the system; an actor can be a class of users, roles that users can play, or other systems;

- Triggers: the triggers section describes the starting conditions which cause a use case to be initiated;

- Primary flow: at a minimum, each use case should convey a primary scenario, or the typical course of events. The main basic course of events is often conveyed as a set of usually numbered steps;

- Post-condition: the post-condition section summarizes the state of affairs after the scenario is complete.

Note:

Use case ID should contain enough information to properly describe the contents of the document. However, keeping title short will help users and developers to quickly identify and retrieve accurate information. To facilitate sorting, a consistent separator between naming elements is proposed (_). The following rule aims to well-balance the use case ID through the type of PLANTCockpit application (A1 for W8, A2 for W9 and A3 for W10), the end-user name and a number:

UC___

Example: UC_A1_BMW_001

Project - No 260018

Date 10.12.10



Table 4: Use case table

Use case

Use case ID

Use case name

Purpose

Actor

Pre-conditions

Triggers

Primary flow

Post-conditions

3.7.2 Technical specification The objective of this phase is to provide guidelines to identify and document technical requirements for PLANTCockpit in consistency with the specified functional requirements in tables and use cases but also through the concept maps. The goal of the technical requirements identification and documentation aims at providing a state of the art of information systems and interfaces used in the partners plants. The reason this has to be performed is to allow the interconnection of PLANTCockpit with all relevant systems at the partners sites. To ensure this, a table (Table 5) has been devised that captures the following information:

- Identifier of the technical system: Each system is uniquely identified for all of the project by way of ID convention;

- Name of the technical system: The name with which the system is usually addressed should be put here, to allow re-identification in other plants and processes;

- Allocation in the automation pyramid: Here it needs to be specified what role the system fulfils in the automation pyramid, e.g. if it is ERP, MES or SCADA;

- Provided interfaces: In order to gather information stored in the system, any interface for data exchange on a technical level provided by the system needs to be mentioned and specified;

- Semantic information (function in the process): The semantic information is the description of the information stored in the described system. This description needs to be exhaustive and needs the most care, because it sets the field for later integration;

- Associated requirements: The identifiers for every functional requirement that can be covered by the system have to be captured in order to interconnect it once information may have been integrated into PLANTCockpit.

Project - No 260018

Date 10.12.10



Table 5: Technical requirement table

Technical requirements

Technical requirement ID

System name

Allocation in pyramid

Provided Interface Semantic information

Associated requirements

3.7.2.1 Definition of the application Define what the domain application is, describe its functionality, and state why this application is focused in PLANTCockpit (e.g. relate to business importance, environmental importance, development of new business areas) (Table 6).

Table 6: The concerned PLANTCockpit application

Application Describe functionality Describe why this Application is focused in PLANTCockpit

3.7.2.2 Objective of the application As background for the subsequent sections, list and describe all the objectives that are to be achieved by the PLANTCockpit application using Table 7. Describe the objective and why the objective is part of the PLANTCockpit application (ONE objective per ID).

Table 7: Objectives of the concerned PLANTCockpit application

ID Objective (one per ID) Describe why OB1 OB2 OB3

3.7.2.3 Involved actors in the application Define and describe the involved actors who will be affected by the PLANTCockpit application using Table 8. Include actors both externally (e.g. transportation company, user, service organizations, recycler, authorities), and internally (e.g. design department, production planners, workers).

Project - No 260018

Date 10.12.10



Table 8: Involved lifecycle actors of the concerned PLANTCockpit application

ID Actor External / Internal

Describe how they will be involved, their role and impact of the PLANTCockpit technology

Importance / Relevance High, Medium, Low

AC1 AC2 AC3

3.7.2.4 Physical components considered in the application Define all of the PLANTCockpit applications physical components, their functionality, and their relation to the Application objectives using Table 9 (i.e. how does the inclusion of this component contribute to fulfilling the objectives defined previously in this document). Indicate also if the component is to be Included in the PLANTCockpit application, if it is Optional (i.e. could be omitted, but would be nice to have), or Not if it is not to be included.

Table 9: Physical components of the concerned PLANTCockpit application

ID Physical component

Describe functionality

Relation to Application objectives

Focus in PLANTCockpit Included, Optional, Not

PC1 PC2

3.7.2.5 The application software/support-systems Describe the software/support-systems of the application (e.g. ERP, MES, decision support systems) that are part of the whole PLANTCockpit Application by using Table 10. Describe functionality of the systems and indicate if the system is to be: Included (must be included in the work of PLANTCockpit); Optional (may be included, but not necessary in order to fulfil the objectives defined previously, Not (not to be included).

Table 10: Support systems / other systems external of the concerned PLANTCockpit application

ID Software / support systems

Describe functionality

Relation to Application objectives

Focus in PLANTCockpit Included, Optional, Not

SS1 SS2

Project - No 260018

Date 10.12.10



3.7.2.6 Description of the functionality of the application In this section, all necessary functionalities of the application are to be defined according to Table 11. This is an important summary of the functionality of the Application. Be as specific as possible in this table as this forms the basis for development of the PLANTCockpit technology and support systems. The input in this table forms the basis for making IDEF diagrams of the functionalities. It is therefore required to add enough information in order to fulfil the requirements of IDEF diagram. Every functionality should at least have one control, one input, one output, one technology/system/actor.

Table 11: Functionalities of the concerned Application

ID Functionality Requirement(s) Define the inputs needed to achieve this functionality and relate the input to other FU IDs (e.g. output data from FU3)

Define the outputs from this functionality

What are the controls

Technologies/Systems/Actors involved Describe the technologies involved, or assumed technology/systems needed

Rationale Describe why this functionality is needed

Priority High, Medium, Low

Related to objective ID (

FU1 FU2

Project - No 260018

Date 10.12.10



3.7.2.7 Information flow modelling template and guide (Swim lane) In this section, with the proposed modelling templates, PLANTCockpit end-users will be able to provide workflow and information flow models with collaboration with other partners in order to consolidate their models for PLANTCockpit applications.

3.7.2.7.1 Description of basic symbols of event and information flow modelling templates

The proposed description of event and information flow consists of basic modelling components such as process, Boolean operators and information symbols.

Table 12: Basic symbols for workflow and information modelling

Modelling components

Symbol Description

Process

text: Arial 10pt

It indicates a business processing unit that has an explicit role. It will be initiated by input events and produce output events. In the data aspect, it requires inputs for its execution and makes outputs as the result of the execution.

Event

text: Arial 10pt

It indicates the change of state that takes place as a result of a process.

Information

text: Arial 10pt

It is a set of data objects which have similarity in their semantics.

Operators V

OR operator

V

AND operator

XOR

XOR operator

Link Workflow

Information flow

Project - No 260018

Date 10.12.10



3.7.2.7.2 Event process chain diagram for workflow modelling The proposed modelling approach is based on discrete process modelling method. Event-driven process chains are an intuitive graphical business process description language. The language is targeted to describe processes on the level of their business logic, not necessarily on the formal specification level, and to be easy to understand and use by PLANTCockpit partners. Modelling template (Swim lane): This template enables (Figure 30) the end-user to define event process chain, using previously described symbols through the main elements of the system architecture (columns). A process consists of sequences of events triggering business functions, which are themselves the results of other functions apart from initial events triggering the whole process. By introducing Boolean operators, the event-driven control structure can be expanded to a complex control flow illustrating business relevant decisions.

Project - No 260018

Date 10.12.10



Figure 30. Swim lane template

Device controller PDKM system

Design knowledge

experts...DSSPEID

E2

E5

V

E8

P2

P3

E6

E1

P4

E3

V

XOR

E7

E4

P1

Condition 1

Condition 2

Condition 3

Condition 4

Project - No 260018

Date 10.12.10



Guideline:

- Please think of columns of the swim lanes in your application. They must correspond to the main elements of the system architecture;

- Please consider the flow of information in your application, i.e. from data gathering to analysing to decision and feedback. Based on them, describe necessary events and processes.

Remarks:

- If possible, please use the Microsoft Visio modelling template. If it is not possible to use Microsoft Visio, please use Microsoft PowerPoint. In that case, please keep in mind to follow the same font and size and symbols of modelling components;

- Consider not only system aspects but also human interactions in considering the column of swim lane;

- As much as you can, please describe the workflow modelling in detail. It will be helpful to not only you but also other partners;

- Do not duplicate information or processes in the diagram.

3.7.2.7.3 Information flow diagram for information flow modelling Information flow modelling is a technique that allows a formal description of a domain of interest to be defined. The resulting information model may be used for many purposes, including helping to improve the understanding of the domain, or providing a basis for implementation. Here, an information flow diagram (Figure 31) is proposed including previously described symbols.

Modelling template:

Figure 31. Information flow diagram

Guideline:

- Please reuse processes that are defined in the workflow modelling; - Please describe necessary information for each process: input and output;

Project - No 260018

Date 10.12.10



- Please think of links of this information with processes. If necessary, you can define necessary processes more in your diagram (in this case, you should modify the workflow modelling diagram).

Remarks:

- Do not duplicate same information or processes in the diagram; - As much as you can, please describe the information flow modelling in detail. It will be

helpful to not only you but also other partners; - Please represent the link between processes with a dotted arrow.

3.7.3 Summary - Requirements specification aims to integrate the output from all previous stages in the

analysis process together and puts forward a full description and understanding of what you want the system to do. The goal hierarchy model features a set of observations which are evaluated by the end user (Line Manager) in order to rank and rate certain constraints within the system in order of priority. Factors influencing the order of priority on constraints are represented in more detail in the subsequent control flow diagram. These are then mapped into a partial set of basic user/system interactions and use cases as defined in the final UML use case diagram which represents the system, its actors (users, external data sources as well as any other entities whose behaviour the system cannot control or change);

- UML is often the modelling tool of choice for Requirement specification, there are various commercial and open source offerings available.

The relationship between models across the CWA phases is represented in Figure 32 below; it shows each phase of the analysis process and how the relevant templates have been applied to the manufacturing case study as described in previous section of the document. It shows the mapping between each phase of the CWA process. Progression through the CWA process is iterative in nature, as more knowledge is discovered, the number of artefacts and models will increase in line with this, which results in a full understanding of the functional requirements of the system.

Project - No 260018

Date 10.12.10


PLANTCockpit D2.1 Public

Documents

Transcript of PLANTCockpit D2.1 Public