1 Descriptions of Function

peanutplausibleΗλεκτρονική - Συσκευές

21 Νοε 2013 (πριν από 3 χρόνια και 8 μήνες)

76 εμφανίσεις

peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

1

11/21/2013

N
N
a
a
m
m
e
e


o
o
f
f


D
D
o
o
m
m
a
a
i
i
n
n


T
T
e
e
m
m
p
p
l
l
a
a
t
t
e
e


1

Descriptions of Function

All prior work (intellectual property of the company or individual) or proprietary (non
-
publicly available) work should be so noted.

1.1

Function Name

Name of Function

1.2

Function ID

Identification number of the fu
nction

1.3

Brief Description

Describe briefly the scope, objectives, and rationale of the Function.

1.4

Narrative

A complete narrative of the Function from a Domain Expert’s point of view, describing what occurs when, why, how, and under w
hat conditions.
This will

act as the basis for identifying the Steps in Section 2.

All actors should be introduced in this narrative. All sequences to be described in
section 2 should be introduced in prose here. Embedded graphics is supported in the narrative.

1.5

Actor (Stakeholder)

Roles

Describe all the people (their job), systems, databases, organizations, and devices involved in or affected by the Function (
e.g. operators, system
administrators, technicians, end users, service personnel, executives, SCADA system, real
-
time databa
se, RTO, RTU, IED, power system).
Typically, these actors are logically grouped by organization or functional boundaries or just for collaboration purpose of t
his use case. We need
to identify these groupings and their relevant roles and understand the con
stituency. The same actor could play different roles in different
Functions, but only one role in one Function. If the same actor (e.g. the same person) does play multiple roles in one Functi
on, list these different
actor
-
roles as separate rows.

peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

2

11/21/2013

Grouping (
Community)
,


Group Description



Actor Name

Actor Type (person,
organization,
device, system
, or subsystem
)

Actor Description










Replicate this table for each logic group.

1.6

Information exchanged

Describe any information exchanged in this t
emplate.

Information Object Name

Information Object Description





1.7

Activities/Services

Describe or list the activities and services involved in this Function (in the context of this Function). An activity or serv
ice can be provided by a
computer sy
stem, a set of applications, or manual procedures. These activities/services should be described at an appropriate level, wit
h the
understanding that sub
-
activities and services should be described if they are important for operational issues, automation n
eeds, and
implementation reasons. Other sub
-
activities/services could be left for later analysis.

Activity/Service Name

Activities/Services Provided



peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

3

11/21/2013

Activity/Service Name

Activities/Services Provided



1.8

Contracts/Regulations

Identify any overall (human
-
initiated) contracts, regulations, policies, fin
ancial considerations, engineering constraints, pollution constraints, and
other environmental quality issues that affect the design and requirements of the Function.

Contract/Regulation

Impact of Contract/Regulation on Function




Policy


From Actor


May

Shall
Not

Shall

Description (verb)

To Actor

ProvideEnergy

ESP



X

Provide power on demand

Customer
















peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

4

11/21/2013

Constraint

Type

Description

Applies to

















2

Step by Step Analysis of Function

Describe steps that implement
the function. If there is more than one set of steps that are relevant, make a copy of the following section grouping
(
Steps to implement function,
Preconditions and Assumptions, Steps norma
l sequence, Post
-
conditions)

and provide each copy with its own
se
quence name.

2.1

Steps to implement function



Name of Sequence

Name of this sequence.

2.1.1

Preconditions and Assumptions

Describe conditions that must exist prior to the initiation of the Function, such as prior state of the actors and activities

Identify any assu
mptions, such as what systems already exist, what contractual relations exist, and what configurations of systems are probabl
y in
place

Identify any initial states of information exchanged in the steps in the next section. For example, if a purchase order
is exchanged in an activity, its
precondition to the activity might be ‘filled in but unapproved’.

Actor/System/Information/Contract

Preconditions or Assumptions



peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

5

11/21/2013

Actor/System/Information/Contract

Preconditions or Assumptions



2.1.2

Steps


Name of Sequence


