Extended Hierarchy State Transition Matrix Design Method
Version 2.0

Masahiko Watanabe
CATS 1997l Author's biography
Early 1980s: Engaged in VOSIII database language compiler and CAI.
Late 1980s: Engaged in the real-time monitor control system, RTOS.
Early 1990s: Engaged in ZIPC
Published papers and books
n Nikkei Electronics, "Real-time CASE Tools for Supporting Basic Design," January 6, 1992.
n CQ Shuppan Interface, "ZIPC for Real-Time Applications and System Development," May,
July, August, 1996.
n Electronics Development Institute Press, "CASE for Real-time Control"n Electronics Development Institute Press, "Implementing CASE in the Real-time
Environment"
n 53rd Convention of Japan Information Processing Society, "ZIPC: An Environment forDeveloping a Microcomputer Embedded System Using the State Transition Matrix"
n 53rd Convention of Japan Information Processing Society, "Definition of State Transition
Matrix Types: The Basic Concept"

The Extended-Hierarchy State-Transition Matrix Design Method, Version 2.0

February 12, 1997
Author: Masahiko Watanabe
Copyright CATS, 1997
Reproduction and copy without permission are prohibited.

Table of contents

1.
2.
3.
4.

Introduction....................................................................................................................... 1
Format of the state transition matrix (STM)........................................................................ 3
Format of the extended hierarchy state transition matrix (EHSTM) .................................... 5
Event ................................................................................................................................ 94.1. Event types................................................................................................................ 9
4.1.1
Variable memory event....................................................................................... 9
4.1.2
Interrupt event .................................................................................................. 10
4.1.3
In-mail event .................................................................................................... 12
4.1.4
Function-call event ........................................................................................... 13
4.2. How to access variables .......................................................................................... 14
4.2.1
Message event................................................................................................. 14
4.2.2
Flag event ........................................................................................................ 15
4.3. Mixed events ........................................................................................................... 16
4.4. Format of event cell ................................................................................................. 19
4.4.1
Event ............................................................................................................... 19
4.4.2
Event frame...................................................................................................... 19
4.4.3
Message event................................................................................................. 20
4.4.4
Flag event ........................................................................................................ 20
4.4.5
In-mail event .................................................................................................... 20
4.4.6
Interrupt event .................................................................................................. 22
4.4.7
Function-call event ........................................................................................... 23
4.4.8
Trigger event .................................................................................................... 23
4.4.9"else" event ...................................................................................................... 24
4.4.10 Event virtual frame ........................................................................................... 25
4.4.11
Event actual frame ........................................................................................... 26
4.4.12 "if" condition ..................................................................................................... 27
4.4.13 "switch" condition ............................................................................................. 29
4.4.14 Event-analyzer start activity .............................................................................. 31
4.4.15 Event-analyzer end activity............................................................................... 31
4.4.16 Event-hit start activity ....................................................................................... 31
4.4.17 Event-hit end activity ........................................................................................ 31
4.4.18 No action default/else ....................................................................................... 32
4.4.19 Analysis sequence number............................................................................... 33
5. State............................................................................................................................... 35
5.1. Exclusive state ........................................................................................................ 35
5.2. Concurrent state ...................................................................................................... 35
5.3. Format of state cell .................................................................................................. 37
5.3.1
State ................................................................................................................ 37
5.3.2
State frame ...................................................................................................... 37
5.3.3
Exclusive state ................................................................................................. 37
5.3.4
Concurrent state............................................................................................... 37
5.3.5
State virtual frame ............................................................................................ 38
5.3.6
State actual frame ............................................................................................ 39
5.3.7
State start activity............................................................................................. 40
5.3.8
State mode activity ........................................................................................... 40
5.3.9
State end activity .............................................................................................. 40
5.3.10 Default state..................................................................................................... 40
5.3.11
State hierarchy STM call .................................................................................. 41
5.3.12 Synchronized state........................................................................................... 42
6. Action ............................................................................................................................. 43
6.1. Format of action cell ................................................................................................ 43
6.1.1.
Human language statement.............................................................................. 44
6.1.2.
Computer language statement.......................................................................... 44
6.1.3.
NS chart........................................................................................................... 44
6.1.4.
Invalid .............................................................................................................. 44
6.1.5.
No use ............................................................................................................. 45
6.1.6.
Event hierarchy STM call.................................................................................. 45iTable of contents

6.1.7.
Subroutine STM call ......................................................................................... 47
6.1.8.
Library STM call ............................................................................................... 47
6.1.9.
Divided action cell ............................................................................................ 48
6.1.10. EHSTM system call .......................................................................................... 49
6.1.11. Transition symbol ............................................................................................. 49
6.1.12. Don't care......................................................................................................... 49
7. Transition........................................................................................................................ 51
7.1. Transition types ....................................................................................................... 51
7.1.1
Fixed transition................................................................................................. 51
7.1.2
Memorized transition ........................................................................................ 52
7.1.3
Deep-memorized transition............................................................................... 54
7.2. Transition and state type.......................................................................................... 57
7.2.1
No transition to concurrent state ....................................................................... 57
7.2.2
No transition to concurrent brother state ........................................................... 58
7.3. Synchronized transition............................................................................................ 59
7.3.1
Synchronized number....................................................................................... 59
7.3.2
Wildcard transition............................................................................................ 60
7.3.3
Synchronized state and synchronized transition................................................ 61
7.3.4
Forced transition .............................................................................................. 63
7.4. Transition range....................................................................................................... 64
7.5. Format of transition.................................................................................................. 65
8. Activity............................................................................................................................ 67
8.1. Event activity ........................................................................................................... 67
8.1.1.
Event-analyzer start activity .............................................................................. 69
8.1.2.
Event-analyzer end activity............................................................................... 69
8.1.3.
Event-hit start activity ....................................................................................... 70
8.1.4.
Event-hit end activity ........................................................................................ 70
8.2. State activity ............................................................................................................ 71
8.2.1.
State start activity............................................................................................. 71
8.2.2.
State mode activity ........................................................................................... 72
8.2.3.
State end activity .............................................................................................. 72
8.3. Dispatch activity....................................................................................................... 73
8.4. Trigger activity ......................................................................................................... 74
8.5. STM main activity .................................................................................................... 75
8.6. Order of actions and activities.................................................................................. 75
8.7. Format of activity ..................................................................................................... 77
9. Event analyzer................................................................................................................ 79
9.1. Variable event analyzer ........................................................................................... 79
9.2. Event analyzer and variable access method............................................................. 80
9.2.1.
Flag variable access method ............................................................................ 80
9.2.2.
Mail variable access method............................................................................. 80
9.2.3.
Synchronized variable access method.............................................................. 81
9.3. In-mail analyzer ....................................................................................................... 83
9.4. Interrupt event analyzer ........................................................................................... 84
9.5. Function-call event analyzer .................................................................................... 85
10. State scheduler............................................................................................................... 87
10.1.
Parent-and-child schedule.................................................................................... 88
10.2.
Concurrent schedule ............................................................................................ 89
10.3.
Tree schedule ...................................................................................................... 91
10.4.
State scheduler and transition .............................................................................. 92
10.5.
State scheduler and activity.................................................................................. 92
10.6.
State scheduler and interrupt event ...................................................................... 94
10.7.
Format of state scheduler..................................................................................... 94
11. Driven type ..................................................................................................................... 95
11.1.
Event-driven type ................................................................................................. 95
11.2.
State-driven type.................................................................................................. 96
11.3.
Driven type and event .......................................................................................... 97ii

Table of contents

11.4.
Driven type and state ........................................................................................... 98
11.5.
Driven type and action ......................................................................................... 98
11.6.
Driven type and transition..................................................................................... 98
11.7.
Driven type and activity ........................................................................................ 98
11.8.
Driven type and event analyzer ............................................................................ 99
12. Department....................................................................................................................101
12.1.
Department under non RTOS..............................................................................102
12.2.
Department under RTOS ....................................................................................103
12.3.
Main/Task STM ...................................................................................................104
12.4.
Library STM ........................................................................................................105
12.5.
Device-driver STM .............................................................................................. 111
12.6.
Interrupt-handler STM .........................................................................................116
12.7.
Device-register STM ...........................................................................................117
13. Clone STM.....................................................................................................................121
14. STM main ......................................................................................................................123
14.1.
STM main and event-driven type.........................................................................123
14.2.
STM main and state-driven type..........................................................................124
15. Hierarchy .......................................................................................................................125
15.1.
Event hierarchy...................................................................................................125
15.1.1. Call and return of event hierarchy ....................................................................127
15.2.
State hierarchy....................................................................................................130
15.2.1. Call and return of state hierarchy .....................................................................133
15.3.
Hierarchy and event ............................................................................................137
15.4.
Hierarchy and state.............................................................................................138
15.5.
Hierarchy and action ...........................................................................................139
15.6.
Hierarchy and transition ......................................................................................140
15.7.
Hierarchy and activity..........................................................................................140
15.8.
Hierarchy and event analyzer..............................................................................141
15.9.
Hierarchy and state scheduler.............................................................................141
15.10. Hierarchy and driven type ...................................................................................141
15.11. Hierarchy and department...................................................................................144
15.12. Hierarchy and clone STM....................................................................................145
15.13. Format of hierarchy.............................................................................................145
16. Subroutine STM.............................................................................................................147
16.1.
Call and return of subroutine STM .......................................................................147
16.2.
Internal subroutine STM......................................................................................148
16.3.
External subroutine STM.....................................................................................148
16.4.
Subroutine STM and multitask.............................................................................148
17. EHSTM system call........................................................................................................149
17.1.
inmail ..................................................................................................................150
17.2.
zkill / zalive .........................................................................................................151
17.3. zset / zseth / zcheck................................................................................................152
17.4.
zret .....................................................................................................................153
17.5.
event ..................................................................................................................155
17.6.
zdi / zei / zdil / zeil ...............................................................................................156
17.8.
ztrap ...................................................................................................................156iii

Table of contentsiv

·Introduction

1. Introduction
The original version of the Extended Hierarchy State Transition Matrix Design Method was
published in 1992. Five years have passed since that time.
Changes in "The Extended Hierarchy State Transition Matrix Design Method version 2.0" are as
follows:(1) States can be concurrent.
(2) State hierarchy is allowed.
(3) Functions and interrupts can be described as events.
The range of applications that can be designed using the state transition matrix has been
extended, owing to these additions.

The trend is moving from structured analysis and design to object-oriented analysis and design.
The embedded system engineers would ask, "Can it be used for real-time controlled software in
the embedded, one-chip microprocessor?" as they did when structured analysis and design
were introduced. The answers from methodologists are always, "Yes, it can," but embedded
system engineers are skeptical about such an answer. Information processing engineers neverask whether they can use it.
Why are their reactions different? Probably the focus of each party is a little different. The mostimportant information concerning the structured analysis and design method is "data flow," whilethe "object" is the most important for object-oriented analysis and design. It is natural that thesemethodologies, which come from the information processing field, focus on "data flow" and"object," and that the information processing engineers have no doubt about it.
The focuses of embedded system engineers, however, are on "actual time" and "control." To
our regret, even state transition does not capture "actual time." Maybe "actual time" is a kind of
information that can be captured only by activation (simulation) such as computer graphics.
In order for software to realize "control," it is necessary to manage various states within thesoftware, switch actions depending on the state or received event, then change the state
further. "Event,” "state," "action" and "transition" are important items of information. If a class isdesigned without considering the importance of such information, the class will not have"control," and we wonder what happens to the software built using the class.
The basic concept of the state transition matrix design method is to design software withconsideration for "events," "states," "actions" and "transitions." Therefore, embedded systemengineers do not become skeptical. However, the information about "object" should be added
to it.
It is not that the "state transition" information is added to "object." “Object-oriented” in theembedded world means to consider "when," "where" and "what" the class executes before
considering what the class exactly does (method and attribute). It is necessary to design
objects that handle control, not the objects that handle data.

1

·Introduction

The state transition diagram is used to design state transitions. Mealy, Moore, Harel and others
have rapidly improved the notational conventions. On the other hand, the state transition matrix
has been treated as a supplement to the state transition diagram, so very little has been
improved. I have no idea why the state transition diagram has been improved but the statetransition matrix has not.
I have challenged this issue because I was curious about the reason. I have always preferred
the matrix because it is more organized and easier to spot missing items. As for the diagram,even though deletions could be handled somehow, we did not like the troublesome insertion
operations, which required moving other shapes and connecting the transition destinations.
Another reason I prefer the state transition matrix is that if it is used for designing, it is notnecessary to create a separate checklist for testing. This document is a result of our efforts torealize what the most up-to-date state transition diagrams can represent by using the statetransition matrix. I have been designing control systems using the state transition matrix for along time. The software created thus far is still used actively. The method of design, using thestate transfer matrix, did not change even once from the age of assembly language well into theage of C. I believe the importance of the state transition matrix will further expand in the future.

2¸Format of the state transition matrix (STM)

2. Format of the state transition matrix (STM)
The state transition matrix (STM) consists of the following four categories of information:(1) Event(2) State(3) Action(4) Transition
Events (or states) are written in the rows and states (or events) are written in the columns.
Actions and transition destinations are written in the cells where the rows and columns cross.
The STM can clearly and precisely describe when (event), where (state), and what (action).

State A

State B

Event B Event C

ActionTransition
destination

Event AEvent A

State CState A

ActionTransition
destination

Event B

Transition
destination
ActionState B

ActionTransition
destination

Transition
destination

Event C

ActionActionState C

Transition
destination

Figure 2- 1 Format of the state transition matrix
A simple example is described using the STM. This STM shows someone's actions when
making a phone call.
In this example, events are described in the rows, states in columns, transition destinations in
the upper half of the cells and actions in the lower half of the cells.

Disconnected

Message for making
a phone call
Voice from theother party

On the phone

Dial

State the message
Hang upBusy tone
Hang up

Figure 2- 2 STM describing actions when making a phone call
When the "message for making a phone call" event occurs while in the "disconnected" state, the"dial" action occurs and the state transfers to "busy." The active state is "busy" at this stage,"state the message" and "hang up" are activated when the "voice from the other party" event3¸Format of the state transition matrix (STM)

occurs, and the transition is made to the "disconnected" state. At this stage, the active state is"disconnected."
The STM in this document uses a format in which events are written in rows, states in columns,
actions at the bottom and transitions at the top of the cells.

4¹Format of the extended hierarchy state transition matrix

3. Format of the extended hierarchy state transition matrix (EHSTM)
Table 3-1 shows the Extended Hierarchy State Transition Matrix (EHSTM). Details are
explained in the following chapters.

StateE//concurrent//stateStateD//concurrent//stateFigure 3- 1 Format of the extended hierarchy state transition matrix

5¹Format of the extended hierarchy state transition matrix

1: STM definition
2: Trigger activity
3: Event virtual frame
4: Event actual frame
5: If condition
6: Switch condition
7: In-mail
8: Interrupt event
9: Event-hit start activity
10: Event-hit end activity
11: Function-call event
12: Nassi-Shneiderman chart
13: Driver STM call
14: Library STM call
15: Subroutine STM call
16: Event-hierarchy STM call
17: Invalid
18: Divided action cell
19: No use
20: Name transition
21: Local transition
22: Global transition
23: Concurrent state
24: Synchronized state
25: State virtual frame
26: Event-analyzer end activity: State-driven type only
27: Event-analyzer start activity: State-driven type only
28: State actual frame
29: State mode activity
30: State end activity
31: State start activity
32: Default state
33: Don't care
34: State hierarchy STM call
35: Dispatch activity
36: STM main end activity
37: STM main start activity
38: Flag analyzer end activity
39: Flag analyzer start activity
40: In-mail analyzer end activity
41: In-mail analyzer start activity
42: Event-analyzer end activity
43: Event-analyzer start activity
Notes: Notations in Japanese and English

Number Japanese English
Meaning
Number
ZEH_ Event hierarchy STM

6

Number

ZSH_ State hierarchy STM

NumberZES_

Event-driven subroutine STM

NumberZSS_

State-driven subroutine STM

NumberZEL_

Event-driven library STM

NumberZSL_

State-driven library STM

NumberZTR_

Trigger event

¹Format of the extended hierarchy state transition matrix

7

ºEvent

4. Event
An event is an external stimulus. The state transition matrix design is used to determine torespond to the stimuli. The first step in the state transition design would be to list events. In theexample phone call in Chapter 2, there are three events: "message for making a phone call,""voice from the other party" and "busy tone." The events handled in the analysis stage tend tobe very abstract. The events handled in the design stage, however, need to be conscious of theimplementation, even though they are abstract. For this reason, events in the design stage
have to be clearly defined. A clearly defined event has a specific type. The event types are
explained below.

4.1 Event typeIn the extended hierarchy state transition matrix design method (hereinafter referred to as the
EHSTM design method), four types of events are defined:(1) Variable memory(2) Interrupt(3) In-mail(4) Function call

4.1.1 Variable memory event
The variable memory event considers the change of a variable value as an event. The mostgeneral event a program handles is the change in variable value. When a variable valuechanges from 0 to 1, the program recognizes the occurrence of an event.
Variable A
Variable B

0FF

Figure 4- 1 Variable memory event&: Refer to 4.2, "How to access variables," 9.1, "Variable event analyzer," and 9.2, "Event
analyzer and variable access method" for more information on variable memory events.

9ºEvent

4.1.2 Interrupt event
The interrupt event is used by the CPU to directly notify the program of an external stimulus.
When the Real-Time Operating System (RTOS) is used, an interrupt handler provided by the
RTOS is called. When the RTOS is not used, the user creates an interrupt routine that stores or“pushes” information from the interrupted program and retrieves or “pops” the information when
the interrupt processing is complete before going back to the program. Interrupts can beprevented when a DI (disable interrupt) command is explicitly issued in the program. Theinterrupt prevention is released by the EI (enable interrupt) command.

Figure 4- 2 Interrupt event
An interrupt can occur even during the STM operation. Therefore, note that the following two
behaviors may occur when an interrupt event is used:(1) If the STM does not have the reentrant structure, the state transition via the interrupt event
may take priority.
(2) If the STM has the reentrant structure, the state transition via the interrupt event may beignored.

State A

State B

State C

1

2

3
1

2
Event A

1
Action A

Interrupt event X

3

1

Action C

Action B

2

Figure 4- 3 Interrupt event
Assume action A was being executed because event A occurred in state A. When the interrupt
event X occurs in this instance, the PC (program counter) of the interrupted action A is pushed

10

ºEvent

in the TCB (task-control block) if the RTOS is used. If the RTOS is not used, the PC is pushed
in the supervisor stack. Then, event analysis is performed during interrupt processing, andaction C, where the interrupt event and state A cross, is executed as event number 2. Once
action C is complete, a transition is made to state C, whose state number is 3. At this time, thecontrol returns to the interrupted program. If the RTOS is used, it may return after other tasks
have been operated. When the execution of the rest of action A is complete, an attempt ismade to retrieve the state-transition destination. At this time, if the STM does not have areentrant structure, the state-transition destination will be state A, which has the state
number 1 because the current state is state C, which has state number 3, due to the statetransition by the interrupt event X. If the STM has a reentrant structure, a state transition ismade to state B having state number 2, because the state number returns to the one at the timeof the interrupt. In this case, the result is equivalent in that no state transition has occurred
via the interrupt event X.
Interrupts can explicitly be prohibited or enabled via the state transition matrix by writing zdi() orzei() to prohibit or enable the interrupt, respectively, in actions or activities. zdi() and zei() are
the system calls of the EHSTM design method.

&: Refer to 4.4.6, "Interrupt event," 9.4, "Interrupt event analyzer," 12.6, "Interrupt handler
STM" and 17.6, "zdi/zei/zdil/zeil," for more about interrupt events.

11

ºEvent

4.1.3 In-mail event
In-mail events are the events that can be exchanged between STM hierarchies within the same
STM tree. In other words, the in-mail function exchanges messages between STMs in thesame way as the RTOS’s message communication function between tasks. The in-mailfunction can be used regardless of whether the RTOS is implemented or not. The in-mail is for
notify other STMs of internal events occurring in the action cell. A usage example is as follows:
When an error is detected during the processing of an action cell, an in-mail indicating anabnormality is transmitted to the STM controlling another equipment in order to perform error
recovery.

1

1.1

1.1.1

1.2

Figure 4- 4 In-mail event&: Refer to 4.4.5, "In-mail event," 9.3, "In-mail analyzer," and 17.1, "In-mail," for the in-mailevents.

12

ºEvent

4.1.4 Function-call event
A function-call event considers a function call as an event. Therefore, the STM that can handle
function-call events has to be in the library section.
/* JPEG decompress library initialization */jpeg_CompressInit(&(dInfo));/* get buffer processing */getBuff(&(jpegBuff[0]));/* JPEG decompress start */for(;;){
err=jpeg_Compress(&(dInfo));if(err == JPEG_CONT){/* update buffer processing */getBuff(&&jpegBuff[0]));continue;}else if(err == JPEG_OK){/* normal completion */break;}else{/* abnormal completion */break;}

void
jpeg_CompressInit(JPEGINFO* cInfo)longjpeg_Compress(JPEGINFO* cInfo)

Figure 4- 5 Function-call event
An STM that has been called as a function returns to the caller when the zret() system call isissued.

&: Refer to 9.5, "Function-call event analyzer" and 12.4, "Library STM" for the function-callevents.

13

ºEvent

4.2. How to access variables
There are two access methods for variables:(1) Message type(2) Flag type
Event

Variable

Message type

Mail type
Synchronization typeFlag typeInterrupt
In-mail

Function callFigure 4- 6 Event types
The access method is closely related to the timing when the event is detected (retrieved).

4.2.1 Message event
Message events can be divided into communication-type events and synchronization-type
events. The RTOS is necessary in order to handle the message-type events. Mail-type eventsand synchronization-type events do not simply access the variables in the program, but they doso by executing mail communication and synchronization using the RTOS system calls. The
program is called a task or process because it operates under the control of RTOS.

When mail (message) isdelivered, check what thecontent (variable) is.

When a notice (event flag)comes in, check what thecontent (variable) is.

Figure 4- 7 Message event14

ºEvent

4.2.2 Flag event
With flag events, the program simply accesses variables. It does not matter whether the RTOS
exists when handling flag events.

Always monitors if
something has occurred.

Figure 4- 8 Flag event
A flag event is represented by an "if" or "switch" condition in terms of its format.
The condition of the highest level in the event cell is considered a flag event. Events withcondition symbols following a message event are considered regular condition statements andare not subject to monitoring by polling as flag events are.
Condition

Condition
Message type
Condition

Flag typeFlag typeFigure 4- 9 Flag events and conditions&: Refer to 9.1, "Variable event analyzer" and 9.2, "Event analyzer and variable accessmethod," for information on accessing variables.

15

ºEvent

4.3. Mixed events
Events of different types can coexist in a single STM. However, function-call events must
belong to the library or device-driver section.
State

Message typeFlag typeIn-mail typeInterrupt type
Function callFigure 4- 10 Mixed events
In the above example, five event analyzers are generated in one STM. They are the message
analyzer for the message event, flag-sensing analyzer for the flag event, in-mail analyzer for thein-mail event, interrupt handler for the interrupt event, and the function for the function-callevent.
The default operations of mixed events are:À message analyzer
Á flag analyzer
Â in-mail analyzer

Further, the interrupt handler is executed when the interrupt occurs, and the function-call event
occurs with the function call. "Event analyzer" is a generic term for the above three.
When communication-type and synchronization-type message events coexist, a problem occurs
in the task execution control, such as when use of the synchronization type is disabled thecommunication type enters the wait state, and vice versa.

16

ºEvent

When the highest-level event is a flag type or in-mail type, the event symbols for its children canbe omitted.

Figure 4- 11 Nested events
In Figure 4-11, events "B" through "G" are not considered message events but flag events,
which are the same event type as parent event "A." In other words, a message event cannot be
placed after a flag event. Similarly, events "I" through "N" are not considered message events
but in-mail events, which are the same event type as parent event "H." In other words, theparent of a message event has to be a message event.

Figure 4- 12 Flag events and conditions

17

ºEvent

In Figure 4-12, event "A" is a message event. Events "B" and "C" are not flag events but
condition statements. Events "D" through "G" are message events, which are the same event
type as parent event "A."

Figure 4- 13 In-mail events and conditions
In Figure 4-13, event "A" is an in-mail event. Events "B" and "C" are not flag event but condition
statements. Events "D" through "G" are in-mail events, which are the same event type as
parent event "A." They are not interpreted as message events.

When the head is a message event, in-mail events cannot be placed thereafter.

&: Refer to 9, "Event analyzer," for details on the event analyzer.

18

ºEvent

4.4.

Format of event cell

The following information can be described in the event cells:
1: Event
2: Event frame
3: Message event
4: Flag event
5: In-mail event
6: Interrupt event
7: Function-call event
8: Trigger event
9: “else” event
10: Event virtual frame
11: Event actual frame
12: “if” condition
13: “switch” condition
14: Event-analyzer start activity
15: Event-analyzer end activity
16: Event-hit start activity
17: Event-hit end activity
18: Default/else (no action default/else)
19: Analysis sequence number

4.4.1 Event"Event" is a generic team for message events, flag events, in-mail events, interrupt events andfunction-call events. An event is converted to an event number by the event analyzer. An event
normally has an event number, but sometimes it refers to an event and event frame collectively.

&: Refer to 9, "Event analyzer," for details on the event analyzer.
4.4.2 Event frame
An event frame is a bundle of events or event frames. The event frame allows the creation of atree structure of events or conditional branches. There are two kinds of event frames: event
virtual frames and event actual frames.

19ºEvent

4.4.3 Message event
There are two kinds of message events -- mail events and synchronization events -- but they
use the same notations.

4.4.4 Flag event
A triangle is attached to the top-left corner of a flag event.
4.4.5 In-mail event
In-mail performs communication between STMs within the same tree. The reception of an inmail is represented by a double square. The issuance of in-mail is represented by “in-mail(STM level number of the notification destination, in-mail name)” in ZIPC.

In-mail A
In-mail B

In-mail (100, in-mail B)

In-mail (100, in-mail A)

Event AEvent B

Figure 4- 14 Sample in-mail STM (1)There is a possibility that an in-mail can form an infinite loop. In the above STM, thetransmission and reception of in-mail are repeated infinitely when in-mail A occurs during state
number 0. The "if" and "switch" conditions can be stated after in-mail. An event-hit activity canbe defined for an in-mail. No events can be stated following an in-mail.

20

ºEvent

In-mail B
In-mail A

In-mail C

Variable A==1