Describe the normal sequence of events, focusing on steps t
hat identify new types of information or new information exchanges or new interface
issues to address. Should the sequence require detailed steps that are also used by other functions, consider creating a new
“sub” function, then
referring to that “subrout
ine” in this function. Remember that the focus should be less on the algorithms of the applications and more on the
interactions and information flows between “entities”, e.g. people, systems, applications, data bases, etc. There should be a

direct link be
tween
the narrative and these steps.

The numbering of the sequence steps conveys the order and concurrency and iteration of the steps occur. Using a Dewey Decima
l scheme, each
level of nested procedure call is separated by a dot ‘.’. Within a level, the s
equence number comprises an optional letter and an integer number.
The letter specifies a concurrent sequence within the next higher level; all letter sequences are concurrent with other lette
r sequences. The
number specifies the sequencing of messages in

a given letter sequence. The absence of a letter is treated as a default 'main sequence' in parallel
with the lettered sequences.

Sequence 1:

1.1
-

Do step 1

1.2A.1
-

In parallel to activity 2 B do step 1



1.2A.2
-

In parallel to activity 2 B do ste
p 2



1.2B.1
-

In parallel to activity 2 A do step 1



1.2B.2
-

In parallel to activity 2 A do step 2



1.3
-

Do step 3

1.3.1
-

nested step 3.1

1.3.2
-

nested step 3.2

Sequence 2:

2.1
-

Do step 1

2.2


Do step 2


peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

6

11/21/2013

#

Event

Primary Actor

Name of
Process
/Activity

Description of

Process/Activity

Information
Producer

Information

Receiver

Name of Info
Exchanged

Additional Notes

IECSA
Environment

#

Triggering event?
Identify the name
of the event.
1

What other actors
are primarily
responsible for the
Process/Activity?
Actors are defined
in section
1.5
.

Label that would
appear in a
process diagram.
Use action verbs
when naming
activity.

Describe the actions that take
place in active and present
tense. The step should be a
des
criptive noun/verb phrase
that portrays an outline
summary of the step. “If
…Then…Else” scenarios can
be captured as multiple
Actions or as separate steps.

What other actors
are primarily
responsible for
Producing the
information?
Actors are defined
in sec
tion
1.5
.

What other actors
are primarily
responsible for
Receiving the
information?
Actors are defined
in section
1.5
.

(Note


May leave
blank if same as
Primary Actor)

Name of the
information objec
t.
Information objects are
defined in section
1.6

Elaborate
architectural issues
using attached
spreadsheet. Use
this column to
elaborate details
that aren’t captured
in the spreadsheet.

Reference the
applicable IECSA
Environ
ment
containing this data
exchange. Only one
environment per
step.





















2.1.3

Post
-
conditions and Significant Results

Describe conditions that must exist at the conclusion of the Function. Identify significant items similar to that in the prec
o
nditions section.

Describe any significant results from the Function

Actor/Activity

Post
-
conditions Description and Results





2.2

Architectural Issues in Interactions

Elaborate on all architectural issues in each of the steps outlined in each of the seq
uences above. Reference the Step by number. Double click on
the embedded excel file


record the changes and save the excel file (this updates the embedded attachment).


FUTURE USE




1

Note


A triggering event is not necessary if the com
pletion of the prior step


leads to the transition of the following step.

peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

7

11/21/2013

2.3


Diagram

For clarification, draw (by hand, by Power Point, by UML diagram)
the interactions, identifying the Steps where possible.

FUTURE USE

3

Auxiliary Issues

3.1

References and contacts

Documents and individuals or organizations used as background to the function described; other functions referenced by this f
unction, or acting
as “
sub” functions; or other documentation that clarifies the requirements or activities described. All prior work (intellectual
property of the
company or individual) or proprietary (non
-
publicly available) work must be so noted.

FUTURE USE


ID

Title or conta
ct

Reference or contact information

[1]




[2]




3.2

Action Item List

As the function is developed, identify issues that still need clarification, resolution, or other notice taken of them. This
can act as an Action Item
list.

FUTURE USE

ID

Description

Status

[1]




peanutplausible_53ddabc1
-
9fee
-
49c4
-
896b
-
3e754b67b20e.doc

8

11/21/2013

[2]




3.3

Revision History

For reference and tracking purposes, indicate who worked on describing this function, and what aspect they undertook.

FUTURE USE


No

Date

Author

Description

0.