In-mail D
Event AEvent Bif (in-mail_A) {if (in-mail_B) {// event number 0}
else if (in-mail_C) {if (variable A = 1) {// event number 1}
else {// event number 2}}}
else if (in-mail_D) {// event number 3}

Figure 4- 15 Sample in-mail STM (2)Event AIn-mail

Event BThe in-mail analyzer and event analyzer are separate functions.

Figure 4- 16 Sample of unallowed in-mail STM&: Refer to 9, "Event analyzer," for the in-mail and event analyzers.

21

ºEvent

4.4.6 Interrupt event
The interrupt event analyzes events within the interrupt handler and manipulates the STM. The"if" and "switch" conditions can be stated after the interrupt. An event detection activity can be
defined for an interrupt event. No events can be stated after an interrupt event.

Interrupt A Variable
A

Interrupt B
Interrupt C

interrupt void interrupt_A (void) {switch (variable_A) {case DEF_A:// event number 0
break;
case DEF_B:// event number 1
break;
case DEF_C:// event number 2
break;}}
interrupt void interrupt_B (void) {// event number 3}
interrupt void interrupt_C (void) {// event-hit start activity// event number 4// event-hit end activity}

Figure 4- 17 Sample interrupt event STM

22

ºEvent

4.4.7 Function-call event
A function-call event is indicated by "[" on the left.
4.4.8 Trigger event
Only one trigger event can be defined in an STM department (STM tree). However, it cannot be
used in the subroutine, library or driver section. In other words, one trigger event can be
defined in a task or module. A trigger event is executed only once at the beginning of a task or
module execution. In order not to increase the number of cells, trigger events are notwritten in the event column but as trigger activities in EHSTM version 2 or later. In
EHSTM version 2, "n" and "ii" are not treated as keywords for trigger events. If a
trigger event needs to be specified anyway, use “¥¥.” The trigger event is executed only inthe left-most action cell (state number 0), even if it is a concurrent state. In a trigger event, thespecification of the default state position with the default symbol (u) is ignored, and the statewith the youngest number is selected instead.

Trigger event
Event AEvent B
Event C

Figure 4- 18 Trigger event23

ºEvent

4.4.9 “else” event
One "else" event can be defined in each frame. This is the event not classified into any event.
Figure 4-19 represents the else event in a format similar to the C programming language.

Event AEvent B
Event Cif (event_A) {// event number 0}
else if (event_B) {// event number 1}
else if (event_C) {// event number 2}
else {// event number 3}

Figure 4- 19 “else” event

The else event can be placed in each frame as shown in Figure 4-20.

Figure 4- 20 “else” event in each frame

24

ºEvent

4.4.10 Event virtual frame
The event virtual frame is used for analyzing events, and can execute event-hit activities. An
event virtual frame can be a comment frame that will not be executed, by enclosing the entire
frame with comment symbols. In this case, the activity does not run, either. Event virtualframes do not have event numbers.
Take a look at Figure 4-14. Frame A is the parent frame of frames "B" and "C," and possesses
an event-hit start activity. Frame B is the parent frame of events "A" and "B," and possesses anevent-hit end activity. Frame D is a comment. A comment is an abstract event that does nothave to be analyzed by the event analyzer.

Frame B
Frame A
Frame C

Event AEvent B
Event C
Event D
Event E/* frame D */Frame E
Frame F

Event F
Event G
Event Hif (frame_A) {// event-hit start activity
if (frame_B) {if (event_A) {// event number 0}
else if (event_B) {// event number 1}// event-hit end activity}
else if (frame_C) {if (event_C) {// event number 2}
else if (event_D) {// event number 3}}}
else if (frame_E) { // frame D
if (event_E) {// event number 4}else if (event_F) {// event number 5}}else if (frame_F) {25

ºEvent

if (event_G) {// event number 5}else if (event_H) {// event number 6}}

Figure 4- 21 Event virtual frame sample STM
4.4.11 Event actual frame
The event actual frame can be described as an event virtual frame that has an event number
and drives the STM.

Actual frame A
Event AEvent B
Event C
Event D
Event E
Actual frame B
Frame C

Event F
Event G

Event H
Event Iif (actualframe_A) {// event number 0
if (event_A) {// event number 1}
else if (event_B) {// event number 2}
else if (actualframe_B) {if (event_C) {// event number 3}
else if (event_D) {// event number 4}else if (frame_E) {// event number 5}// event number 6}
else if (frame_C) {if (event_F {// event number 7}
else if (event_G) {// event number 8}}26

ºEvent

else if (event_H) {// event number 9}}else if (event_I) {// event number 10}

Figure 4- 22 Event actual frame sample STM
Event actual frames can also define activities the same way event virtual frames can.

4.4.12 "if" condition
The "if" condition classifies events based on a specific condition. In the traditional STM, "if"conditions are written in condition cells. However, it is not practical to write a retry counter as astate, for example, because it will lead to a huge increase in the number of states. Be careful,since the use of too many "if" conditions will increase flags, which may ruin the STM design.
Remember, the essence of the STM design is to reduce flags as much as possible. The
purpose of the STM design will be lost if too many "if" conditions are used in the state transition
matrix.

Variable A == 1
Variable B == 1
Event A
Variable C > 0
Variable C <= 0

if (event_A) {if (variable_A = 1) {// event number 0}
else if (variable_B = 1) {// event number 1}
else {
if (variable_C > 0) {// event number 2}
else if (variable_C <= 0) {// event number 3}}}

Figure 4- 23 "if" condition sample STM (1)27ºEvent

Variable A == 1
Variable
A>0

Variable B == 1
Variable C > 0
Variable C<= 0
Event

Figure 4- 24 "if" condition sample STM (2)Conditions and events can be mixed, as shown in Figure 4-24. When the event at the highest
level is a flag or in-mail type, the child events are interpreted as the same type as that of theparent event.
In Figure 4-25, the event is interpreted as a flag type instead of a message type.

Variable A == 1
Variable B == 1

Variable
A>0

Event

Variable C > 0
Variable C<= 0

Event

Figure 4- 25 "if" condition sample STM (3)A function call (differing from the function-call event) can be written in the "if" condition. For
example, a function (not a variable) can also be written as follows:
GetChar() = OKThis can also be written using a "switch" condition or flag-type event.

&: Refer to 4.3, "Mixed events," for the interpretation when events and conditions are mixed.

28

ºEvent

4.4.13 "switch" condition"Switch" conditions work in the same way as "if" conditions. The difference is the same as
between the "if" statement and "switch" statement in the C programming language. A "case"statement follows immediately after the "switch" condition, and no events are allowed.

Event A

VariableA
VariableBif (event_A) {switch (variable_A) {case DEF_A:// event number 0
break;
case DEF_B:// event number 0
break;
default:
switch (variable_B) {case DEF_A:
case DEF_B:// event number 2
break;
case DEF_C:
case DEF_D:// event number 3
break;
case DEF_E:
case DEF_F:// event number 4}}}

Figure 4- 26 "switch" condition sample STM

29

ºEvent

Figure 4- 27 Coexistence of switch condition and message event
In Figure 4-27, "A" is interpreted as a message event, "B" as a switch statement, "C" and "D" ascase statements, and "E" to "J" as message events.

30

ºEvent

4.4.14 Event-analyzer start activity
The processing that is called immediately prior to starting the event analyzer is described.
Three types can be set in one state transition matrix: message-event analyzer, flag-event
analyzer and in-mail event analyzer. An "S" is attached to the state transition matrix to indicatethat an event-analyzer start activity exists. Refer to the interrupt-event sample STM for theformat.

&: The activity will be explained in 8, "Activity."
4.4.15 Event-analyzer end activity
The processing that is called immediately prior to the end of the event analyzer is described.
Three types can be set in one state transition matrix: message-event analyzer, flag-event
analyzer and in-mail event analyzer. An "E" is attached to the state transition matrix to indicatethat an event-analyzer end activity exists. Refer to the interrupt event sample STM for theformat.

4.4.16 Event-hit start activity
This is the processing that is executed immediately after an applicable event is detected. It canbe set in four types of events: variable type, interrupt type, in-mail type and function-call type.
An "S" is attached when there is activity. Refer to the interrupt event sample STM for theappropriate format.

4.4.17 Event-hit end activity
This process is executed when the action and transition processing are finished after anapplicable event is detected. It can be set in four types of events: variable type, interrupt type,in-mail type and function-call type. An "E" is attached when there is activity. Refer to theinterrupt-event sample STM for the format.

31

ºEvent

4.4.18 No action default/else

VariableA

Variable B == 0

Variable B == 100

switch (variable_A) {case 100:// event 0
break;
case 200:// event 1
break;
case 300:// event 2
break;
default:err();}
if (variable_B == 0) {// event 3}
else if (variable_B == 100) {// event 4}
else {
reset ()}

Figure 4- 28 No action default/else
When processing is required for the "default" of a switch statement or "else" of an "if" statement,
regardless of the state, the increase in the number of cells can be suppressed by specifying noaction default/else.

32ºEvent

4.4.19 Analysis sequence number

Event AEvent B
Event C

Figure 4- 29 Analysis sequence number
if (event_C) {// event number 2}
else if (event_B) {// event number 1}
else if {event_A} {// event number 0}
The order of the analysis can be set by specifying the analysis sequence number.

33

ºEvent34

»State

5. State
A state can be described as a shelf for storing events that have occurred in the past. In theexample of the telephone in Chapter 2, there were two states: "disconnected" and "busy." A
state has two attributes: one is the exclusive attribute, and the other is the concurrent attribute.
The STM created only with the exclusive attribute is called the exclusive STM, and the others
are called concurrent STMs.

5.1. Exclusive state
If only one of the states of the design target is active at a time, it is in the exclusive state. The
telephone example in Chapter 2 is in the exclusive state. The exclusive state means that either
the "disconnected" or "busy" state can be active.

5.2. Concurrent state
When multiple states are active in the design target, it is in the concurrent state. In theexample of the concurrent state shown below, the action of watching TV is added to thetelephone example from Chapter 2.
TELEPHONE

DISCONNECTED

Message formaking a phone
call
Voice from theother party
Busy tone
Interested
program

ON THE PHONE

Dial
State the message
Hang up

Mute

Hang upTurn TV on

End of program

Turn TV off

Turn TV off

Figure 5- 1 Concurrent state STM

35

» State

This is an STM for the action to make a phone call while watching TV. When making a phone
call while watching TV, the sound of the TV is muted when the other party answers. The
telephone and TV can operate concurrently.

A concurrent state is surrounded by dotted lines. The "telephone" and "TV" state frames haveconcurrent attributes, and both of them could be active simultaneously. The "telephone" state
frame has two child state frames ("disconnected" and "busy"), both of which are exclusive
attributes. The "TV" state frame has one exclusive-attribute state ("OFF") and one exclusiveattribute state frame ("ON"). In addition, the "ON" state frame has two exclusive-attribute states("NORMAL" and "MUTE").

A concurrent state is a candidate for task splitting. Concurrent states mean operations are
executed concurrently. Therefore, concurrent actions can be achieved through multitasking byconsidering each concurrent state as a task. In this case, the STM that represents one of thesetasks is in the exclusive state.
[System specifications]
TELEPHONE
DISCONNECTED

Message formaking aphone call

ON THE PHONE

Dial
State the message
Hang up

Voice from theother party
Busy tone

Mute

Hang up

Interested
programTurn TV on

End ofprogramMessage formaking aphone call

Voice from theother party
Busy tone

Turn TV off

Dial

Voice fromthe other party

State the message
Hang upHang up[Telephone task]

Interested
program
End ofprogram

Mute
Turn TV on
Turn TV off[TV task]

Figure 5- 2 Concurrent states and exclusive state tasks

36

Turn TV off

Turn TV off»State5.3.

Format of state cell

The following information can be described in the state cells:
1: State
2: State frame
3: Exclusive state
4: Concurrent state
5: State virtual frame
6: State actual frame
7: State start activity
8: State mode activity
9: State end activity
10: Default state
11: State hierarchy STM call
12: Synchronized state

5.3.1 State
State is a generic term for the exclusive state and concurrent state. In some cases, it includes
state frames.

5.3.2 State frame
A state frame is a bundle of states or state frames. A tree structure of states can be created via
the state frame. State frames have two types: state virtual frame and state actual frame.

5.3.3 Exclusive state
An exclusive state is represented by a square.
5.3.4 Concurrent state
A concurrent state is represented by a dotted square inside a solid square.

37» State

5.3.5 State virtual frame
A state frame is a parent state that bundles child states. A state frame itself may become achild. Similarly to the states, state frames have attributes of either exclusive or concurrent.
Rules in the parent-and-child relationship of state attributes( ) Exclusive ( )Exclusive ( )Concurrent ( )Concurrent

|

|

|

|

Exclusive

Concurrent

Exclusive

Concurrent

Rules in the brotherhood relationship of state attributes( ) Exclusive - Exclusive ( )Concurrent - Concurrent (×)

Exclusive - Concurrent

Exclusive attribute means only one of the brothers becomes active at a time. In other words, allbrothers have to be exclusive. Therefore, exclusive and concurrent states cannot be brothers.

Figure 5- 3 Exclusive state
The parent-and-child and brotherhood relationships of the above STM can be represented by
the following state tree.

S1 - S2
S21- S22

S3 - S4
S33 - S32
S311- S312

Figure 5- 4 State tree38

»StateThere are four errors in the following STM:

Figure 5- 5 Erroneous states(1) S3 is concurrent. S3 should be exclusive, or S1, S2 and S4 should be concurrent.
(2) S22 is concurrent. S22 should be exclusive or S21 concurrent.
(3) S32 is concurrent. S32 should be exclusive or S31 concurrent.
(4) S312 is concurrent. S312 should be exclusive or S311 concurrent.

5.3.6 State actual frame
The state actual frame is a state frame that can drive actions by events and make transitions.
State frames cannot drive actions by events. The state virtual frames (S2, S3 and S31)
described in 5.3.5 are unrelated to the execution of actions. Only the states (i.e., the ones
having state numbers) are related to actions.

Figure 5- 6 State actual frame
S2, S3 and S31 are state actual frames. Since S21 and S22, which are the child states of S2,
are exclusive brother states, only one of them is executed. The rule that determines which one
is executed is explained in Chapter 7, "Transition." Since S31 and S32, which are the childstates of S3, are exclusive brother states, only one of them is executed. When S31 is executed,
one of the child states, S311 or S312, is executed.

39

» State

5.3.7 State start activity
This process is executed when a transition is made to the applicable state (when the applicablestate becomes active). An "S" is attached to indicate that activity exists. See S3 in Figure 5-6
for the format.

5.3.8 State mode activity
This process is executed as long as the applicable state is active. An "M" is attached to indicatethat activity exists. See S3 in Figure 5-6 for the format.

5.3.9 State end activity
This process is executed when a transition occurs from the applicable state (when theapplicable state becomes inactive). An "E" is attached to indicate that activity exists. See S3 in
Figure 5-6 for the format.

5.3.10 Default state
The default state specifies which state of the brother states becomes active. When there is nodefault mark (τ), the state with the lowest state number becomes the default state. The default
state of the STM in Figure 5-6 is S1 (state number: 0). The state that becomes active first shallbe S1. When the transition to S2 occurs, of the child states of S2 (S21, S22), the S21 becomes
active by default.

Figure 5- 7 Default state&: Several types can be specified for transitions. Depending on the type, the default may bevalid or invalid. Refer to 7, "Transition," for details.

40»State

5.3.11 State hierarchy STM call
The state hierarchy is described in the state cell as follows:
STM level number
STM name
The state hierarchy STM can be called only from a state having a state number. Others cannot
call this. State frames and state actual frames cannot call it, either. The hierarchy states are
implemented via the state tree. The state tree shown in Figure 5-4 is described below using thestate hierarchy.

Figure 5- 8 State hierarchy STM&: The details of hierarchy are explained in 15, "Hierarchy."41

» State

5.3.12 Synchronized state
The synchronized state is a concurrent state that performs transition synchronous to thetransition from a concurrent state. A synchronized state is represented by an exclusive parent
state frame surrounded by solid lines.

A

E1

E2

B

C

B1

B2

B3

B4

0

1

2

3

4

5

-

A

C

0

5

B

/

/

/

/

/

/

B

0

5

A

C

A

/

/

/

/

/

/

0

1

Figure 5- 9 Synchronized state
The exclusive state "B" is a synchronized state. The "B1" synchronized state makes a statetransition to "A" via event "E1." Normally, a transition occurs to the "A" state at this time.
However, since the synchronized state is specified as the parent's exclusive frame, "B1" waits
until all of the brother concurrent states "B2/B3/B4" make transitions to state "A" (state number:0). What happens if "B2" accepts "E1" in this state? The action will be executed but thetransition to state "C" will be ignored, because "B1," which is a synchronized state, is alreadywaiting for the synchronization to state "A." State "B1" will keep waiting until the states "B2,""B3" and "B4" make transitions to state "A," resulting in a deadlock since "B2" and "B4" will haveno transitions to state "A." The deadlock can be released by specifying a forced transition. Thiskind of deadlock should be statically detected by a CASE tool that supports the EHSTM.
The priority of the synchronized transition destination is determined on a first-come, first-servebasis.
&: Synchronized transition and forced transitions are explained in 7.3, "Synchronizedtransition."42

¼Action

6. Action
An action is a function or process that is executed when the specific event occurs during thespecific state. The action cell is a cell in which the event cell and the state cell cross. While the"what" (function) is normally described in the action, "how" (processing) can also be described.
A function is described as the action in the example phone call in Chapter 2. It is also allowed
to describe how to process the function of "making a phone call" in the action cell.
Disconnected

Message formaking a phone
call//DialLift handset
Push phone number ofthe other party

Voice from theother party
Figure 6- 1 Action that describes processing

6.1. Format of action cell
The following information can be described in the action cells:
1: Human language statement
2: Computer language statement
3: NS chart
4: Invalid
5: No use
6: Event hierarchy STM call
7: Subroutine STM call
8: Library STM call
9: Divided action cell
10: EHSTM system call
11: Transition symbol
12: Don’t care43

¼ Action

6.1.1.
Human language statement
A function or process is described in human language in the action cell. The range of usable
Actionhuman language statements is not specified in this document, but depends on thespecifications of the CASE (Computer-Aided Software Engineering) tool that supports the
EHSTM design method.
6.1.2.
Computer language statement
A function or process is described using computer language in the action cell. The range ofusable computer language statements is not specified in this document, but depends on thespecifications of the CASE tool that supports the EHSTM design method.
6.1.3.
NS chart
The NS chart can be described in the action cell. The NS chart is a documentation technique
for the structured approach. In the NS chart, three basic logical structures (sequence, if thenelse, do while) are represented by the following symbols. 1The range of usable NS charts is notdefined in this document. It depends on the specifications of the CASE tool that supports the
EHSTM design method.
A
B

p
THEN

A

(1) Sequence

p
ELSE

B

A

(2) if-then-else(3) do-while

Figure 6- 2 Basic symbols of NS chart (A and B: functions; p: test condition)
6.1.4.
Invalid“Invalid” is represented by an “X" mark. The invalid indicates an event and state combinationthat can never occur. Therefore, a debugging process such as halting the system needs to be
implemented in case the invalid action cell is called. In the example of a phone call in Figure 2,
the "voice from the other party" and "busy tone" events never occur in the "disconnected" state.
Therefore, invalid (X) is written in the action cell.
1 Kunitomo, Yoshihisa, "Introduction to the structured programming," Ohm-sha press44

¼Action

6.1.5.
No useNo use is indicated by the "/" symbol. No use means the event and state combination can exist
but no processing is executed. In the example phone call in Figure 2-2 in Chapter 2, even if a
"Message for making a phone call" occurs under the "Busy" state, it is ignored (/).
6.1.6.
Event hierarchy STM call
The event hierarchy STM call is described as follows.
STM level number <option>
STM name <option>
Unlike the state hierarchy STM call, the event hierarchy STM call can call multiple child event
hierarchy STMs. The STM of a phone call in Figure 2-2 is shown as an event hierarchy.

Disconnected
Message formaking a phonecall

On the phone

Dial

Busy tone

On the phone

Voice from theother party
Busy tone

State the message
Hang upHang up

Figure 6- 3 Event-hierarchy STM call
The event hierarchy constructs a tree of events. The event tree of Figure 6-3 is shown as
follows, and can be represented not only by hierarchy but also by an event frame.
Sound heard from the phone - Voice from the other party- Busy tone

Figure 6- 4 Event tree
Three items can be specified for the option: argument, clone number and event number.

45

¼ Action(1)Argument
By specifying arguments, information can be exchanged between the calling STM and thecalled STM.
Tel(&para1, para2)
The description is the same as that of the arguments in the C programming language. Whenthe argument type is necessary, declare it in the STM on the called side.
Tel(int *ip1, int i2)(2)Clone number
The clone STM is treated as an array in C. The clone number is an array index. Specify anindex, assuming the STM as an array.
1.1[2]
The array index starts from 0. The array size for the STM is declared on the called side.
1.1[3](3)Event number
By specifying the event number, a call can be made so that the specified event number is driven
without going through the event analyzer of the called STM. This is called the direct event
number call. Insert a colon (:) after the name or level number of the STM to be called, thenspecify the event number after that.
tel:0
No declaration is necessary on the called side.
The event number starts with 0 or 1.
(Use of STMs starting with 0 and those starting with 1 mixed in the same project may easily leadto confusion.)
The composite format for options is described in the order of (1) clone number, (2) event
number and (3) argument.
1.1[0]:0(p1,p2,p3)&: The hierarchy is detailed in 15, "Hierarchy." The details of the clone are explained in 13,"Clone STM." The details of the event analyzer are explained in 9, "Event analyzer."46

¼Action

6.1.7.
Subroutine STM call
Subroutine STM calls are written as the following:∆Subroutine STM level number <option>∆Subroutine STM name <option>∆100[0]:0(p1,p2,p3)
For the specifications of options, refer to Section 6.1.6, "Event hierarchy STM call," since they
are the same.

&: The details of the subroutine STM will be explained in 16, "Subroutine STM."
6.1.8.
Library STM call
The library STM calls are written as the following:library STM level number (function name <option>)library STM name (function name <option>)(*)The event number cannot be specified via a library call.
A function name is written instead of the event number.
JPEG[0]:jpeg_Compress(p1,p2,p3)
The STM level number and name can be omitted only when the call is made with the argument
options only.

jpeg_Compress(p1,p2,p3)&: The details of the library STM are explained in 12.4, "Library STM."

47

¼ Action

6.1.9.
Divided action cell
The divided action cell is an action cell split into multiple cells, according to the condition.

if(A==1){
FuncA}
else if(B==1){
FuncB}
else if(A==1 && B==1){
FuncC
}
else{
}
Figure 6- 5 Divided action cell
The rule for determining the condition of the divided action cell is the "if-else" method. In theexample above, FuncC will never be executed. To change to the "if-if" method, describe it using
the NS chart or directly write the C code.

48

¼Action

6.1.10.
EHSTM system call
The EHSTM system calls are not represented by symbols but by writing specific actions bywords (sentences) such as “system call.”The EHSTM system calls will be explained again in 16, "EHSTM system call." Refer to that
section for details.
6.1.11.
Transition symbol
By using the transition symbol (=>), the transition destination can be specified without writing in
the transition cell. When the transition symbol is found, actions written after the transition
symbol are executed after the activity (end and start) is operated.
=> transition destination
A local or global transition can be specified as the transition destination.
Figure 6- 6 Transition Symbol

In the STM in Figure 6-6, every funcC is executed after the transition is activated. If you wish
not to execute the rest of the process after the transition is performed, it is necessary to write areturn statement in the action cell of the STM.
&: The details of the transition are explained in 7, "Transition."
6.1.12.
Don't care
Don't care is represented by a dot (.). The meaning is the same as no use (/).

49

½Transition

7. Transition“Transition” means a transfer from one state to another state. In the example of a phone call in
Figure 2-2, the transition from the "disconnected" state to the "busy" state occurs via the"message for making a phone call" event after executing the "dial" action.

7.1. Transition types
In the EHSTM design method, the transitions are defined in three types.1
(1)
Fixed
(2)
Memorized(3)
Deep-Memorized
The transition type specifies which child state to activate when its parent state is specified as
the transition destination. If a childless state is specified as the transition destination, there isno difference in the action when any type is specified. A state name or state number is
specified as the transition destination. The specified name has to be a unique name.
When the transition type is omitted, the deep memorized is used.
7.1.1 Fixed transition
The fixed transition is written in the following format:
Transition destination state name (D)Transition destination state number (D)Voicefrom the
other
party
Interested
program

Mute

Turn TVon

End ofprogramTurn TV off

Turn TV off

Figure 7- 1 Fixed transition (1)In the "OFF" state upon "Interested program" event, transition to the "ON(D)" state will occur
after the "Turn TV on" action. This means that the default state of "NORMAL" or "MUTE" will beselected after the transition to the "ON" state occurs. In other words, since there is no default
mark (τ), in this situation "NORMAL" will become the active state via the priority given to thesmaller number.

1

Rapid Simulation & Training51

½ Transition

Voicefrom the
other
party

Mute

Interested
programTurn TV on

End ofprogramTurn TV off

Turn TV off

Figure 7- 2 Fixed transition (2)If there is a default mark on "MUTE," the active state will be "MUTE" after transition to the "ON"state.

7.1.2 Memorized transition
The memorized transition is written in the following format:
Transition destination status name (H)Transition destination status number (H)Voicefrom the
other
party
Interested
program
End ofprogram

Mute

Turn TV on

Turn TV off

Turn TV off

Figure 7- 3 Memorized transition (1)The default state is ignored by the memorized transition. The child state, which was active inthe past, will be activated. The default is used only when no state has been active.

52

½Transition

OFF
Interested
program

(1)

(2)

(3)

State

Event

ON
NORMAL

Voice from theother party

ON
MUTE

End ofprogram(4)(5)

End ofprogramOFF

OFF

Interested
program

ON
MUTE

(6)

Interested
programON
NORMAL

Figure 7- 4 Memorized transition SDL(Functional Specification and Description Language)(1) The "NORMAL" state is activated by default at the beginning.
(2) When the "Voice from the other party" event occurs, the "MUTE" state is activated.
(3) At this stage, the "ON" parent state will change the history of the child state to "MUTE."(4) Again, the "Interested program" event occurs.
(5) Because the transition destination type is the memorized type (H), a transition occurs to"MUTE," which is the recorded history.
(6) When the "Voice from the other party" event does not occur, the “ON” parent state keeps thechild state history at "NORMAL," so the transition is made to "NORMAL."
This requires only a change of the transition type to the memorized type, so there is no need forthe transition requester side to be conscious about what was active last time. Also, if transition
by default is desired, all you need to do is change the transition type to the fixed type.

53

½ Transition

7.1.3 Deep-memorized transition
The deep-memorized transition is written in the following format:
Transition destination state name (P)Transition destination state number (P)The deep-memorized transition is applied when the transition type is not explicitly specified.
(*) Note that deep-memorized transition is applied, not fixed transition, when the transition typeis omitted.

Figure 7- 5 STM for a videocassette recorder (1)Through deep-memorized transition, the parent state activates (makes a transition to) thedescendant states based on the history of all descendant states. In the memorized transition,
the parent state executes a transition based on the history of its own child only, while the fixedtransition is applied to the grandchildren and their descendants.
The STM for a videocassette recorder in Figure 7-5 is explained below as an example.
1
2
3
4
5
6
7

54

Initially "OFF" as the default state.
"ON" occurs.
Memorized transition (H) occurs to the "ON" state.
Since there is no history yet (none has been activated), transition is made to "NO_TAPE,"
which is the default state.
"IN TAPE" occurs.
Deep-memorized transition (H) occurs to the "TAPE" state.
Since there is no history yet, transition is made to the "¢" (STOP) state, which is thedefault.

½Transition" u " (PLAY) occurs.
Transition to state number 3.
"uu" (FAST FORWARD) occurs.
Transition to state number 4.
"OUT TAPE" occurs.
Transition to state number 1.
"IN TAPE" occurs.
Deep-memorized transition (P) occurs toward the "TAPE" state.
The history of states whose parents are "TAPE" will look like the following diagram at thistime. The states indicated by ¤ are the ones that were active previously.
TAPE
¢
u
¤
u
uu
¤
tt
33
τ

8
9
10
11
12
13
14
15
16

uu
tt
n

Figure 7- 6 State tree
17

" uu " of state number 4 becomes active.

To avoid the continuation of the previous operation when the tape is inserted, change=>TAPE(P)to=>TAPE(D)and it will always start from the default "¢" (STOP) state.
In the current design, the PAUSE(33) will be executed during PLAY, FAST FORWARD or
REWIND, but it will return only to the PLAY state when it is released. In order to return to theprevious state, add a virtual state frame and execute a deep-memorized transition for the state
frame.

55

½ Transition

Figure 7- 7 STM for a videocassette recorder (2)When the parents have only one generation of children (when there are no grandchildren), thedeep-memorized transition and memorized transition have the same meaning.

56

½Transition

7.2. Transition and state type
Any states or state frames except for the following two can be specified as transition
destinations.
(1) Concurrent state(2) Child states of concurrent brothers
The transition can be synchronized for concurrent states.
7.2.1 No transition to concurrent stateTransition to a concurrent state (including state frames) is not allowed. The concurrent state isa state that can always be active along with another concurrent state. Making a transitionmeans to activate the transition destination.
Let’s take the concurrent state STM in Figure 5-1 as an example. "Telephone" and "TV" areconcurrent states, and it is not that only one of them can be active; both of them are active at
the same time. Therefore, a transition to one of "Telephone" or "TV" (activate) cannot happen.
The STM in Figure 7-8 was created from the viewpoint of the videocassette recorder'smanufacturer. The STMs in Figures 7-5 and 7-7 were created from the viewpoint of the user
who operates the videocassette recorder.

MOTOR

HEAD
PLAY

RECORD

IN OPERATION
STOP

PAUSE
NORMA L

STOP
NormalFAST
REWINDFORWARD

STOP
NormalFAST
FORWARDFASTFORWARD

REWIND

REWIND

REWIND

PAUSE

PAUSE

In operation

STOP
NormalFAST
FORWARD

PAUSE

NormalFigure 7- 8 STM for a videocassette recorder (3)The "HEAD" and "MOTOR" are concurrent states and are activated concurrently, so neither ofthem can alone be specified as the transition destination. However, transition to the "TAPE"
status, which is the parent of "HEAD" and "MOTOR," is allowed because it is an exclusive state.
When a transition to "TAPE" occurs, "HEAD" and "MOTOR" are activated regardless of thetransition type for "TAPE."

57

½ Transition

7.2.2 No transition to concurrent brother state
Concurrent brothers cannot make transitions to a child of the others.
TELEPHONE

DISCONNECTED

Message formaking a call
Voice from theother party
Busy tone

ON THE PHONE

Dial
State the message
Hung up

Mute

Hang up

Interested
programTurn TV on
End ofprogramTurn TV off

Turn TV off

Figure 7- 9 No transition to concurrent brother state"Hang up after telling the message" when the "Voice from the other party" is heard while "On thephone.""Mute the TV sound " when the "Voice from the other party" is heard while the "TV sound isturned on."
These two actions are processed concurrently. The "TV" state is ignored during the"Telephone" state, while the "Telephone" state is ignored during the "TV" state. If one has toworry about the other, they are not concurrent states.
In the example of the videocassette recorder in Figure 7-8, "HEAD" and "MOTOR" do notinterfere with each other in the transition. This is because the same event can be obtained inconcurrent states.
Note that it does not mean the concurrent state cannot be exited. Transition to the exclusive
state, other than the child states of the concurrent brothers, is allowed.

58

½Transition

7.3. Synchronized transition
A synchronized transition is also allowed from the concurrent state within a synchronized state.
However, the synchronized state synchronizes to all the concurrent states.

A

B

C

B1

B2

B3

B4

0

1

2

3

4

5

E1

0

/

=>A

=>C

=0

=>5

=>B

E2

1

B

=>0

=>5

=>A

=>C

=>A

Figure 7- 10 Deadlock
A deadlock occurs in Figure 7-10 because the transition does not occur unless "B1/B2/B3/B4"
are all synchronized. Therefore, the synchronized transition is used. The synchronizedtransition and synchronized state cannot be used at the same time.

7.3.1

Synchronization number

A

B

B1

B2

C

B3

B4

E1

0
/

1
2
=>A(*1) =>C(*2)

3=>0 (*1)

4=>5(*2)

5
=>B

E2

B

=>0 (*1)=>A (*1)=>C(*2)=>A=>5(*2)

Figure 7- 11 Synchronized transition
The synchronized transition is indicated by (*n). The n is called a synchronization number.
Synchronization works only with states having the same synchronization number. Therefore,
when a transition of "B1" to "A" occurs after accepting "E1," a transition of "B3," which has thesame synchronization number, to the "A" state will be waited. During this wait, "B2" and "B4"will accept events and execute corresponding actions, but transitions will not occur. To disable
the actions also, use the optional specifications of the CASE tool that supports the EHSTM.
The synchronized transition is performed on a first-come, first-served basis. When "B2"
executes "E1" first, for example, it waits for the synchronization of the "C" state.
The contention of transition type is also solved on a first-come, first-served basis. If a wait forsynchronization occurs in a fixed transition first, the transition type after synchronization is
ignored even if it is a memorized type, and a fixed transition is performed.

59

½ Transition

7.3.2 Wildcard transition
A wildcard transition can be specified for the synchronized transition. A wildcard transition isrepresented by (**).
A

E1
E2

0
1

B

C

B1

B2

B3

B4

0

1

2

3

4

/
B

=>A(*1)=>0(*2)=>C=>5=>0(*1)=>A(**)

=>5
=>C

5
=>B
=>A

Figure 7- 12 Wildcard transition
The wildcard transition is a special type of synchronized transition. It has the characteristic ofadjusting to all synchronization numbers. When “E1” occurs first in “B1” and transfers to "A,"
"B3" can synchronize to either "E1" or "E2."
If "E1" occurs first for "B1," (*2) becomes the synchronization number. Therefore, "B3" waits for"E2" to occur at the wildcard transition. When "E1" occurs for "B3," the transition is ignored
even though the action is executed. The wildcard becomes the object of synchronization.
If "E2" is activated first for "B3," the one executed next becomes the synchronization
number. Even if a transition without a synchronization number occurs while waiting forsynchronization at the wildcard transition, the transition is ignored, since it is ignored by
the synchronized transition.

60

½Transition

7.3.3 Synchronized state and synchronized transition
The synchronized state is explained in 5.3.12, "Synchronized state." The difference between
the synchronized state and synchronized transition is that the synchronized transition can
specify the transition destination for the synchronization in more detail.

HEAD
PLAY

MOTOR
RECORD
STOP

PAUSE

IN
OPERATION

PLAY
OFF

MOTOR OFF=>ν1.1>NORMALNO_TAPE

RECORDOFFSTOPNORMAL
FAST FORWARD

REWIND=>In operation
(P)

PAUSE

NORMAL

Figure 7- 13 Synchronized state example
Let’s consider a practical example. See Figure 7-13. The state transitions of "HEAD" and"MOTOR," which are the concurrent child states, will be synchronized because "TAPE" is asynchronized state. Transitions within "HEAD" and "MOTOR" are unrelated to synchronization.
The transitions affected by the synchronization are the ones that exit "TAPE," which is theparent state of "HEAD" and "MOTOR." In this example, =>NO_TAPE will be synchronized.
Even if a transition from "HEAD" to the "NO_TAPE" state occurs first, the "HEAD" will wait until
a transition of "MOTOR" to the "NO_TAPE" state occurs.

61½ Transition

HEAD
PLAY

MOTOR
RECORD
STOP

PLAY OFF

PAUSE

IN
OPERATION

MOTOR
OFF
=>ν1.1>NORMALNO_TAPE

RECORDOFFSTOPNORMALFAST
FORWARD

REWINDIn operation

PAUSE

NORMAL

Figure 7- 14 Synchronized transition example
The synchronized transition synchronizes the specified transitions. In Figure 7-14, (*1) is
specified in four locations. The synchronized transition (*1) is specified for synchronizing atransition to "NO_TAPE" while "HEAD" and "MOTOR" are in operation.
However, when "HEAD" is "OFF" or "MOTOR" is "STOP," caution must be taken when thesynchronized transition and normal transition are mixed because no special synchronization isnecessary. When "HEAD" is "OFF" the "PLAY" and "MOTOR" is "PAUSE," a transition to"NO_TAPE" will occur independently when "HEAD" accepts an "OUT TAPE" event, even if"MOTOR" wants to synchronize. As is shown in the example, the wildcard transition can be
specified when the other end wants to synchronize even if the own side does not necessarily
require synchronization.

62

½Transition.MOTORHEAD
PLAYRECORDSTOPINOPERATION

MOTOR
OFF
=>ν1.1>NORMALNO_TAPE

RECORD
OFF

PLAY OFF

PAUSE

STOP
NORMAL

Figure 7- 15 Wildcard example
Specifying a wildcard transition can match with the synchronization of the other. When a normaltransition occurs during a WAIT of the wildcard transition, the normal transition is ignored.
When a synchronized transition (*1) occurs during a WAIT of the wildcard transition, thesynchronized transition (*1) is used. The wildcard transition cannot coexist with thesynchronization state, since the synchronized transition cannot.
A "-" symbol is used just like -(**) for executing synchronization only, according to the transition
destination of the concurrent brother state when the transition destination cannot be decided byits own state.

7.3.4 Forced transition
The forced transition is used to make a transition happen forcibly. The forced transition can beused with the synchronized state. A forced transition to state number 0 occurs when 0(*) isused. To use a forced transition to make a forcible transition to the transition destination
currently waiting for synchronization, write as -(*), as in the wildcard transition.

A

B

C

B1

B2

B3

B4

0

1

2

3

4

5

E1

0

/

=>A

=>C

=>0

=>5

=>B

E2

1

B

=>0

=>5

=>A

=>C

=>A

Timeout 2/=>-(*)=>A(*)=>0(*)=>-(*)/

Figure 7- 16 Forced transition63

½ Transition

7.4. Transition range
Making a transition within its own STM (a sheet of STM) is called a local transition. A transitionof another STM is called a global transition. Therefore, all transitions without hierarchies shallbe local transitions. There is one transition destination for each STM. Even though multiple
STM transitions can be specified according to the hierarchy, only one transition destination canbe specified for each STM.
An example of the state hierarchy for the videocassette recorder in Figure 7-5 is shown in
Figure 7-17.

Figure 7- 17 STM for a videocassette recorder (4)There are no synchronized or wildcard transitions for global transitions. This is because global
transition is synonymous with forced transition, in the sense that the transition is forced. For
global transition, write as 1.1>- in order to make a forced transition to the transition destinationthat is in a wait for synchronization.

64

½Transition

7.5. Format of transition
Local transitions
Transition destination name (transition type specification *n)
The transition destination name has to be a unique name.
Separate by a colon (:) if the name becomes unique in conjunction withthe parent state.
state1:state2:state3
Transition destination number (transition type specification *n)Transition type specification
D: Fixed type
H: Memorized type
P: Deep-memorized typeThe deep-memorized type is used when omitted.
*nForced transition by * only.
Wildcard transition when * is used for n.
n is the number that indicates the synchronization type.
Non-numeric characters are allowed in some CASE tools that
support the EHSTM design method.
Global transitions
Local
transition
destination
name
Local
transition
destination
number(*)The

or

STM
name

/

STM
number>Transition destination name(transition type)Transition destination
number (transition type)attached to the head of STM names may be omitted.

Figure 7- 18 Syntax of global transition

For transitions from the action area=> local transition=> global transition
Example=>OFF=>3/ 1.1>265

¾Activity

8. Activity
The activity is a function or process that is called under specific circumstances. The specificcircumstances include the situation in which an event is detected or when a state transition
occurs. A function or process called when the specific event occurs during the specific state isan action. Figure 8-1 shows the classification of activities.
Activity

Event

Analyzer

Start

End
Hit

Start
End

State

Start
Mode(*)End
Dispatch(*)
Trigger
STM mainStartEnd(*)cannot be used for an event-driven STM.

Figure 8- 1 Classification of activities
8.1. Event activity
The event activities are used for imbedding regular processing related to event occurrences.

Event

Event occurred!
Perform event-analyzer activity.

Event-analyzer activity
Event AEvent BThe event isdetermined as event
B!
Perform event-hit
activity.

Event C

Figure 8- 2 Event activity

67

¾Activity

The event-analyzer activity begins the activity if one exists when an event has occurred or isconsidered to have occurred before event-analyzer processing is executed. The event-hit
activity begins the activity if one exists under circumstances in which the specific event has
occurred (after the event analyzer has been executed).
The event-analyzer and event-hit activities can be used together. There are three methods ofevent analysis, and these can be mixed. Refer to Section 4.3, "Mixed events," for more about
mixed events.
There are six kinds of event-analyzer activities:
Event analyzer

MessageStart activity
End activity

Flag

Start activity
End activity

In-mailStart activity
End activity

There are ten kinds of event-hit activities:
Event hit

MessageStart activity
End activity

Flag

Start activity
End activity

In-maiStart activity
End activity

Interrupt

Start activity
End activity

Function callStart activity
End activity

There are usable and unusable event activities, depending on the STM driven type.

&: The details of the event analyzer and STM driven type are explained in 9, "Event analyzer,"and 11, "Driven type," respectively.

68

¾Activity

8.1.1. Event-analyzer start activity
The Event Analyzer Start Activity (EASA) is executed before event analyzer processing is
executed. It is always called for flag events and when the STMs driven type is the state-driven
type.
Disconnected
Message formaking a phonecall

On the phone

Dial

Voice fromthe other
party

State themessage
Hang upBusy tone

Hang up(EASA) Interrupt the current activity

Figure 8- 3 Event-analyzer start activity
When an EASA is set as shown above, "Interrupt the current activity" processing is called when
all events including "Message for making a phone call," "Voice from the other party" and "Busytone" have occurred.

&: The details of the STM driven type are explained in 11, "Driven type."
8.1.2. Event analyzer end activity
The Event-Analyzer End Activity (EAEA) is executed immediately before the wait for the next
event after event-analyzer processing is executed, and actions and transitions are processed if
any of those exist. It is always called for flag events and when the STM driven type is the statedriven type.
Disconnected
Message formaking a phone
call
Voice fromthe other
party
Busy tone

On the phone

Dial

State themessage
Hang upHang up(EASA) Return to the interrupted activity

Figure 8- 4 Event-analyzer end activity
When the EAEA is set as shown above, "Return to the interrupted activity" processing is called
which waiting for the next event after all events including "Message for making a phone call,""Voice from the other end" and "Busy tone" have occurred and the actions and transitions havebeen completed.

69

¾Activity

8.1.3. Event-hit start activity
The Event-Hit Start Activity (EHSA) is executed when the generated event is analyzed via theexecution of event analyzer processing.
Disconnected

Message formaking a phonecall

On the phone

Dial

Voice fromthe other
party

State themessage
Hang up(EHSA) Take a note
Busy tone

Hang up

Figure 8- 5 Event-hit start activity
When the "Message for making a phone call" event occurs, the "Take a note" activity is called.

8.1.4. Event-hit end activity
The Event-Hit End Activity (EHEA) is called when the actions and transitions have been finishedafter event analyzer processing is executed and the generated event is analyzed.
Disconnected On the phone

Message formaking a phone
call
Voice fromthe other
party

Dial

State themessage
Hang up(EHEA) Discard the note
Busy tone

Hang up

Figure 8- 6 Event-hit end activity
When "Message for making a phone call" occurs during the "Disconnected" state, the "Dial"
action is executed and a transition to "Busy" occurs. Then, the "Discard the note" activity is
executed.
The example of the above event-analyzer activity has the same meaning as describing theactions as follows:70

¾Activity

Disconnected
Message formaking a phonecall

On the phone

Take a note
Dial
Discard the
memo

Voice fromthe other
party

State themessage
Hang upBusy tone

Hang up

Figure 8- 7 Event-hit activity
8.2. State activity
The state activity is executed at intervals when the state becomes active or inactive.
&: Refer to 10.5, "State scheduler and activity," for more about the activation timing of thestate activity.
8.2.1. State start activity
The start activity (SSA) is executed when the applicable state becomes active as a result of astate transition.

Disconnected

Message formaking a phone
call
Voice fromthe other
party
Busy tone

On the phone

Dial
State themessage
Hang upHang up(SSA) Pick up a pen

Figure 8- 8 State start activity
Assume that a "Message for making a phone call" occurs during the "Disconnected" state. The"Dial" action is executed, and a transition occurs from the "Disconnected" state to the "Busy"state, thus activating the "Busy" state. The "Pick up a pen" activity is executed at this time.

71

¾Activity

8.2.2. State mode activity
The state mode activity (SMA) is executed at all times while the state is active. The SMA
cannot be used if the STM-driven type is the event-driven type.
Disconnected

Message formaking a phonecall

On the phone

Dial

Voice fromthe other
party

State themessage
Hang upBusy tone

Hang up(SMA) Draw a circle
Figure 8- 9 State mode activity
The "Draw a circle" activity is called as long as the "On the phone" state remains active.
8.2.3. State end activity
The state end activity (SEA) is called when the state becomes inactive.

Disconnected

Message formaking a phone
call
Voice fromthe other
party
Busy tone

On the phone

Dial

State themessage
Hang upHang up(SEA) Put the pen down

Figure 8- 10 State end activity
After the "Voice from the other party" or "Busy tone" event occurs during the "Busy" state andthe "State the message, hang up" or "Hang up" action is executed, the "Put down the pen "activity is executed immediately before a transition from the "Busy" state to the "Disconnected"
state occurs.
If the SSA is set in the "Disconnected" state, it is executed once the "Put down the pen " activity
is complete.
&: The execution order of SSA, SSE and actions can be changed. This will be explained in
8.6, "Order of actions and activities."72

¾Activity

8.3. Dispatch activity
The dispatch activity is activated each time a dispatch occurs. A dispatch is a switch of states inthe state-driven STM. It is different from the state mode activity, in which the scheduled activity
associated with a state is activated. Even if the function to be described as the dispatch activity
is described as the state start activity for all functions, it cannot substitute the dispatch activity.
This is because the dispatch activity is also executed at the moment the ready state ischanged to active in order to achieve the concurrent state, in addition to activation via
the occurrence of a transition. Rather, describing in the state mode activities of all states cansubstitute for dispatch activity. The state type of the state-driven STM is the same regardless ofwhether it is the exclusive or concurrent type. Normally, the dispatch activity is described when
the system has to be monitored and controlled at all times.
The dispatch activity does not exist for the event-driven STM because there is no Dispatching ofstates. If the event is P-type in the event-driven STM, the event-hit activity substitutes thedispatch activity.
ZKILL

DEAD
ZKILL

ZALIVEeState transition
did not hit

SUSPEND

Synchronizedtransition
release

WAIT

e

s

Wait forsynchronizedtransition

State transition did not hit
State transition hit
Event analyzer for theprevious completed state m

READY
d

Event analyzer forthe completed state

ACTIVEs

Start

d DispatcheEndm ModeFigure 8-11 State transition of state driven STM states73

¾Activity

Disconnected On the phone

Message formaking a phone
call

Dial

Voice fromthe other
party

State themessage
Hang upBusy tone

Hang up(D)"Monitor if birds come to eat the food"Figure 8- 12 Dispatch activity
When the above STM is defined as a state-driven type, "Monitor if birds come to eat the food" isalways executed in any state.

&: The STM driven type is explained in 11, "Driven type."
8.4. Trigger activity
The trigger activity has the same characteristics as the trigger event.
Disconnected

Message formaking a phone
call
Voice fromthe other
party
Busy tone

On the phone

Dial
State themessage
Hang upHang up(T)"Place the food"Figure 8- 13 Trigger activity"Place the food" processing is executed immediately after the program designed by the above
STM starts the operation. Then, it waits for an event. Normally, the system's initial processing
is described as the trigger activity.

&: Refer to 4.4.8, "Trigger event," for the trigger event.

74

¾Activity

8.5.

STM main activity

The STM main is explained in Chapter 14. The STM main controls the calls of the statetransition matrix mechanism. The STM main’s start activity is the activity called before a seriesof state transition matrix mechanisms starts. The STM main’s end activity is the activity called
once the operation of a series of state transition table mechanisms is complete. Note that these
activities mark the start and end of the state transition matrix mechanism but not the start andend for the system. Such a delimiter (start and end) of the system is usually implemented bymeans of the state activity or event activity. The STM main usually has an infinite-loop
structure. The STM main’s start activity is called at the beginning of the infinite loop, which the
STM main end activity is called at the end of the loop.

…
while(1){
STM main start activity…
…
…
STM main end activity}
8.6.

Order of actions and activities

The order of actions and activities is as follows:
Action à End activity à Start activity
Even though the following orders can be used, the choice as to whether or not to implement
these orders depends on the specification of the tool supporting the EHSTM design method.
End activity à Action à Start activity
End activity à Start activity à Action
Specify '-' in the transition destination when executing the action only, without executing theactivity. If the same state number or state name as that of the current state is explicitly
specified, the state activity will run.

event1 1

state11

state22=>-=>2

Figure 8- 14 No transition specification

75

¾Activity

Because no transition or action is executed, a temporary operation can be processed byproviding an in-mail as an event.
The order of actual activities differs, depending on the STM driven type.
(1)For the event-driven type
1 STM main start
2 Trigger (executed only once at the activation)
3 Event-analyzer start
4 Event-hit start (not executed when the event does not hit)
5 State end (not executed in the initial state or when the transition does not occur)
6 State start (not executed when the transition does not occur)
7 Event-hit end (not executed when the event does not hit)
8 Event-analyzer end
9 Event-analyzer end
When the concurrent-type STM is used, 5 and 6 are repeated for the number of concurrent
states that are ready.
(2)For the state driven-type
1 STM main start
2 Trigger (executed only once at the activation)
3 Dispatch
4 State mode (not executed in the initial state)
5 Event-analyzer start (not executed in the initial state)
6 Event-hit start (not executed when the event does not hit)
7 State end (not executed in the initial state or when the transition does not occur)
8 State start (not executed when the transition does not occur)
9 Event-hit end (not executed when the event does not hit)
10
Event-analyzer end (not executed in the initial state)
11
STM main end
When the concurrent-type STM is used, → through ∝ are repeated for the number of concurrent
states that are ready.
The order of event analyzer execution is (1) message, (2) flag and (3) in-mail.

76

¾Activity

8.7.

Format of activity

Activities can describe mostly the same information as actions do.
1: Human-language statement
2: Computer-language statement
3: NS chart
4: Event hierarchy STM call
5: Subroutine STM call
6: Library STM call
7: Divided action cell
8: EHSTM system call
9: Transition symbol&: Refer to 6, "Action," for each action.

77

¾Activity

78¿Event analyzer

9. Event analyzer
The event analyzer is used to retrieve and analyze events, and for detecting the event number
on the STM. Therefore, to be precise, there are two types of tasks, event retrieval and event
analysis, and sometimes these are collectively called event analyzers. There are four types of
events: variable, interrupt, in-mail and function call.
9.1. Variable event analyzer
To analyze the variable, comparisons are made using conditional statements ("if" and "switch"statements) to detect what the variable event is. Refer to the example in Chapter 4.4 showing
what kind of event analyzer is generated from the event cell. The "if-else" rule is used as thedefault event analyzer for analyzing events in STM event cells, and the analysis is performed in
the order from the event with the youngest event number first.

Event A
Frame B
Frame A

Frame C

if(Frame A){// event-hit start activity
if(Frame B){
if(Event A){// event number 0}
else if(Event A){// event number 1}// event-hit end activity}
else if(Frame C){
if(Event C){// event number 2}
else if(Event D){// event number 3}}}

Event B
Event C
Event D

if(FrameA){// event-hit start activity
if(C){
if(Event D){// event number 3}if(Event C){// event number 2}}
if(Frame B){
if(Event B){// event number 1}
if(Event A){// event number 0}// event-hit end activity}}

Figure 9- 1 Event analyzer
Events are analyzed in the order from event number 3 to number 0, and the "if-if" rule is used
for the analysis rule. By using the "if-if" rule, a single event can drive the STM multiple times.
There may be cases in which the variable becomes the event number. In these cases, theevent analyzer is not executed and the STM is simply driven using the value of the variable.
&: Refer to 4, "Event," for event types.

79¿Event analyzer

9.2. Event analyzer and variable access method
There are three access methods for variable events: the mail type, synchronized type and flag
type. The access method specifies how to retrieve events regardless of the event analyzer.
This is called an event acquisition function.
9.2.1. Flag variable access method
The flag variable access method reads only the value of the variable directly, so no event
acquisition function is necessary. Access to the variable is achieved by executing the event
analyzer immediately. The change of variables can be monitored at all times by calling theevent analyzer from inside the infinite loop of the program.
9.2.2. Mail variable access method
If the event is set to the communication type using the RTOS, a procedure for retrieving
messages and copying messages to the variable (copying may not be necessary), etc., will benecessary. This procedure is written as the event acquisition function.

Entiremessage
contents

Eventacquisition
function

Messagepointer
Messagebody

Eventanalyzerfunction

Figure 9- 2 Communication variable access method
The message is a mechanism existing almost only for the event-driven structure. The use of
messages is recommended when designing a system using the event-driven exclusive-state
STM.
A task has a message at a single location (RCV_MSG). While there is no message, "wait" isused so that the CPU is not wasted. When a message arrives, it is picked up by the RTOS andthrown into the event analyzer. The event analyzer examines the message, retrieves the event
number and transfers the control to the STM drive mechanism.
Postal matters have several types, including postcards and envelopes. Likewise, messages

80¿Event analyzer

have various types. The entire content can be sent via a single message, or the body of themessage is placed in the global memory and the pointer to the memory storage is notified as amessage.
Task
MessageEventretrieval

MessageEventanalyzer

Figure 9- 3 Message and input port

The change in the input port cannot be known unless a message arrives, because the task does
not start until the message is delivered. By changing RCV_MSG to PRCV_MSG, the input port
can be monitored without shifting the task to "wait," even if there are no messages.
&: Refer to 4.2, "Variable access method," for variable access methods.
Refer to the documents relating to the RTOS for detailed operations.
9.2.3. Synchronized variable access method
If the synchronized variable access method is realized using the RTOS event flag (WAI_FLG),
the task does not occupy the CPU unnecessarily because the task waits until the event occurs.
Interrupt

Task

Interrupt
handler
WAI_FLG

• 0

• 0.1

ISET_FLG
EVENTFLAG ID• 0.2

Figure 9- 4 Synchronized type waiting for a single event
However, the task enters the wait for the WAI_FLG event flag, other flags cannot be monitored(9-5). This is not desirable for the STM design that would need to wait for multiple events.

81¿Event analyzer

Interrupt

Task
Interrupt
handler

WAI_FLG• 0• 0.1

ISET_FLG

Input port

EVENTFLA G ID

• 0.2

Figure 9- 5 Synchronized type waiting for multiple events
The task can monitor both flags in a single wait by connecting two handlers to EVENTFLAG(Figure 9-5). Even though the task could synchronize with handlers 1 and 2, it cannot know
which handler the setting is from. In this case, provide an external variable that shows the typeso that it can be known from which handler the setting comes. The event analyzer examines
this external variable.
Interrupt 1

Task

Interrupt
handler

1

WAI_FLG• 0• 0.1

ISET_FLG

Interrupt 2
Interrupt
handler2

EVENTFLA G ID

• 0.2

Figure 9- 6 Synchronized type waiting for multiple events with a single event flag
The WAI_FLG is convenient for achieving the concurrency of activation for multiple events
awaited by a task using a single flag set.

82¿Event analyzer

Interrupt
Interrupt
handler

Task
WAI_FLG• 0• 0.1

ISET_FLG
EVENTFLAG ID

• 0.2

Task
WAI_FLG

Figure 9- 7 Notifying multiple tasks simultaneously
9.3. In-mail analyzer
The in-mail analyzer analyzes the in-mail events. The in-mail does not care whether or not theRTOS is installed. The in-mail buffer defined by the STM is analyzed by the in-mail analyzer todrive the STM. The in-mail analyzer's default rule described in the event cell is the same as thatof the event analyzer. The in-mail analyzer and event analyzer are individually prepared foreach STM.
External
event

Messagequeue/variable

In-mail acquisition
function

In-mail analyzer
function

Event-acquisition
function

Event-analyzer
function

In-mail bufferInternal event

Figure 9- 8 In-mailBy default, the in-mail analyzer function is executed until the in-mail buffer becomes empty after
the event-analyzer function is completed.

83¿Event analyzer

while(TRUE){// event-acquisition function// event-analyzer function// STM drive
while (in-mail buffer becomes empty) {// in-mail acquisition function// in-mail analyzer function// STM drive
}
}
9.4.

Interrupt event analyzer

The interrupt event analyzer is created within the interrupt handler. Interrupts can be handled
by setting a variable from the interrupt handler so that interrupts can be received as polling
events, or by transmitting a message from the interrupt handler so that interrupts can bereceived as communication events, without writing in the STM directly as an interrupt type. If
the event is described directly to the STM as the interrupt type, the interrupt handler will drive
the STM. The interrupt type is separated from other events by drawing sloped lines at the topleft and bottom-right of the event column.

interrupt void DEV_I(void){switch(stat){case INIT_OK:
event nobreak;= 2;case INIT_ERR:
event nobreak;= 3;case READ_OK:
event nobreak;= 4;case READ_ERR:
event nobreak;= 5;} drive
STM
event no();}
interrupt void TimeOut(void){
event no= 6;
STM drive event no();}

int Dev_Init(DEVINFO* cInfo)

int Dev_Read(DEVINFO* cInfo) 1

DEV_I

INIT_OK2

INIT_ERR

3

stat
READ_OK 4
READ_ERR 5
TimeOut

Figure 9- 9 Interrupt typeThe default rule of the event analyzer is the same as that of the variable type.

84

0

6

¿Event analyzer

9.5. Function-call event analyzer
The function-call event analyzer has the same mechanism as the interrupt event analyzer. The
event analyzer is executed in a function of the function-call type, and the STM is driven.

int Dev_Init(DEVINFO* cInfo){= 0;
event no(
);
STM
drive
event
}
(

0

int Dev_Read(DEVINFO* cInfo) 1

number

int Dev_Read(DEVINFO* cInfo){= 1;
event no();
event
}STM drive(

int Dev_Init(DEVINFO* cInfo)

number

DEV_I

INIT_OK2

INIT_ERR

3

stat
READ_OK 4
READ_ERR 5
TimeOut

6

Figure 9- 10 Function-call type85

¿Event analyzer

86ÀState scheduler

10. State scheduler
The state scheduler schedules the state described in the STM. Even for the exclusive state
STM in which all of the states are exclusive, a parent schedule occurs when an activity is
installed in the state frame.

ZKILL

DEAD
ZKILL
Missed by state transition

ZALIVEe

SUSPEND

Cancelsynchronizedtransition

WAITe
Wait forsynchronizedtransition

Missed by state transitions

Hit by state transition
Event analyzer for the previous
state is complete
m

READY
d

Event analyzer for the stateis complete

ACTIVEs Startd Dispatchem ModeEnd

Figure 10- 1 State scheduler
The following schedules occur:(1)Parent-and-child schedule(2)Concurrent schedule(3)State tree schedule
There are occasions when you will wish to set priorities for the states, especially the concurrent
states. In EHSTM Ver. 2, the state priority can only be defined by the scheduling as described
below. The detailed definition of a state priority depends on the specification of the CASE tool
supporting state schedulers. EHSTM Ver. 3 will have the priority definition of states and events.

87ÀState scheduler

10.1. Parent-and-child schedule
When the child state is specified as the transition destination, its parent becomes ready first.
Telephone

Disconnected

Message formaking a phone
call
Voice from theother party

On the phone

Dial
State the message
Hang up

Mute

Busy tone
Hang up
Interested
programTurn TV on

End ofprogramTurn TV off

Turn TV off

Figure 10- 2 STM of telephone and TV
See the example for telephone and TV in Figure 10-2 .

¡[Telephone]¡ [TV]¡[Disconnected][On the phone]
˜[OFF][ON][NORMAL][MUTE]¡Ready:˜Active

Assume the "Interested program" event occurs during the "OFF" state. After the "Turn TV on"
action is executed, a state transition to "NORMAL," which has state number 3, occurs. The
order of readiness is "ON," then "NORMAL." When the child is the transition destination, theparent always becomes ready first. The order of switching from READY to SUSPEND is fromchild to parent.

¡[Telephone]¡[Disconnected][On the phone]¡ [TV]

[OFF]
¡[ON]

˜ [NORMAL][MUTE]¡Ready:˜Active

When the "End of program" event occurs during the "NORMAL" state and upon transition to the"OFF" state, "ON" and "NORMAL," which have been READY or ACTIVE until now, become
SUSPEND in the order of from "NORMAL" to "ON."88ÀState scheduler

10.2. Concurrent schedule
There are two types of concurrent schedules:(1)Default type (D-type)(2)Dispatch type (P-type)
By the default type, the priority of switching for the concurrent state to READY and ACTIVE isgiven to the default side. By the dispatch type, the entry to the right of the state that became
READY first the previous time is switched to READY first. The priority returns to the HEAD if
there is nothing to its right. In other words, the READY priority of the concurrent statescirculates.

HEAD
PLAY

MOTOR
In operation

RECORDSTOP

PAUSENORMAL FAST
REWINDFORWARD

In
operation(P)

Figure 10- 3 Videocassette recorder STM[OFF]¡ [ON]

˜ [NO_TAPE][TAPE][HEAD][MOTOR][PLAY][OFF][ON][RECORD]

[OFF]
[ON]

[STOP][PAUSE][In operation][NORMAL][FAST FORWARD][REWIND]

89ÀState scheduler

When the "IN TAPE" event occurs, a transition to "TAPE" occurs. Because "HEAD" and"MOTOR" are concurrent, "HEAD" always becomes READY before "MOTOR" if the default typeis set for the concurrent schedule. If the dispatch type is selected for the concurrent type, the
READY priority is given to “MOTOR” if “HEAD” took priority previously, and the priority
circulates among concurrent brother states.
[OFF]¡ [ON ]

˜ [NO_TAPE][TAPE]¡ [HEAD]¡ [PLAY][RECORD]¡ [MOTOR][STOP][PAUSE]¡ [In operation][OFF]¡ [ON][OFF][ON][NORMAL][FAST FORWARD][REWIND]

Assume a videocassette recorder as described above is in the “PLAY” state and an "OUTTAPE" event occurs when the "TAPE" state is active. The order of changing from READY to
SUSPEND is from child to parent. This is the reverse of the order in which SUSPEND becomes
READY, i.e., from parent to child. If the order of changing from SUSPEND to READY is"TAPE" -> "HEAD" -> "PLAY" -> "ON" -> "MOTOR" -> "In operation" -> "NORMAL,"
the order of switching from READY to SUSPEND will be as follows:"TAPE" <- "HEAD" <- "PLAY" <- "ON" <- "MOTOR" <- "In operation" <- "NORMAL"
Even if a transition occurs from the "ON" state and causes to suspend READY, the "ON" state
does not become SUSPEND first.

90ÀState scheduler

10.3. Tree schedule
There are two types of tree schedules:(1) Vertical type (V-type)(2) Horizontal type (H-type)The vertical tree schedule operates by giving priorities to parent-and-child relationships upon
the change from SUSPEND to READY. The horizontal tree schedule operates by giving
priorities to brother relationships upon the change from SUSPEND to READY.

HEAD
PLAY

MOTOR
IN OPERATION

RECORDSTOP

PAUSENORMALFAST
FORWARD

REWINDIn
operation(P)

Figure 10- 4 Videocassette recorder STM
[OFF]
¡[ON]

˜[NO_TAPE][TAPE][HEAD][PLAY][RECORD][MOTOR][STOP][PAUSE][IN OPERATION]

[OFF]
[ON]
[OFF]
[ON]

[NORMAL][FAST FORWARD][REWIND]"NO_TAPE" makes a transition to the "TAPE" state when it accepts an "IN TAPE" event during
the active state. At this time, changes from SUSPEND to READY occur in the following order if
vertical (parent type) scheduling is specified:"TAPE" à "HEAD" à "PLAY" à "OFF" à "MOTOR" à "STOP"
When the horizontal (brother type) scheduling is specified, the order is:91ÀState scheduler"TAPE" à "HEAD" à "MOTOR" à "PLAY" à "STOP" à "OFF"Changes from READY to SUSPEND will follow the above order in reverse.

10.4. State scheduler and transition
The three transition types (default transition, history transition and deep history transition) do notaffect the concurrent scheduler types.
For example, if the transition "=>TAPE" described in the action cell for state number [2] of event
number [2] is changed to "=>TAPE(D)," the child state of "HEAD" is simply changed to "PLAY"
and "OFF" is selected as the child state of "PLAY." This is not for specifying the priority of theschedule. If "=>TAPE(H)" is stated, the one that was READY last time is simply selected as thechild state of "HEAD" and the default is specified for the grandchild, but the priority of theschedule is not specified. If "=>TAPE(P)" is stated, the child state of "HEAD" is simply selectedto the one that was READY previously, and the one that was READY last time is specified forthe grandchild, also. Specifying the priority of the schedule is independent of this operation.
10.5. State scheduler and activity
The event activities and trigger activities are not related to the state scheduler. On the other
hand, the state activity and dispatch activity are related to the state scheduler. This relationshipis shown in Figure 10-5.
The state start activity is executed when SUSPEND changes to READY. The state end activity
is executed when READY changes to SUSPEND. The state mode activity is executed as longas it is active. A dispatch activity is executed each time a dispatch occurs.

92ÀState scheduler

ZKILL

DEAD
ZKILL

ZALIVEe

SUSPEND

state transition did not hit

Releasesynchronizedtransition

WAIT

e

Wait forsynchronizedtransition

state transition did not hits

Hit by state transition

READY
d

Event analyzer for themprevious completed state

ACTIVE

Event analyzer forthe completed state

s

Start

d DispatcheEndm ModeFigure 10- 5 State scheduler STD

SUSPEND READY ACTIVE DEAD WAIT
0

1

s

/

2
Transition
symbolHit by state transition
Hit by state transition
0

Missed by state transition
Event analyzer for theprevious state is complete
Missed by state transition

/

2

Î

Event analyzer for the state
analyzer for theis Event
completeprevious state is complete

else=>READY

1

3

/

/

/

/

/

Î

Î

/

d

Î

e

s

e

e

=> SUSPEND=>SUSPEND

dm

4=>ACTIVE

Event analyzer for the stateis complete

Î
3

Î

/

=>READY

ZKILL

4=>DEAD=>DEADÎ//ZALIVE

5///=>SUSPEND/

6

Î

=>WAITÎ/

Wait for the synchronizedtransition
Release synchronizedtransition

7

Î

Î
Î

/

Î

=>SUSPEND

Figure 10- 6 State scheduler STM

93ÀState scheduler

10.6.

State scheduler and interrupt event

All interrupt events perform event-driven actions regardless of whether the driven type isdefined as event-driven or state-driven. In other words, all action cells that cross with READY
concurrent states are called.

INT

state1state2state3

Action1

Action2

Action3

Figure 10- 7 Interrupt event for concurrent states
In Figure 4-24, Action1, Action2 and Action3 are called when the "INT" occurs. The order of thecalls depends on the state scheduler. The function that keeps the same schedule order byinitializing the READY authority upon interrupt is not specified in this document, but depends on
the specification of the tool supporting the EHSTM.

&: Refer to 8, "Activity," 11, "Driven type," 5, "State" and 4, "Event," for the activity, driven type,concurrent state and interrupt event, respectively.

10.7. Format of state scheduler
The state scheduler is not specified on the STM. It is usually set as a property of the STM by
the tool that supports the EHSTM design method.

94Á Driven types

11. Driven type
There are two driven types of STMs: the event-driven type (E-type) and state-driven type (Stype).

11.1. Event-driven typeThe event-driven type waits for events at one location in the program. For the wait method theRTOS structure can be used if it is installed, or sensing of the flag (so-called polling) by the
program may also be used. The important thing is to wait for an event at a single location,
making it possible to receive any event under any state. The received event undergoes theevent analysis and the event number assigned within the STM is calculated, then the action atwhich the event and current state number cross is called.
Event-driven type

Event
£0

Event
analyzer

Figure 11- 1 Event-driven type

TELEPHONE

DISCONNECTE

Message formaking a phone
call
Voice from theother party

Busy tone
Interested
program

ON THE PHONE

Dial
State the message
Hang up

Mute

Hang upTurn TV on

End of program
Turn TV off

Turn TV off

Figure 11- 2 STM of telephone and TV

95Á Driven types

We’ll use the example of a telephone and TV in Figure 11-2. When the currently ready statesare "Telephone"-"Disconnected" and "TV"-"OFF," there is no scheduling of a state in the eventdriven type. Instead, events are awaited at a single location. When an event occurs after awhile, the ready states are activated in sequence. Vertical scheduling and horizontal schedulingare the types used for specifying the sequence. In addition, default scheduling and dispatch
scheduling are used as the priority scheduling for concurrent states. In this way, the eventdriven type activates the state only after an event occurs.
The event-driven STM is declared in the highest-level STM via the ¨ symbol.

11.2. State-driven typeThe state-driven type monitors events for each state. It does not wait for (or does not analyze,
to be more accurate) events pertaining to no use or invalidity in the matrix. The “cyclic
executive” is easily performed for the S-type because it accepts events for each state and theevents to be analyzed for the state are predetermined.
State-driven type

Event
analyzer

Event

Figure 11- 3 State-driven typeLet’s use the example of the telephone and TV in Figure 11-2. In the state-driven type, when
the states currently ready are "Telephone"-"Disconnected" and "TV"-"OFF," the event-analyzer
function associated with each state is initiated and whether or not an event has occurred ischecked each time one of the "Telephone," "Disconnected," "TV" or "OFF" states is activated.
Even if no event has occurred, one of the states is always active.
The state-driven STM is declared in the highest-level STM using the ν symbol.

96Á Driven types

11.3. Driven type and event
Caution should be exercised concerning the types of handled events depending on the driven
type.
RTOS not required(it can exist)
Polling type

Eventdriven
type

Statedriven
type

CPU resource
problemInterrupt
type

RTOS required
Synchronized
type

Messagetype

Queuemanagement
problem

Task wait
problem

Task wait problem

Figure 11- 4 Driven types and event types
In the event-driven STM, events are awaited at a single location within the program. If pollingtype events are handled by the event-driven type, the CPU resource is always used. This is not
a problem, however, when the RTOS is not installed or when there is only one task, even if it isinstalled. When synchronized events are handled by the event-driven type, one event flag isshared. Then, a variable is necessary to identify the specific event from the shared event flag.
When a variable is used, it is necessary to pay attention if it is overwritten. If the variable isoverwritten, it has to be in the form of a queue.
The state-driven type has a structure that accepts events in each state. When synchronized
events are handled by the state-driven type, the task waits for synchronization within the event
analyzer associated with a single state. Therefore, even in the concurrent state, the task itself
will be in the wait state and concurrent processing may not be possible. This also applies tomessage events.

97Á Driven types

11.4. Driven type and state
In the event-driven type, a state is activated at the time the event is captured. In the statedriven type, the state scheduler activates a state via dispatch.
State
type
Driventype

Exclusive

Concurrent

Eventdriven
type

All events are awaited at asingle location.
Call actions from a single
state.

All events are awaited at asingle location.
Call actions from multiple
states.

Statedriventype

A single state checks whether
the specific event has
occurred.

Multiple states check
whether the specific event
has occurred.

Figure 11- 5 Driven type and state type11.5. Driven type and action
In either driven type, the action cell is executed where the event occurred and the currently
active state cross.
11.6. Driven type and transition
Transitions are executed in the same way for either driven type.
11.7. Driven type and activity
In the event-driven type, the dispatch activities and state-mode activities cannot be usedbecause the state scheduler is not operating all the time but is activated when an event isreceived.

Event-driven
type
State-driven
type

State
start

State
end

State
mode

Dispatch

Event
Analyzer
start

Event
Analyzer
end

Event hit
start

Event hitend

Trigger

•

•

×

×

•

•

•

•

•

•

•

•

•

•

•

•

•

•

Figure 11- 6 Driven type and activities98Á Driven types

11.8. Driven type and event analyzer
There is no close relationship between the driven type and the event analyzer. There are threekinds of event analyzers: the message (mail or synchronized) event analyzer, flag event
analyzer and in-mail event analyzer. These event analyzers can be allocated to each STM orstate.
TELEPHONE

DISCONNECTED

Message formaking a phone
call
Voice from theother party

ON THE PHONE

Dial
State the message
Hang up

Mute

Busy tone
Hang up
Interested
program
End ofprogramTurn TV on

Turn TV off

Turn TV off

Figure 11- 7 STM of telephone and TV
The following shows the event analyzer of Figure 11-7 created for each STM.
if(message for making a phone call){// event number 0}
else if(voice from the other party){// event number 1}
else if(busy tone){// event number 2}
else if(interested program ){// event number 3}
else if(end of the program){// event number 4}99Á Driven types

The following shows the event analyzer of Figure 11-7 created for each state.
(1)Event analyzer associated with the "Disconnected" stateif(message for making a phone call){// event number 0}(2)Event analyzer associated with the "Busy" stateif(voice from the other party){// event number 1}
else if(busy tone){// event number 2}(3)Event analyzer associated with the "OFF" state
if(interested program){// event number 3}(4)Event analyzer associated with the "NORMAL" stateif(voice from the other party){// event number 1}
else if(end of the program){// event number 4}(5)Event analyzer associated with the "MUTE" stateif(end of the program ){// event number 4}
The event analyzer defined for each STM can be used in the event-driven or state-driven
program structure.

100ÂDepartment

12. Department
The department is a framework that defines the target of the STM design.
The following departments can be designed by the STM in the implementation environment for
which no RTOS is installed:(1)
Main section(2)
Library section(3)
Interrupt-handler section(4)
Device-register section
The following departments can be designed by the STM in the implementation environment for
which the RTOS is installed:
(1)
(2)
(3)
(4)
(5)

Task section
Library section
Interrupt-handler section
Device-driver section
Device-register section101ÂDepartment

12.1. Department under non-RTOS
The main section enters an infinite loop, the event analyzer of the main STM is executed, and thevariable event is captured. The device-register STM becomes the external environment from theCPU's viewpoint and generates interrupts. The interrupt is captured by the interrupt-handler STM,
then the result is written to the variable and passed to the main section. The library section is called
as a function-call event from the action or activity of the main section. The device section is an
STM that describes how to respond to command registers such as various LSIs. This STM does
not usually become a program code, but is used for simulations conducted without the target or
code.
External-environment
target STM

Design target
STM

Library B STM

Flag event A
Device-register
A STM

Interrupt-handler
A STM

Main (O) STM

Library C STM

Hierarchy (0,1) Hierarchy (0,2)
STM
STM

Device-register
B STM(IO) library
STM

Flag event B

Subroutine A
STM

Subroutine B
STM

Figure 12- 1 RTOS Departments under non-RTOS
There are cases in which an interrupt event is incorporated in the main STM but the STM for theinterrupt-handler section is not created. When the main section needs to be conscious of interrupts,
design so that the main section handles interrupt events. When state management via the interrupt
handler is necessary, create the interrupt-handler STM.

102ÂDepartment

12.2. Department under RTOS
The RTOS implements the multitask structure instead of the single-path program structure. A task
STM is designed for each task. The library section is called from the task section via a function-callevent. Exclusive control when sharing the library among tasks is performed using the semaphoremechanism of the RTOS within the action of the task section. It is convenient when message-type
events are used in the task section, because events from device drivers and other tasks can be
accepted. The events can be used as synchronized events for analyzing variables, or as flag
events. Refer to Chapter 9, "Event Analyzer." Interrupts are captured by the interrupt-handler
STM. The device-driver section is called from a task as a function call, capturing interrupt events.
Externalenvironment
target STM

Deviceregister A
STM

Device register B
STM

Design target
STM

Interrupt
handler A
STM(IO) library
STM

OS

Task (1)subroutine
STM

Task (1)library
STM

Commonsubroutine
STM

Commonlibrary
STM

Task (2)subroutine
STM

Task (2)library
STM

Hierarchy (1.1) Hierarchy (1.2)
STM
STM

Task (2)
STM

Hierarchy (2.1)
STM

Hierarchy (2.2)
STM

Device register C
STM

Figure 12- 2 Departments under RTOS
In general, when the RTOS is installed, the interrupt handler and device driver are placed under
RTOS control or manipulated by each manager layer of the RTOS. The basic STM mechanism isthe control of calling and returning of functions. A CASE tool that simulates the state-transition
matrix is required to support the operations of the following: call of the RTOS or manager layer,interrupt handler and device driver, return-operation control and system-call operation for each
RTOS. This document does not cover these operations; it only defines the description method of
the state transfer matrix.

103ÂDepartment

12.3. Main/Task STM
The main STM and task STM are declared as follows:(return-value type) (driven type) STM name (number of clones) (argument)(1) Items in parentheses ( ) can be omitted.
(2) Driven type:£(event-driven or event hierarchy)¢(state-driven or state hierarchy)(3) STM name: A number starting with 0 when a hierarchy exists.
(4) Number of clones: Write the number of clones in [ ].
Clones cannot be used in the state hierarchy.
Declaration example:int £sample[2](char *lpstat1, int icode)
Call example£1.1[0]:0(lp1,p2,p3)
STM main

Event analyzer

STM (drive section)

Event-obtain function
Event-analyzer function call
Can pass arguments
Event analyzer

returnCan return a return value
In-mail obtain function
In-mail analyzer call
Can pass arguments

Activity
ActionreturnTransition
Can return a return value

In-mail analyzer

returnCan return a return value

returnCan return a return value

Activity
ActionTransition

Figure 12- 3 Sequence diagram for main/task STM&: Refer to 13, "Clone STM," for the clone.
Refer to 14, "STM Main," for the STM main.

104ÂDepartment

12.4. Library STM
The library STM is declared as follows:(return-value type) (driven type) STM name (number of clones) (argument)(1) Items in parentheses ( ) can be omitted.
(2) Driven type:™(Event-driven or event hierarchy)
˜(State-driven or state hierarchy)(3) STM name: A number starting with 0 when a hierarchy exists.
(4) Number of clones: Write the number of clones in [ ].
Clones cannot be used in the state hierarchy.
Declaration example: ™100
Call example: func(lpara1,para2)™100:func(lpara1,para2)
Functioncall

Caller function

Eventanalyzer

STM
drive
section

Function-call event
Event number

Activity, action, transition
returnEvent obtain
Event-analyzer call
Event analyzer
Activity, action, transition
returnreturnEvent obtain
Event-analyzer call
Event analyzer
Activity, action, transition
zret
returnreturnFigure 12- 4 Library STM operation sequence
The control is not returned to the caller STM unless "zret" is executed, because the library STM is105ÂDepartment

called as a function from the caller. The middleware STM1 in Figure 12-5 is used as an example forthe explanation.
UNUSEDINITIALIZEDCOMPRESSNORMALCOMPLETIONCONTINUE ABNORMAL

Figure 12- 5 Middleware STM
initial/*JPEG
JPEG• L’decompress
ƒ‰
·
ƒC
ƒ u
ƒ‰
ƒŠ
•library
Š ú
‰
‰ »
*/
jpeg_CompressInit(&(dInfo));/*ƒ bufferƒboƒtƒ processing
Ž æ
@
‚è
• ž
‚ Ý
• ˆ
— •
*/
get
getBuff(&(jpegBuff[0]));
begin
JPEG
*/
/*JPEG• L’ decompression
Š J
·
Ž *
n/
for(;;){
err = jpeg_Compress(&(dInfo));if(err == JPEG_CONT){
update/* ƒ oƒbƒbufferƒ@t• X•processing
• ˆ
V
— *
•/ */
getBuff(&(jpegBuff[0]));continue;}else if(err == JPEG_OK){
normal
*/
/*
• ³
• í
•completion— ¹
I*/
break;}else{
abnormalcompletion
*/
/*
*/
ˆ Ù
• í
• I
—
¹
break;}

Figure 12- 6 Middleware call
When jpeg_CompressInit() is called, the control is transferred to the STM and is not returned tothe caller until "zret" is executed. When jpeg_Compress() is called, the control is not returned to
1 NEC: µSAP703000-B03JPEG middleware (tentative)

106

COMPLETIONÂDepartment

the caller until the library STM executes "zret()" in response to JPEG_OK, JPEG_ERR or
JPEG_CONT. During this period, the event analyzer of the library STM is being processed.
The execution method for this event O(E-type) or ˜(S-type)) is declared in the called library
STM. All of the P, C and M types can be used for the event type. Care should be taken when
the M type is used, since the same message queue as the one used by the caller is used for thefunctions of the RTOS message mechanism. Normally, the P type is used for the event type ofthe library STM.
The analyzer can be executed using the arguments passed upon the function call as conditions.

short
req_io(UW iodvn,
T_REQIO *pk_rqio)(pk_rqio->iofn)

TIO_CI:TIO_LI:0

TIO_CO:TIO_LO:

1

init

in

out

0

1

2

2
default:

Reference:
Tsubota, Hideo:
TRONWARE Vol. 5:
’ Ø
“ c
• G
• :vTRONWARE
Vol.5
An
exampleµiTRONƒ ÊŽ d—using
l
Ž g
ð
‚OS
‚ ½
Á
—ofá
‘the
è
Ê Þ²½ÄÞ×²ÊÞ-Ž Q
• l
iTRON
OS‚the-ÃÞ
specification - Device Driver

short req_io(UW iodvn,TREQIO *pk_rqio){
int ev_no;switch(pk_rqio->iofn){case TIO_CI:
case TIO_LI:
ev_no = 0;
break;
case TIO
ev_no = 1;
break;
default:
ev_no = 2;
break;}
act(ev_no)}

Figure 12- 7 Function call arguments 2

2 Reference: Tsubota, Hideo, “TRONWARE Vol.5: An example using the OS of the µiTRON

specification - Device Driver –“107ÂDepartment

Let's take a closer look at the operations of the library STM.

[ int A(struct c* pc1)

[ int B(char c1, int i2)

EventX

EventY
Figure xx is used as an example. The operations in this case are shown in Figure xx.

[ int A(struct c* pc1)
j[ int B(char c1, int i2)

EventXk
EventYThe library STM is called by the function-call event (j). If zret() does not exist, it enters a loopthat waits for an event (k). Now there is an issue of how to pass the arguments upon entry tothis loop. Functions A and B have different numbers and types of arguments. The arguments
are declared using the frame upon entering the loop, as shown in Figure xx.

108ÂDepartment[ int A(struct c* pc1)
jk

pc1->m1,NULL[ int B(char c1, int i2)
c1,i2
EventXlchar ca
int ibf(ca,ib)m

EventYl is the declaration of arguments for the function comprising the loop, while jand k are thedeclarations of the arguments to be passed. With this method the arguments can be passed to
the function m described in the action cell.

[ int A(struct c* pc1)
jpc1->m1,NULL[ int B(char c1, int i2)
c1,i2

k

char ca
int ibEventXf(ca,ib)

EventYzret(x)The control returns to the caller when "zret" is executed at . An int-type value is returned inthis case, since the return values from functions A and B are the same type. A problem occurs
when the types of return values are different between functions A and B. In such cases, thedifference of return values should be solved through the use of different frames.

109ÂDepartment

k
k

j

k

[ void A(struct c* pc1)
EventX
EventY[ int B(char c1, int i2)
EventX
EventYzret()

zret(x)The type of return value from zret() can be altered by adding a frame for each return-value type.
The argument declaration can be omitted by adding frames. In this case, the function-event
argument (j) is passed to the loop function (k).
To avoid wasting the CPU with the loop, RTOS system calls waiting for events can be written as
event-analyzer start activities in j and k so that polling is not used and the CPU can be usedefficiently.

110ÂDepartment

12.5. Device-driver STM
The device-driver STM is declared the same way as the library STM.
Declaration example:š100[3](char* cpdata)
Call example: read(lpara1,para2)
š100:read(lpara1,para2)
The existence of an RTOS mechanism is assumed for the operation of a device-driver STM.
When the RTOS is not installed, the device-driver STM is not used but the interrupt-handler
STM is used instead.

Task

IInterrupt
HandlerŒ‚. ‚' o(TRAP)• j
C Interface

Devic
DeviceD
e river'DriverInterrupt
Handler. ‚'Œ‚(IO)

Figure 12- 8 Positioning of device-driver STM
The device-driver STM has exactly the same description format as the library STM mentioned
earlier. In most cases, however, the operations of the actual device driver and library are
different. Moreover, the operation varies depending on the implemented RTOS type. However,when a device driver is designed using the state-transition matrix, it is no different from creating
a library or task. The device driver is called from the higher-level application by a system call(also called an IO system call or a driver system call). This can be considered a function-callevent or message event. Or, if the system call is an internal interrupt such as a TRAP, there is
no problem in considering it an interrupt event and proceeding with the design.
The notes explained hereinafter are for creating a simulator tool that supports this methodology.
For actual simulations, the philosophy will change depending on which RTOS is simulated. A
library STM is a task from the RTOS's viewpoint. A device-driver STM is controlled by the
RTOS, separate from the task. System calls from a task to a device driver are forwarded to thedevice driver as software interrupts (TRAP). If the call is asynchronous (calling return), thedevice driver returns the control to the task as soon as it receives the command. If it issynchronous (complete return), the called task stays in the IO wait state until the device drivercompletes the processing, and the task does not operate until the device driver completes theprocessing. This is caused not by the STM operation but the RTOS operation. The device111ÂDepartment

driver does not return to the task that has called it. The relationship between them is not thesimple call and return of a program, but the device driver is called from the task via RTOS andthe control is returned. With this method, the RTOS can even give priority to the execution ofanother task. Here, zretset() is tentatively provided to express the intention of returning control
to the RTOS. From the state-transition design viewpoint, there is no problem whether writing
the zretset() function or writing codes that returns to the device driver of the RTOS to be used.
Whether the code is understood or not depends on the specification of the CASE tool that
supports the EHSTM.

Figure 12- 9
UNUSEDINITIALIZEDINITIALIZATIONCOMPLETEREADNORMALCOMPLETIONABNORMALCOMPLETION

Initializing

Initializing

Initializing

Initializing

Initializing
Read

Initialization
complete

Abnormalcompletion
Normal completion

Abnormalcompletionrcv_msg(MB1);...
...
get_tid(p_tskid);
dInfo.tskid = *p_tskid;
s = DevInit(&dInfo));if(s == INIT_OK){s = DevRead(&dInfo);
if(s == READ_OK){
...
}
else{
...
}
}

Figure 12- 10 Driver call112ÂDepartment

The operation upon calling Dev_Init is basically the same as that of the library-call STM. In
other words, it is a synchronized (complete return) type. The synchronized type here meansthat the control is not returned to the caller until processing finishes completely. Not returning
the control to the caller means to make the caller task WAIT, since the device driver STM uses
the RTOS mechanism.
Dev_Init() becomes a TRAP command in C Inter, and is caught by the interrupt handler. Theinterrupt handler that receives this system call (Dev_init) saves the PC and SP of the task at thetime the system call is issued, to the TCB of the task. It then notifies the device driver of therequest from the task.
If the device driver that has received the request as a function-call event is an RTOS, which has
to process the execution control of request tasks, describe the processing in the action or
activity of the device-driver STM.
For iTRON3, the request task is transferred to the forced wait state by isus_tsk(tskid). In orderto resume the task in a forced wait, stateirsm_tsk(tskid) is issued. In the case of the RTOS4 that
does not support isus_tsk(), the event flag is executed using wait_flag(flgid) on the request-taskside, and is set within the device driver using iset_flag(flgid).
The request task needs to obtain the task ID using get_tid(p_tskid) and pass it to the device
driver as an argument.

3 iTRON for NEC-made V850 (RX850) is used as an example.
4 iTRON for NEC-made 78K/IV (RX78k/IV), etc.

113ÂDepartment

Request task

Interrupt handler

Device driver

Dev_Init
TCB_Dev_Init
Returnaddress

isus_tsk

Returnvalue

dispacher
DEV_I:INIT_OK
irsm_tsk

zretset(INIT_OK)

dispacher

Figure 12- 11 Synchronous device driver sequence
In the device-driver STM example, DEV_I is set as an interrupt. This causes the creation ofanother loop that waits for an interrupt in addition to the interrupt handler. The device-driver
STM transfers control to the created loop. The CPU resource, which would be used for the loopthat just waits, can be saved by describing the RTOS synchronized event flag WAI_FLG(EV1) inthe cell. To return the execution privilege to the request task after the device driver hasreceived the specific end interrupt, zretset(ret_value) is called. This command sets the return
value (ret_value) from the device driver to the TCB of the request task and switches the IO waitstate held by the request task back to READY.
Scheduling then sends a request to the RTOS.

114

ÂDepartment

Request task

Device driver

iTRON

Interrupt handler

Dev_Read
TCB_Dev_Read
Returnaddress

zretset(CALL_OK)

dispatcher
dispacher

Returnvalue

Figure 12- 12 Asynchronous device driver sequence
Dev_Read() is an asynchronous (calling return) type. The asynchronous type immediately
returns the control to the caller after receiving the system call, even if processing has not been
completed. Naturally, returning the control means making a request to the RTOS scheduler, sowhether the control is actually returned or not depends on the circumstances of the task
controlled by the RTOS at that time.
In the case of an asynchronous task, it will not know whether the read has been completed untila response has been received. Write it as the following in order to receive the response as amessage:
rcv_msg(MB1);
The device-driver STM is a loop process that waits for an interrupt, since it is independent fromtasks. Interrupt is disabled while the device-driver STM is in operation.

(*)zretset() is not a system call of EHSTM. The system call equivalent of zretset() depends
on the specifications for the CASE tool that supports the EHSTM, because it varies
depending on the RTOS type supported by the tool.

115ÂDepartment

12.6.

Interrupt-handler STM

The interrupt-handler STM is declared as follows:
STM name
Declaration example: Dev_1
Call example: Registered to the interrupt vector table
The interrupt-handler STM is designed so that an interrupt handler exists for each of theinterrupt events and the handler is registered to the interrupt vector table of the CPU. The
EHSTM design method does not cover such issues as the interrupt vector table, which must be
shared because some CPUs have fewer interrupt vector table entries. In some RTOSs, theRTOS interrupt handler catches the interrupt first, then the individual interrupt handler isactivated from the interrupt table provided within the RTOS. However, for its return, amechanism similar to the one for the device-driver STM, such as zretset(), is necessary in the
CASE tool.
In some cases, the STM exists as the interrupt-handler section. In other cases, the interrupt
handler section is dispersed to the task STM or main STM. From the viewpoint of
implementation, there are no problems in describing the interrupt handler (interrupt event) in themain section. If the interrupt handler is written in the task section, it is necessary to adjust it to
the interrupt-handler mechanism of the implemented RTOS. When the interrupt-handler section(interrupt event) is described in the task section, it means "the task is always activated at the
moment an interrupt occurs."
If the interrupt handler is created independently, the task or main section has to be notified of
the occurrence of an interrupt. Normally, the task section uses an independent interrupt-handler
section.

Event AEvent B
Event CInterrupt
AInterrupt
B

Interrupt
AInterrupt
B
Interrupt
C

Event AEvent B
Event CInterrupt
C

Main STM

Interrupt-handler STM

Task STM

Figure 12- 13 Interrupt-handler section&:EHSTM Refer to 17, "EHSTM system call," for more about the EHSTM system call.

116ÂDepartment

12.7. Device-register STM
The device-driver STM is declared the same way as the library STM.
Declaration example: 100[3](char* cpdata)
Call examples: read(lpara1,para2)
100: read(lpara1,para2)
During a system simulation the device-register STM is processed concurrently with the CPU,
since it exists in the external environment.
If the RTOS is implemented, a device-driver STM is usually created, so it is not necessary to
pay attention to the operation of the device itself. However, it is convenient to have the device's
operations described in the form of an STM when the RTOS is not implemented, or fordesigners of device driver STMs or IO library (middleware) STMs.
Usually, communication with peripheral devices is performed via the command/status registers.

CPU

TxINT
RxINT

deviceCOM

device
COM

TxINT
RxINT

CMDREGCMDREGTXDATREG

TXDATREG

RXDATREG

RXDATREG_H

RXDATREG_T

STAREG_H

STAREG_T

HOST

CPU

RXDATREGTERMINAL

Figure 12- 14 An example of communication devices
Let's consider the example in Figure 12-14. There is a device COM, which is forcommunication. The CPU has access to CMDREG, TXDATREG, RXDATREG, andSTAREG_H/T of COM. On the other hand, RXDATAREG_H/T cannot be accessed from theCPU. There must be another end, since it is a communication device. Assuming the other end
also uses the same device, TXSATARREG - RXSATAREG_H/T and STATEREG_H STATEREG_T are connected between devices. The connection here means to create an STM
so that the registers of the other end can be referred to and set from both sides (HOST and
TERMINAL).

117

ÂDepartment

TX
ZEL_500
ComLSI

RX
RUN

STOP
0
4800 0setspeed
ispeed 9600
(int ispeed)119200 2
CMDREG | TXSTART/*activity*/
CMDREG &= TXCLR;CMDREG | TXSTOP/*activity*/
CMDREG &= TXCLR;CMDREG | RXSTART/*activity*/
CMDREG &= RXCLR;CMDREG | RXSTOP/*activity*/
CMDREG &= RXCLR;STAREG_T == ON/*activity*/
STAREG_T = OFF;b192001

2

3=>b9600=>b4800=>b4800=>b19200=>b9600

STOP

RUN

4

5

=>b9600=>b19200=>b19200

zsystim(T_O,
1666);
iflag=OFF;
zsystim(T_O,
0);=>STOPzsystim(T_O,833);
iflag=OFF;
zsystim(T_O,
0);=>STOPzsystim(T_O,416);
iflag=OFF;
zsystim(T_O,
0);=>STOP

5=>RX:RUN

6=>RX:STOP

7RXDATREG =RXDATREG_T;
INT(RxINT);

8/*Tx TimeOut */
T_O

b9600

=>b4800

3 =>TX:RUN(P)
4

b4800

if(iflag==ON){
RXDATREG_H= TXDATREG;
STAREG_H
= ON;
}
else{
iflag = ON;}
INT(TxINT);

if(iflag==ON){
RXDATREG_H= TXDATREG;
STAREG_H
= ON;
}
else{
iflag = ON;}
INT(TxINT);

if(iflag==ON){
RXDATREG_H= TXDATREG;
STAREG_H
= ON;
}
else{
iflag = ON;}
INT(TxINT);

Figure 12- 15 Communication device register STM
According to the states, the transmission and reception (TX/RX) can operate concurrently in theCOM. Unless setspeed() is executed, the transmission is not allowed. Event numbers 3
through 7 sense the CMDREG value as a flag event. If an arbitrary bit of the command register
is on, the arbitrary processing is executed, and the bit is cleared by the event end activity when
it is complete. Once the baud rate is set, it is not changed unless changed by setspeed(). Thisis known from the fact that the type of the transition from state number 1 by event number 3 isthe deep history type. In order for COM to start transmission, it is also known from the matrix(state numbers 1 through 3 of event number 3) that the CPU side has to turn on the TXSTART
bit of the CMDREG to on again and trigger an interrupt (zsystim) for transmission within theCOM. The zsystim interrupt intervals are changed, depending on the baud-rate setting. Whenthe first T_O (event number 8) interrupt occurs, it simply interrupts the CPU with an INT (TxINT),
because the iflag is set to off. The CPU needs to set the transmission data to TXDATREG
before the next interrupt is generated for the COM. The COM sets the EXDATREG value to thereceive register RXDATREG_H of the opposite party (when its own side is the terminal side).
Obviously, this is repeated as long as the transmission data exists. At the end of the118ÂDepartment

transmission, the TXSTOP bit has to be turned on in the CMDREG before the COM's internaltransmission interrupt occurs.
The reception operation runs concurrently with the transmission operation. Reception will be onstandby by turning on the RXSTART bit of CMDREG from the CPU. Then, when STAREG_T(when its own side is the terminal side) is turned ON, RXDATREG_T (when its own side is theterminal side) containing the value set by the opposite party is set in RXDATREG, and thereception interrupt INT (RxINT) is generated in the CPU. You can tell that the CPU side must
read the value in RXDATREG before the next reception from COM occurs.

119ÂDepartment

120

· Clone STM

13. Clone STM
The clone STM generates multiple states from a single STM. “Multiple states” does not mean
multiple concurrent states, but providing multiple sets of states to be controlled by the statescheduler.
The clone STM is declared as an array of the C programming language.
Declaration example:

int 1[3](lp1)
The meaning of the above declaration is, "The return value type is int; there are three clones fornumber 1 of the event driven STM; and receives argument lp1." To be precise, "three clones"
means "one original and two clones." Clones are called by specifying the clone number. The
clone number starts with 0. Clone number 0 is used to call the original. When the clone
number is omitted, 0 is assumed.
Call example:
1[0](&var1)
TELEPHONE

1[2]DISCONNECTE

ON THE PHONED

Message for
Makingphone call
Voice from theother party

Dial
State the message
Hang up

Mute

Busy tone

Hang up
Interested

Turn TV

program
End of program

Turn TV off

Turn TV off

Figure 13- 1 The STM of the telephone and TV
When the STM of the telephone and TV declares the number of clone STMs as two, two sets ofstate-control variables are used.

121

· Clone STM

State-control variable for Clone STM NO:0¢[Telephone]¢[Disconnected]¢[On the phone]¢[TV]¢[OFF]¢[ON]¢[NORMAL]¢[MUTE]
State-control variable foe Clone STM NO:1¢[Telephone]¢[Disconnected]¢[On the phone]¢[TV]¢[OFF]¢[ON]¢[NORMAL]¢[MUTE]£:Dead ¢:Suspended:™Ready:˜Active
The clone STM can be used in all departments. The creation of clone STMs with respect to atask section does not produce multiple tasks. The same thing can be said of the device driverand library sections. Be especially careful with the device driver, since the device drivermechanism of the RTOS may be conducting the unit control. To realize exclusive control forclone STMs, the user must describe the contents in the action or activity. The EHSTM design
method only provides the clone STM mechanism.

The clone STM is convenient when a communication-control protocol task controls channels or
multiple partner stations by a single protocol.
The clone STM cannot use interrupt events.

122¸ STM main

14. STM main
An STM main is created for each main section and each task in the task section. The STM
main calls the event-acquisition function and event-analyzer function. However, there is none in
the library, device driver or interrupt-handler section. In these departments, the eventacquisition and event-analyzer functions are called within the functions generated by thefunction-call type or interrupt-type STM.
The STM main is closely related to the driven type.

14.1. STM main and event-driven typeThe event-driven type has a program structure that waits for events at a single location.
Therefore, the STM main acquires events and calls the event analyzer.
STM mainwhile(1){The eventacquisition function
The event-analyzer} function
The event-acquisition function
Acquire communication andsynchronized events

The event-analyzer function
Detect the event number
Drive the STM

Figure 14- 1 STM main and event-driven type123

¸ STM main

14.2. STM main and state-driven typeThe state-driven type has a structure that retrieves events at multiple locations in the program.
Normally, polling-type events are used for the state-driven type. However, when thecommunication or synchronized type is used by the state-driven STM, events are acquired at asingle location of the STM main by default. It is called “default” here because the tools that
support the EHSTM design method will be likely to have specifications that allow selection fromseveral event-acquisition locations. When polling is set as the event type, the event-acquisition
function does not work. In the state-driven type, the state scheduler is called instead of theevent-analyzer function from the STM main.
STM mainwhile(1){The event-acquisition
function
State scheduler}

The event-acquisition
function
Acquire communication andsynchronized events
State scheduler
An active event-analyzer function

The event-analyzer
function
Detect the event number
Drive the STM

Figure 14- 2 STM main and state-driven type124

¹ Hierarchy

15. Hierarchy
The hierarchy describes the overview in the higher level and in more detail as the level
becomes lower. Using the hierarchy a huge, complicated state transition can be represented in
a compact, easy-to-understand structure. Normally, when the state transition is represented
graphically -- in other words, in the case of the State Transition Diagram (STD) -- the hierarchy
is implemented with respect to states. Harel’s STD is the example. When the state transition isrepresented as a table -- in other words, in the case of the State Transition Matrix (STM) -- thehierarchy is implemented with respect to events. The EHSTM design method version 1 uses
this method.
In the EHSTM design method version 2, the state hierarchy is included in the STM in addition to
the event hierarchy.

&: Refer to 11, "Driven type," for the STM driven type.
15.1. Event hierarchy
In the event hierarchy, an overview event is captured in the higher-level STM, the higher-level
STM notifies the lower-level STM of the event, and the lower-level STM captures it as a detailed
event. Overview-detail relationships are constructed with respect to events, allowing theconstruction of a complicated large-scale system using compact, easy-to-understand STMs.
Let's take a look at an example of hierarchy for the telephone STM. We assume it is an eventdriven STM.
Sound information
Disconnected On the phone

Message formaking a phone
call

Sound
information

On the phone

Dial
Voice fromthe other
party

State themessage
Hang upBusy tone

Hung up

Figure 15- 1 Event hierarchy(1)The “sound information” event and the “voice from the other party” and “busy tone” events havea hierarchical relationship.
“Sound information”“Voice from the other party”“Busy tone”

Figure 15- 2 Event tree
This event tree structure can also be represented using the event virtual frame without using thehierarchy, and the user can choose the format to be used. Description in a single STM has thebenefit of being able to confirm all combinations. The hierarchical structure has the benefits ofreducing the number of “no use” and “invalid” cells, improving the ease of viewing and editing,and reducing the memory required when the STM is programmed in a table. (Usually, the total
number of cells is reduced with the use of hierarchy, even though it is still six after implementing
a hierarchy in the above example.)125

¹ Hierarchy

Disconnected

On the phone

Message for making a
Dialphone call
Voice from theSoundother party

information
Busy tone

State themessage
Hang upHung up

Figure 15- 3 Event virtual frame
Let's take a look at another example of event hierarchy.
This is an STM that controls two drives (A and B).

0.1

Ready
1
Read

1

Write

2

Seek

3

GetID

4

RetrunToZero 5
FormatFigure 15- 4 Event hierarchy(2)1266¹ Hierarchy

The parent STM(0) receives the "host request" by the event virtual frame, and "A:" and "B:" aretreated as events. When the parent STM (0) is in the "free" state, the child STM (0.1) is calledby inheriting the event received by the parent. The child STM classifies the event received by
the parent STM into six detailed events.
The event hierarchy is represented using the STD, as follows:

A
free

B

host request A/
£0.1

busy

free

device return A/
host_req

host request B/
£0.1

busy

device return B/
host_req

Figure 15- 5 Event hierarchy STD
The child STM in this case can also be written as a subroutine STM.

15.1.1. Call and return of event hierarchy
In the event hierarchy, the higher-level STM always receives events and passes these eventson to the lower-level STM. The lower-level STM cannot receive events independently. If theparent cannot know all events of the child STM, it uses an "else" event.

0

0.1

0.2

0.1.1
Figure 15- 6 Event hierarchy tree
The call of another event hierarchy is executed in the action cell. Therefore, an event-hierarchy
STM can be called by passing arguments in the same way as a function call, and the called
event-hierarchy STM can return with a value.

127

¹ Hierarchy£1

State Aif(£1.1(lpara)){// normal processing=> normal state

Event A }else{//abnormal processing=>abnormal state}State AEvent A-1

Event A-2

Figure 15- 7 Call and return of vent hierarchy"Event A" is inherited from £1 to £1.1 as "Event A-1" and "Event A-2," and "lpara" is handed
over when 1.1 is called. A "return" statement is executed when returning from £1.1 to £1.
The return statement described in the STM declaration section is executed when no event hit
has occurred.
The lower event number is determined by the higher-level STM, and the lower-level STM canbe driven by the event number specified in the higher-level STM without executing the event
analyzer of the lower level.

128

¹ Hierarchy1if( 1.1:2(lpara)){//normal processing=>normal state

Event A}else{//abnormal processing=>abnormal state}State AEvent A-1

Event A-2

Figure 15- 8 Event number specification call
The child event (£1.1) will be event number 2 ("Event A-2”), which is specified by the parent.
Event A is passed onto the grandchild £1.1.1).

&: Refer to 4.4.10, "Event virtual frame," for the event virtual frame.
Refer to 16, "Subroutine STM," for the subroutine STM.
Refer to 4.4.9, "ELSE event," for the else event.
Refer to 9, "Event analyzer," for the event analyzer.

129

¹ Hierarchy

15.2. State hierarchy
In the state hierarchy an overview state is captured in the higher-level STM, while detailed
states are captured in the lower-level STM. Overview-detail relationships are constructed withrespect to states, which allows the construction of a complicated large-scale system using
compact, easy-to-understand STMs.
Let's take a look at a hierarchical STM for the telephone example. We assume it is an eventdriven STM.
Telephone

Disconnected

Message formaking a phonecall

On the phone

Voice fromthe other

Mute

party
Dial

Busy tone

State themessage
Hang up

Voice from theInterested
programTurn TV on

End ofHung upother party

programTurn TV off

Turn TV off

Figure 15- 9 State hierarchy transition matrix (1)1.2 in Figure 15-9 can set in a hierarchy with a deeper level.

Interested
program
End ofprogramTurn TV on

Turn TV off

Figure 15- 10 State hierarchy transition matrix (2)Compared with the 5x5=25 cells in the STM shown in Section 5.2 before implementing thehierarchy (Figure 15-10), the number of cells has been reduced to 2x0+2x3+3x3=15 in thestate-hierarchy STM(1) and to 2x0+2x3+2x2+1x2=12 in the state-hierarchy STM(2). The
decision whether or not to use state hierarchy is determined in the same manner as the event
hierarchy. The state tree will be as below:[Telephone][Disconnected][On the phone]
[TV]
[OFF]
[ON]
[NORMAL][MUTE]

Figure 15- 11 State tree130

¹ Hierarchy

The following are the STDs for the STMs in Figures 15-9 and 15-10.
Busy tone/Hung up
Telephone
Voice from the other party/State the message, Hung up

Disconnected

On the phone

Message for making a phone call/Dial

End of program/Turn TV off

TV
End of program/Turn TV off

Interested program/Turn TV on

OFF

/Mute

ON
Voice from the other party
NORMAL
MUTE

Figure 15- 12 State hierarchy STD (1)The state hierarchy for those STMs is expressed the same way by the STD. In the STD for TV
activity in Figure 15-12, when the transition from "ON" to "OFF" is written as shown in Figure 1513, the STM uses the state actual frame as shown in Figure 15-14.

131

¹ HierarchyTV
End of program/Turn TV off

ON
Voice from the other party

Interested program/Turn TV on

OFF

MUTE

NORMAL/Mute

Figure 15- 13 State hierarchy STD (2)Voice from theother party
Interested
program
End ofprogram

Mute
Turn TV on
Turn TV off

Figure 15- 14 State actual frame (3)&: Refer to 5.3.6, "State actual frame," for the state actual frame.

132

¹ Hierarchy

15.2.1. Call and return of state hierarchy
The call of a state-hierarchy STM is different from the call of an event-hierarchy STM. The statehierarchy STM does not make a call at the interval at which an event occurs. A call is executed
when a transition occurs and the state becomes active. Whether the called state-hierarchy STM
inherits the event from the parent or acquires a new event by itself depends on the STM driven
type. While the event-hierarchy STM is called and returns as if it was a function, there are noarguments or return values for the state-hierarchy STM because it is called as part of an active
state.

Figure 15- 15 Call and return of state hierarchy
Telephone

Disconnected On the phone

Message formaking aphone call

Dial

Interested
program

Voice from theother party

Busy tone

State themessage
Hang upTurn TV on

End ofTurn TV off

programHung up

Voice from the other
party

Mute

Figure 15- 16 State hierarchy STM (3)Let's trace the actions in Figure 15-16. Assume the STM is a state-driven type. It is easier tounderstand if the state tree is used as a reference.
The first ready states are "Telephone" and "TV." "Disconnected" and "OFF," which are theirrespective child states, are in the READY state.

133

¹ Hierarchy™[Telephone]™[Disconnected][On the phone]™[OFF][ON][NORMAL][MUTE]™[TV]™Ready:˜Active

Figure 15- 17 State hierarchy scheduling (1)Only one of the ready states becomes active. The active state is switched via a dispatch. Two
specifications are available for scheduling of the dispatch:(1) Vertical scheduling (V-type)(2) Horizontal scheduling (H-type)
In concurrent states, two specifications are available for determining the priority:(1) Default scheduling (D-type)(2) Dispatch scheduling (P-type)
These scheduling types will be explained in the "STM driven type” section.

™ [Telephone]™ [TV]

˜ [Disconnected][On the phone]™ [OFF][ON][NORMAL][MUTE]™Ready: ˜Active

Figure 15- 18 State hierarchy scheduling (2)Being active means that the event is accepted. Assume an "interested program" event occurs
when the "Disconnected" state is active. This event is not known until the "OFF" state becomes
active. This is characteristic of the state-driven type. If it is event-driven, the root STM is firstinitiated at the moment the event occurs, then each STM is called. In the state-driven type,whether or not the event has occurred is not known until the state becomes active because theactive state looks for the occurrence of an event. Therefore, using the synchronized orcommunication-event type in the state-driven type will cause problems. This ia explained in the“STM driven type” section.

™ [Telephone]™ [TV]™ [Disconnected][On the phone]˜ [OFF][ON][NORMAL][MUTE]™Ready: ˜Active

Figure 15- 19 State hierarchy scheduling (3)134¹ Hierarchy

When "OFF" becomes active and the "Interested program" event is captured, a transition to"ON(D)" occurs.

™[Telephone]™[TV]™ [Disconnected][On the phone]
[OFF]
[ON]

™ [NORMAL][MUTE]™Ready: ˜Active

Figure 15- 20 State hierarchy scheduling (4)Assume a "Message for making a phone call" event occurs when the "ON" state is active. The
occurrence of this event will not be known until the "Telephone" state becomes active.
™ [Telephone][Disconnected]™ [On the phone]™ [TV][OFF]™ [ON]

˜ [NORMAL][MUTE]™Ready:˜Active

Figure 15- 21 State hierarchy scheduling (5)Assume a "Voice from the other party" event occurs in the above state. This "Voice from the otherparty" event is described so that it is processed in the "Telephone" and "TV" concurrent states.
Since they are designed as concurrent on the STM, they can be processed at the same time.
Unless an RTOS supporting multiple CPUs is installed, however, in reality one of them isprocessed first. Which state should be processed first cannot be specified, but it is determined
depending on the dispatch situation. To specify that one of them always has processing priority,
the state hierarchy should not be used as in Figure 17 of Section 5.2, but the event-driven STM
should be used. By using the default scheduling for concurrent states, the "Voice from the otherparty" event always accepts the "Telephone" state first in Table 17. Then the "State the message,hang up" action is executed and the "Voice from the other party" is accepted in the "TV" state.
This is essentially the opposite of normal actions. In fact, a default mark (@) should be attachedto the "TV" state because "Mute" should be executed first. The order of event acceptance issusceptible to change, due to the state scheduler. Even if a default mark is attached, this is only
for specifying the order of scheduling but not for specifying the order of events to be processed.
Therefore, nothing can be done further if a "Voice from the other party" event is detected while the"Busy" state is active. The driven type should be the event-driven type if the orders of events areimportant. Refer to Section 14.10 for more about this issue.
The "Voice from the other party" event is usually defined so that its occurrence made known by
the change of a variable. Moreover, the lifespan of the "Voice from the other party" event is one of
the most important items to design.

135

¹ Hierarchy

No voice from the other party
Voice from the other party
Figure 15- 22 Lifespan of an event
The occurrence of an event is captured by the event analyzer. The events are also cleared by theevent analyzer. At this time, in the case of a concurrent state of the state-driven type, the events
cannot be cleared by the analyzer independently because other states might also need it. In thiscase, processing such as a synchronized counter will be necessary for the event analyzer.

&: Refer to 11, "Driven type," for more about the STM-driven type. Refer to 8.3, "Dispatch
activity," for more about dispatch activity. Refer to 9, "Event analyzer," for more about the event
analyzer.

136

¹ Hierarchy

15.3. Hierarchy and event
Events are inherited for communication events, synchronized events and in-mail events.
Inheritance means that the child STM analyzes events acquired by the parent. In other words,
the event inheritance deals with the location in which the event is acquired; namely, whether it isinherited or new events are handled. Normally, if the event-acquisition function is called from asingle location of the STM main, the events acquired there will be inherited by the children of
the event hierarchy. If the event acquisition is called from the state scheduler, events are notinherited and newly acquired ones are always used.

Event acquisition

State scheduler

State scheduler

Event analyzer

Event acquisition
Event analyzer

Event analyzer
E

Event analyzer
vent analyzer

Figure 15- 23 Event inheritance137

¹ Hierarchy

15.4. Hierarchy and state
There are two types of states: the exclusive type and concurrent type. The relationship of thehierarchy with regard to state type is the same as that of the parent-and-child relationship of thestate frame.

ON

ON

VISUAL

OFF

iSW

SW

NAVI

SW

TV

OFF

OFF

AUDIO
SW/
iSW

SW

NAVI

SW

TV

SW

CD

SW

RADIO

TAPE

Figure 15- 24 Car audio STD
Assume a State Transition Diagram (STD) as shown in Figure 15-24. The state frame STM
for this diagram will be as shown in Figure 15-25:

Figure 15- 25 State frame STM for a car audio system138

¹ Hierarchy

The state-hierarchy STM without a state frame is shown in Figure 15-26.

Figure 15- 26 State-hierarchy STM for a car audio system&: Refer to 5.3.2, "State frame," for more about the state frame.
15.5. Hierarchy and action
A call for a state-hierarchy STM cannot be written in the action. Event-hierarchy STMs include
the ones with hierarchical events and those with hierarchical actions. With hierarchical events,
the event type of the child STM in the hierarchy is the same as the parent that initiated the call.
With hierarchical actions, the timing of the call is after the parent receives the event, but theevent types could be different. The child could be a flag type while the parent is a message
type.

139

¹ Hierarchy

15.6. Hierarchy and transition
There are three types of transitions: the default type, history type and deep-history type. A local
transition is a transition within its own STM. A global transition is a transition to an STM ofanother hierarchy within the same department. Transitions can be made to both the event
hierarchy and state hierarchy in the same manner. No transition is allowed beyond thedepartment. For example, a transition to the state in the library STM is not allowed from thetask STM.
When a hierarchy is used, the transition symbol “-“ indicates that priority is given to the transition
within the child STM that has been called.
£1
E1

1

S1
1
1
£1.1

E2

2

£1.1

S2
2

£1.1

SA

1
EA 1 1>2/-

Figure 15- 27 Hierarchy and transition
When £1.1 is called by E1, the £1.1 has 1>2, causing a transition to 2 of the parent state £1.
When it returns to the parent, the parent makes a transition to state 1 because 1 is explicitly
specified.
When £1.1 is called by E1, the £1.1 has 1>2, causing a transition to 2 of the parent state £1.
When it returns to the parent, the parent stays in state 2 because "-" is specified.

15.7. Hierarchy and activity
There are four types of activities: the event activity, state activity, dispatch activity and trigger
activity. The event activity and state activity function in the same way for both the event
hierarchy and state hierarchy. The dispatch activity and trigger activity function only for the rootlevel. They do not exist in hierarchical STMs.

140

¹ Hierarchy

15.8. Hierarchy and event analyzer
Event analyzers are created for the number of hierarchical STMs in the case of event-driven
STMs. For state-driven STMs, an event analyzer is provided for each state.
There are two processes in the event analyzer: event retrieval and analysis of the retrieved
event. By default, the child uses the event retrieved by the parent for the communication type,synchronized type and in-mail type, as described in Section 14.3. If there are any problems
because of this, they are solved by including the event retrieval process in the event analyzer.
In this case, the event inheritance will not be the same as the table shown in Section 14.3.
15.9. Hierarchy and state scheduler
The state scheduler determines the schedule for the parent-and-child relationship amongstates. Since the event hierarchy and state hierarchy can coexist, the state scheduler functions
in either type of hierarchy.
15.10. Hierarchy and driven typeThe driven type is specified for the highest-level STM. The driven type cannot be specified foreach hierarchical STM. The event-driven type has a structure that waits for events at a single
location in the highest-level (root) STM, even if there are multiple hierarchical STMs. The statedriven type has a structure in which an event analyzer is provided for each hierarchy state, andthe active event analyzer is executed by the state scheduler. When the event-hierarchy STM iscalled in the state-driven type, the called event-hierarchy STM is driven as the event-driven
type. This is because the event-hierarchy STM is described in the action and behaves like afunction. Conversely, when the parent calls a state-hierarchy STM in the event-driven type, thecalled state-hierarchy STM is the event-driven type. This is because the state hierarchy is ahierarchical state tree, and the crossed section of an event and one of the multiple ready states
is simply called. There is no event analyzer for each state.
Let's discuss the state-driven type using the phone call example in Figure 15-1.

141

¹ Hierarchy

Disconnected On the phone

Message formaking a phonecall

On the phone
Dial

Sound
information

Voice fromthe other
party

State themessage
Hang upBusy tone

Hung up

Figure 15- 28 State-driven telephone
Because the state is exclusive, the "Disconnected" state has been activated by the statescheduler at the beginning. Because it is a state-driven type, the event analyzer prepared foreach state is called. In this example, the event analyzer is monitoring the occurrence of a
"Message for making a phone call." When a "Message for making a phone call" occurs, "Dial"is executed and a transition to "Busy" occurs. The "Busy" state now becomes active and the"Sound information" event is monitored. When a "Sound information" event occurs, the child
STM " 1.1" is called by inheriting the "Sound information" event. The called event-hierarchy
STM of 1.1 is an event-driven type.
Next, let’s look at the example of the telephone and TV represented by the event-hierarchy STM
and state-hierarchy STM, to discuss the event-driven type.

Telephone

Disconnected On the phone

Message formaking a phone
callInterested

Dial

programSound
information

On the phone

Turn TV on

End ofprogram

Voice fromthe other
party

State themessage
Hang upBusy tone

Hung upTurn TV off

Voice from the otherparty

Figure 15- 29 Event-driven telephone and TV

142

Mute

¹ Hierarchy

In this example there are no events in the root STM. Even though the event-driven type seems
to do nothing because it waits for events at the root, the event analyzers provided for eachstate-hierarchy STM are activated because of the state hierarchy. The event analyzer to be
activated here requires that the parent calling be in the ready state. The event analyzer is notprovided for each state. Assume that the state scheduler is managing the state as follows:™[Telephone]™[TV][Disconnected]™[On the phone][On the phone]
[OFF]
™[ON]
™[NORMAL][MUTE]™Ready:˜Active

Figure 15- 30 State tree
The states of the event-hierarchy STM are not included in the tree by the state scheduler, but
are managed as states of the STM itself. The states of the event-driven type become active
only when the events are analyzed. The order of calling event analyzers follows the
specifications for the parent schedule, concurrent schedule and tree schedule by the statescheduler. The states of the event-hierarchy STM are handled as states of the STM itself, andare processed in the order of action execution in which the event-hierarchy STM call is
described.
Because it is event-driven, it waits for events at a single location of £1. Suppose that "Sound
information - Voice from the other party" event occurs. Naturally, nothing happens because
there is no event analyzer for £1. Next, the event analyzer of the state-hierarchy STM ¢1.1 ofthe "Telephone," which is a ready state, is called (assuming the concurrent schedule is thedefault type). The "Sound information" is analyzed as event number 1. The action where the"Busy" event and the active state "Sound information" cross is called. £1.1.1 is called byinheriting the "Sound information - Voice from the other party" event. The "State the message Hang up" action is executed, and "Disconnected" is changed to ready. The event analyzer ofthe state-hierarchy STM¢1.2 of the "TV" state is called and "Sound information - Voice from theother party" is analyzed, but there is no hit. The event analyzer of the state-hierarchy
STM¢1.2.1 of "On," which is a ready state, hits "Sound information - Voice from the other party"
as "Voice from the other party." The "Mute" action, located at the cross section of "NORMAL"
and "Voice from the other party," is executed, and a state transition occurs to "MUTE." Now thecontrol returns to the parent and waits for the next event. The difference from the state-driven
type is that the event-driven type can specify the processing priority of events. Refer to Chapter
14.2.1.
In the event-driven type, an event hierarchy is called when the action is executed.
In the event-driven type, a state hierarchy is called when the parent's state is ready.
In the state-driven type, an event hierarchy is called when the action is executed.

143

¹ Hierarchy

In the state-driven type, a state hierarchy is called when the state is ready.

15.11. Hierarchy and department
The task section, main section, library section, device-driver section and device-register section
can be represented by hierarchies. Subroutines, which are covered in Chapter 16, can also be
represented by hierarchies.

Task section
First division

Task section
Seconddivision

In-mail andglobaltransitions
occur only
within the samedepartment.

Interface of arguments and return
values only

Driver section

Library section

Subroutine

Figure 15- 31 Departments
The task STM and main STM are represented by £ or ¢.
The library, device driver and device register sections are represented by šor ˜.
The subroutine section is represented by r or p.
The £, šand rat the root level indicate that it is event-driven and that the child level is an
event hierarchy. However, they indicate that the subroutine section is an event hierarchy evenat the root level. The subroutine takes over the driven type of the caller.
The ¢, ˜ and p at the root level indicate that it is state-driven and that the child level is a statehierarchy. However, they indicate that the subroutine section is a state hierarchy even at theroot level. The subroutine takes over the driven type of the caller.

144

¹ Hierarchy

15.12. Hierarchy and clone STM
Both the event hierarchy and state hierarchy can be represented by a clone STM.

Figure 15- 32 Hierarchical clone STM
A multiple of the same state hierarchy cannot be called, since a state hierarchy is part of thestate tree and scheduled by the state scheduler.

15.13. Format of hierarchy
The event hierarchy is represented by £ and state hierarchy by ¢. A call of an event hierarchy
is described in the action cell and that of a state hierarchy in the state area. Multiple events canbe called. The calling of multiple state hierarchies is not allowed.
The hierarchy level number is represented as follows:parent number. child number
The parent number starts with 0. The child number starts with 1. The level numbers for the
event hierarchy and state hierarchy cannot be the same. The child numbers need notnecessarily be sequential, as long as they are unique.
&: Refer to 12, "Department," for the format of declaration and call of the hierarchy.

145

¹ Hierarchy146

ºSubroutine STM

16. Subroutine STM
The subroutine STM is similar to the hierarchical STM. Each department (task section, main
section, library section and device-driver section) can use subroutine STMs. The subroutine
STM can be changed to a clone STM, and also to a hierarchy.
The hierarchical STM and subroutine STM are different in the following ways:(1) While the hierarchy STM can only make a call through the hierarchy tree, subroutine STM
can be called from anywhere. The state subroutine STM can be called from only one
location, the same as the state hierarchy.
(2) The state control variable can be prepared by the caller side and passed to the subroutine
STM as an argument. The subroutine STM for which the state-control variable is preparedby the caller side is called an external subroutine. On the other hand, the subroutine STM
for which the state-control variable is prepared internally is called an internal subroutine.

16.1. Call and return of subroutine STM

p10

£1

p10

£1.1 r20

r20

r10.1

r10.1

£1.1

p20.1

p20.1

r20

Figure 16- 1 Subroutine STM
The hierarchy STM can be called only by the parent-and-child relationship. On the other hand,subroutine STMs can be called from any location. However, like the hierarchy STM, the call isallowed from only one location when the state is a subroutine STM. In Figure 16-1, p10 can becalled from only one location, while r20 can be called from multiple locations. The inheritanceof events is the same as the table in Figure 15-24, in Chapter 15.3. Hierarchical subroutine
STMs can only be called from the parent STM.

147

ºSubroutine STM

16.2. Internal subroutine STM
With the internal subroutine STM, the state scheduler can be used because the state-control
variable is prepared internally. Therefore, all driven types, state types and hierarchies can be
used.
16.3. External subroutine STM
With the external subroutine STM, the state scheduler cannot be used because the state-control
variable is prepared externally. Accordingly, the state hierarchy is not allowed for the exclusivestate STM, which does not use the state scheduler. The event-driven type is used as the driven
type.
Declaration example: int r100[2](char*cpstate, int*ipstate)
Call example: r100[1](p1, externalstate)
The state-control variable is defined both on the caller and receiver sides, and is passed as anargument.

16.4. Subroutine STM and multitask
Multiple tasks can call the same subroutine STM. The exclusive control for the functions calledfrom the subroutine STM and accessed variables is executed via the user processing in thesame way as is done by the library STM.

148

»EHSTM system call

17. EHSTM system callNo.

1

System callinmail(stm_name,inmail)inmail(stm_level_no,inmail)2

zkill(state_name)zkill(state_no)3

zalive(state_name,mode)
zalive(state_no,mode)

4

zset(stm_name,state_name)zset(stm_level_no,state_no)5zseth(stm_name,state_name)zseth(stm_level_no,state_no)6boolzcheck(stm_name,state_name)zcheck(stm_level_no,state_no)7

zret(p)8

event(task_name,event)

9
10
11

zdi()
zei()
zdil(level)

12

zeil(level)

Meaning
Issues in mail.
stm_name: STM name of in-mail destination
stm_level_no: STM level number of in-maildestination
inmail: Name of issued in mailState transition of concurrent state to DEAD
state_name: State namestate_no: State number
State transition of concurrent state to READY
state_name: State namestate_no: State number
mode: Mode specification when READY
D: default/H: history/P: deep history(*) When the mode is omitted, the P specification isassumed.
Transition to the specified state (with activity)
stm_name: Name of the desired STM for statetransition
stm_level_no: Level number of the desired STM forstate transition
state_name: Name of the state
state_no: State number
Sets history to the specified state (without activity)
stm_name: Name of the desired STM for setting
history
stm_level_no: Level number of the desired STM for
setting history
state_name: State namestate_no: State number
Checks if the specified state is READY.
stm_name: Name of the desired STM for setting
history
stm_level_no: Level number of the desired STM for
setting history
state_name: State namestate_no: State number
RETURN:TRUE(READY):FALSE(not READY)
Returns from the library or interrupt-handler STM.
p: Return value(*)p can be omitted.
Issues an event.
task_name: Name of the destination task of issued
event
event: Name of issued event
Disables interrupt.
Enables interrupt.
Disables level interrupt.
level: Disables interrupts equal to or lower than thespecified level.
Level 0 is the highest and level 255 is the lowest.
Enables level interrupt.

149»EHSTM system call

13

ztrap(vector_no)level: Allows interrupts equal to or lower than thespecified level.
Level 0 is the highest and level 255 is thelowest.
Generates a vector interrupt.
vector_no: Generates the specified vector interrupt.
Figure 17- 1 List of EHSTM system calls

The EHSTM system calls from number 8 to 13 depend on the system implemented. Therefore,
the original system calls can also be used. In this case, the CASE tool used to support the
EHSTM design method needs to be compatible with the system call.

17.1. inmail
The inmail sets internal messages in the in-mail buffer. By default, one in-mail buffer isprepared for each department (in the root STM of the department, if the hierarchy is used).
Also, subroutine STMs are prepared outside the departments. An in-mail buffer could be
provided for each hierarchy STM, if it is not using the default. It is up to the specification of the
CASE tool that supports the EHSTM design method.
In-mail buffer£1

inmail( 1.1, in mail_A)
In-mail A

In-mail A

Figure 17- 2 inmail
The naming rule for in mails issued by “in mail” is the same as that for events. Refer to Section
17.6, "event."150

»EHSTM system call

17.2. zkill/zalive
Telephone
Telephone

Disconnected

On the phone

Statusinformation
Message formaking a phone
call

Dial

Voice fromthe other
party

State the message
Hang upBusy tone

Hang up

Interested
programTurn TV on

End ofprogramTurn TV off

FaultyTelephone

Mute

Turn TV off(Telephone)

Recover(Telephone)

FaultyRecover

Figure 17- 3 zkill/zalive
The concurrent state specified by "zkill" (exclusive states cannot be specified) enters the DEAD
state, which will not be scheduled by the state scheduler. The concurrent state specified by"zalive" enters the SUSPEND state, which can be scheduled by the state scheduler.

151»EHSTM system call17.3. zset/zseth/zcheck

HEAD

PLAY

STOP)

PLAY

RECORD

RECORD:OFF

PLAY::PLAY:
RECORD:ON

IN OPERATION
STOP

PAUSE
NORMALFAST
FORWARD

REWIND

STOP

STOP

STOP

NORMALNORMALFAST
FORWARDFASTFORWARD

REWIND

REWIND

REWIND

PAUSE

PAUSE

In operation (P)NORMALFAST
FORWARDPAUSE

NORMAL

Figure 17- 4 zset/zseth/zcheck£ "zset(£1,ON)" is identical to "=>ON." When a transition type such as "=>ON(D)" isspecified, it is specified in parentheses () after the transition destination name, such as"zset(£1,ON(D))." See actions of "NO_TAPE" (state number: 2) and "IN TAPE" (event number:2). The "=>TAPE(D)" means a transition to "TAPE" using the default type. In this case, thechild state of "TAPE" also makes a transition using the default type. In other words, "STOP"
becomes ready in £1.2. How about the states in £1.1? Since £1.1 is an event hierarchy, it is
not included in the state tree. Therefore, "=>TAPE(D)" has no effect on £1.1. "zseth(£1.1,
PLAY: OFF)" changes the history of £1.1 to "PLAY: OFF." The difference between "zset" and"zseth" is that "zseth" modifies only the past state, or history, while the transition actually occurs
by "zset" (the same as =>). This changes the READY position of the states when a history or
deep-history transition occurs. The "zcheck" checks whether the specified state is currently

152

MOTOR

»EHSTM system call

READY or not. TRUE is returned if it is ready, otherwise FALSE is returned.

17.4. zret
"zret" returns the control to the called source from the library STM or interrupt handler. But whyis this return different from that of the task and main sections? The library STM is called fromthe call source by the function-call type. With the function-call type, the function described in an
event is generated and the STM is called by the function. The "return" described in the library
STM returns to this function. The called library STM might not return to the call source but wait
for an event and process it by itself. To return to the call source, "zret" is used.

FuncA(lp1);

FuncA(int* lp){
event_no = 0;
int ret = act(event_no);while (until zret is executed){
Obtain event ();Event analyzer ();}return (value of zret)}

01

FuncA(int *lp)0=>1zret(0)

EventA
11/=>0zret(1)Figure 17- 5 zretIn the example above, the library STM called by FuncA does not return to the call source unless
EventA occurs. When FuncA is called from multiple sources, the FuncA should be designed soit has a reentrant structure.
The following describes the general concept of device drivers and interrupt handlers. Please
note that this is a general concept, and a philosophy separate from this is required forsupporting individual RTOS.
Device drivers operate under the environment where an RTOS is installed. A device driver iscalled by the caller in the form of a device-driver call. When the called device driver returns tothe caller, it returns to the RTOS scheduler. It never returns to the caller task. This is thedifference from the concept of "zret" in the library STM. In the device driver, an event may haveoccurred to the task which has higher priority than that of the caller task. The same applies tothe interrupt handler: "zret" is used if the return from the interrupt handler is simply to return theinterrupted task.

153

»EHSTM system call

DrvA(p1);

0
DrvA(int* ip){
event_no = 0;
int ret = act(event_no);while (until zret is executed){
Obtain event ();Event analyzer ();}Set the return value of zret in ret.
return(ret)1

DrvA(int *lp)

0 =>1 zret(0)EventA1/=>0zret(1)}Figure 17- 6 zretset
In the above example, the device-driver STM called by DrvA does not return to the caller unless
EventA occurs. Also, the operation is the same as that of the library. The mechanism of putting
the request task into the IO wait state when the driver call occurs is defined by the specificationof the tool, and is not specified in this document.

154

»EHSTM system call

17.5. event
This generates message events. Each event has a variable type (mail type, synchronized typeor flag type), interrupt type, in-mail type and function-call type. The EHSTM supplies "ztrap" forgenerating the interrupt type. Other interrupts depend on the specification of each tool that
supports the EHSTM design method. The in-mail type is generated by “inmail.” The functioncall type is generated by calling a function. For the flag-variable type, writing to a variablegenerates an event. The synchronized event (event flag) is substituted by the mail-type event(message).
Task 1 message queue
Task 1 STM£1Event A

Task 2 message queue

Event Aevent(task 2,Z:A:X:B:Y:)

Task 2 STM£2

Z:A:X:B:Y:

X

V

2.1

Y

2.1

Z

Figure 17- 7 event
An event tree (when a frame or hierarchy is used) is represented by a colon(:). The character
string is inherited into the event hierarchy or event frame. The event hierarchy and event frame
analyzes the string to see whether its own event exists.

155»EHSTM system call17.6. zdi/zei/zdil/zeil
The disabling and enabling of interrupts is represented by "zdi()" and "zei()," respectively.
The level interrupt can be controlled in the form of "zdil(level)" or "zeil(level).""zdil(3)" prohibits interrupts of level 3 and below.
"zeil(3)" allows interrupts of level 3 and below.
Level number 0 is the highest interrupt level and 255 is the lowest level.
Operations of NMI (Non-Maskable Interrupt) and the level interrupt vary, depending on theCPU. Therefore, detailed specifications for zdi, zei, zdil and zeil follow the specification of the
CASE tool that supports the EHSTM design method. In this case, the handling of the level
number described above also changes.
17.8. ztrap"ztrap(vector number)" generates vector interrupts.
The vector number ranges from 0 to 255.
The value of a vector number, as well as the combination of a vector number and a level
number, vary according to the specification of the CASE tool that supports the EHSTM design
method.

156

IndexA
action 43
actions and activities
order of 75
action cell
format of 43
activity 67
format of, 77
analysis sequence number 33
Ccomputer language statement 44
clone STM 121
concurrent brother state
no transition to, 58
concurrent schedule 89
concurrent state 35
concurrent state 37
no transition to, 57
Ddeep memorized transition 54
default state 40
default transition 51
department 101
department under RTOS 103
department under non RTOS 102
device register STM 117
device-driver STM 111
dispatch activity 73
divided action cell 48
don't care 49
driven type 95
driven type and action 98
driven type and activity 98
driven type and event 97
driven type and event analyzer 99
driven type and state 98
driven type and transition 98

event driven type 95
event frame 19
event hierarchy 125
call and return of, 127
event hierarchy STM call 45
event type 9
event virtual frame 25
event-analyzer end activity 31,69
event-analyzer start activity 31,69
event-hit end activity 31,70
event-hit start activity 31,70
exclusive state 35, 37
external subroutine 148
Fflag event 15, 20
flag variable access method 80
forced transition 63
function-call event 13, 23
function-call event analyzer 85
Hhierarchy and action 139
hierarchy and activity 140
human language statement 44
hierarchy 125
format of, 145
hierarchy and clone STM 145
hierarchy and department 144
hierarchy and driven type 141
hierarchy and event 137
hierarchy and event analyzer 141
hierarchy and state 138
hierarchy and state scheduler 141
hierarchy and transition 140
I
if condition 27
in-mail 150
in-mail analyzer 83
in-mail event 12
in-mail event 20
internal subroutine 148
interrupt event 10, 22
interrupt event analyzer 84
Invalid 44
interrupt handler STM 116

E
EHSTM
format of, 5system call 49,149
else event 24
event 155
event 19
event 9L
event activity 67
event actual frame 26
library STM 105
event analyzer 79
library STM call 47
event analyzer and variable access method 80
Mevent cell
format of, 19
main/task STM 104

Indexmail variable access method 80
memorized transition 52
message event 14
mixed events 16
N
NS chart 44
no use 45
no action default/else 32
P
parent-and-child schedule 88
Sstate 35, 37
state activity 71
state actual frame 39
state cell
format of, 37
state end activity 40,72
state frame 37
state hierarchy 130
call and return of, 133
state hierarchy STM call 41
state mode activity 40,72
state scheduler 87
state scheduler
format of, 94
state scheduler and activity 92
state scheduler and interrupt event 94
state scheduler and transition 92
state start activity 40,71
state virtual frame 38
state-driven type 96
STM
format of, 3
STM main 123
STM main activity 75
STM main and event driven type 123
STM main and state driven type 124
subroutine STM 147
call and return of 147
subroutine STM and multitask 148
subroutine STM call 47
switch condition 29
synchronized number 59
synchronized state 42
synchronized state and synchronizedtransition 61
synchronized transition 59
synchronized variable access method 81
Ttransition 51

format of, 65
transition and state type 57
transition range 64
transition symbol 49transition type 51
tree schedule 91
trigger activity 74
trigger event 23
Vvariable event analyzer 79
variable memory event 9
variables
how to access, 14
Wwildcard transition 60
X-Z
zdi / zei / zdil / zeil 156
zkill / zalive 151
zret 153
zset / zseth / zcheck 152
ztrap 156