Context Navigation

StateGraph.mo

Revision 463, 120.3 kB (checked in by hubertus, 21 months ago)
Created maintenance version from Dynasims version with minimal changes (no checksum, 1 graphics, a few improved documentation places, structurallyIncomplete annotations in Visualizers)

Line
1	package StateGraph
2	"Library to model discrete event and reactive systems by hierarchical state machines"
3
4	extends Modelica.Icons.Library2;
5
6	annotation (
7	version="0.87",
8	versionDate="2004-06-23",
9	preferedView="info",
10	Documentation(info="<html>
11	<p>
12	Library <b>StateGraph</b> is a <b>free</b> Modelica package providing
13	components to model <b>discrete event</b> and <b>reactive</b>
14	systems in a convenient
15	way. It is based on the JGraphChart method and
16	takes advantage of Modelica features for
17	the \"action\" language. JGraphChart is a further development of
18	Grafcet to include elements of StateCharts that are not present
19	in Grafcet/Sequential Function Charts. Therefore, the StateGraph
20	library has a similar modeling power as StateCharts but avoids
21	some deficiences of StateCharts.
22	</p>
23	<p>
24	For an introduction, have especially a look at:
25	</p>
26	<ul>
27	<li> <a href=\"Modelica:Modelica.StateGraph.UsersGuide\">StateGraph.UsersGuide</a>
28	discusses the most important aspects how to use this library.</li>
29	<li> <a href=\"Modelica:Modelica.StateGraph.Examples\">StateGraph.Examples</a>
30	contains examples that demonstrate the usage of this library.</li>
31	</ul>
32	<p>
33	A typical model generated with this library is shown
34	in the next figure where on the left hand side a two-tank
35	system with a tank controller and on the right hand side the
36	top-level part of the tank controller as a StateGraph is shown:
37	</p>
38	<p>
39	<img src=\"../Images/StateGraph/Examples/ControlledTanks1_small.png\">
40	<img src=\"../Images/StateGraph/Examples/ControlledTanks2_small.png\">
41	</p>
42	<p>
43	The unique feature of the StateGraph library with respect to JGraphCharts,
44	Grafcet, Sequential Function Charts, and StateCharts, is Modelica's
45	\"single assignment rule\" that requires that every variable is defined
46	by exactly one equation. This leads to a different \"action\" definition
47	as in these formalisms. The advantage is that the translator can either
48	determine a useful evaluation sequence by equation sorting or
49	reports an error if this is not possible, e.g., because a model
50	would lead to a non-determinism or to a dead-lock. As a side effect,
51	this leads also to simpler and more easier to understand models and
52	global variables are no longer needed (whereas in JGraphCharts,
53	Grafcet, Sequential Function Charts and StateCharts global variables
54	are nearly always needed).
55	</p>
56	<p>
57	The StateGraph library is currently available in a beta release.
58	The available components will most likely not be changed for the
59	release version. It is planned to improve the convenience of
60	building models with the StateGraph library for the release version
61	(this may require to introduce some additional annotations).
62	It is planned to include the StateGraph library in the
63	Modelica standard library.
64	It is most useful to combine this libray with the Modelica libraries
65	</p>
66	<ul>
67	<li><b>Modelica.Blocks.Logical</b> that provides
68	components available in PLCs (programmable logic controllers). </li>
69	<li><b>UserInteraction</b> that provides components to
70	interactively communicate with models in a running simulation.</li>
71	</ul>
72
73	<p>
74	Copyright © 1998-2006, Modelica Association and DLR
75	</p>
76	<p>
77	<i>The Modelica package is <b>free</b> software; it can be redistributed and/or modified
78	under the terms of the <b>Modelica license</b>, see the license conditions
79	and the accompanying <b>disclaimer</b>
80	<a href=\"Modelica://Modelica.UsersGuide.ModelicaLicense\">here</a>.</i>
81	</p><br>
82
83	</HTML>
84	"),
85	Window(
86	x=0.05,
87	y=0.06,
88	width=0.29,
89	height=0.59,
90	library=1,
91	autolayout=1),
92	Icon(
93	Rectangle(extent=[-88,-20; -50,-54], style(color=0, rgbcolor={0,0,0})),
94	Line(points=[-50,-38; -24,-38], style(
95	color=0,
96	rgbcolor={0,0,0},
97	fillColor=0,
98	rgbfillColor={0,0,0},
99	fillPattern=1)),
100	Polygon(points=[-24,-32; -12,-38; -24,-44; -24,-32], style(
101	color=0,
102	rgbcolor={0,0,0},
103	fillColor=0,
104	rgbfillColor={0,0,0})),
105	Line(points=[-12,-6; -12,-76],
106	style(color=0, rgbcolor={0,0,0})),
107	Line(points=[-12,-38; 14,-38], style(
108	color=0,
109	rgbcolor={0,0,0},
110	fillColor=0,
111	rgbfillColor={0,0,0},
112	fillPattern=1)),
113	Polygon(points=[14,-32; 26,-38; 14,-44; 14,-32], style(
114	color=0,
115	rgbcolor={0,0,0},
116	fillColor=0,
117	rgbfillColor={0,0,0})),
118	Rectangle(extent=[26,-22; 64,-56], style(color=0, rgbcolor={0,0,0}))));
119
120	package UsersGuide "Users Guide"
121
122	annotation (DocumentationClass=true, Documentation(info="<html>
123	<h3><font color=\"#008000\" size=5>Users Guide of package StateGraph</font></h3>
124	<p>
125	Library <b>StateGraph</b> is a <b>free</b> Modelica package providing
126	components to model <b>discrete event</b> and <b>reactive</b>
127	systems in a convenient
128	way. This package contains the <b>users guide</b> for
129	the library and has the following content:
130	</p>
131	<ol>
132	<li><a href=\"Modelica://Modelica.StateGraph.UsersGuide.OverView\">Overview of library</a>
133	gives an overview of the library.</li>
134	<li> <a href=\"Modelica://Modelica.StateGraph.UsersGuide.FirstExample\">A first example</a>
135	demonstrates at hand of a first example how to use this library.</li>
136	<li> <a href=\"Modelica://Modelica.StateGraph.UsersGuide.ApplicationExample\">An
137	application example</a> demonstrates varies features at hand of the
138	control of a two tank system.</li>
139	<li><a href=\"Modelica://Modelica.StateGraph.UsersGuide.ReleaseNotes\">Release Notes</a>
140	summarizes the differences between different versions of this library.</li>
141	<li><a href=\"Modelica://Modelica.StateGraph.UsersGuide.Literature\">Literature</a>
142	provides references that have been used to design and implement this
143	library.</li>
144	<li><a href=\"Modelica://Modelica.StateGraph.UsersGuide.Contact\">Contact</a>
145	provides information about the authors of the library as well as
146	acknowledgments.</li>
147	</ol>
148	</html>"));
149
150	class OverView "Overview of library"
151
152	annotation (Documentation(info="<html>
153	<h3><font color=\"#008000\" size=5>Overview of Library StateGraph</font></h3>
154	<p>
155	In this section, an overview of the most important features
156	of this library is given.
157	</p>
158	<h4><font color=\"#008000\">Steps and Transitions</font></h4>
159	<p>
160	A <b>StateGraph</b> is an enhanced finite state machine.
161	It is based on the JGraphChart method and
162	takes advantage of Modelica features for
163	the \"action\" language. JGraphChart is a further development of
164	Grafcet to include elements of StateCharts that are not present
165	in Grafcet/Sequential Function Charts. Therefore, the StateGraph
166	library has a similar modeling power as StateCharts but avoids
167	some deficiences of StateCharts.
168	</p>
169	<p>
170	The basic elements of StateGraphs are <b>steps</b> and <b>transitions</b>:
171	</p>
172	<p align=\"center\">
173	<img src=\"../Images/StateGraph/UsersGuide/StepAndTransition1.png\">
174	</p>
175	<p>
176	<b>Steps</b> represent the possible states a StateGraph can have.
177	If a step is active the Boolean variable <b>active</b> of
178	the step is <b>true</b>. If it is deactivated,
179	<b>active</b> = <b>false</b>. At the initial time, all \"usual\"
180	steps are deactivated. The <b>InitialStep</b> objects are steps
181	that are activated at the initial time. They are characterized
182	by a double box (see figure above).
183	</p>
184	<p>
185	<b>Transitions</b> are used to change the state of a StateGraph.
186	When the step connected to the input of a transition is active,
187	the step connected to the output of this transition is deactivated
188	and the transition condition becomes true, then the
189	transition fires. This means that the step connected to the input to the
190	transition is deactivated and the step connected to the output
191	of the transition is activated.
192	</p>
193	<p>
194	The transition <b>condition</b> is defined via the parameter menu
195	of the transition object. Clicking on object \"transition1\" in
196	the above figure, results in the following menu:
197	</p>
198	<p align=\"center\">
199	<img src=\"../Images/StateGraph/UsersGuide/StepAndTransition2.png\">
200	</p>
201	<p>
202	In the input field \"<b>condition</b>\", any type of time varying
203	Boolean expression can be given (in Modelica notation, this is
204	a modification of the time varying variable <b>condition</b>).
205	Whenever this condition is true, the transition can fire.
206	Additionally, it is possible to activate a timer, via
207	<b>enableTimer</b> (see menu above) and provide a
208	<b>waitTime</b>. In this case the firing of the transition
209	is delayed according to the provided waitTime. The transition
210	condition and the waitTime are displayed in the transition icon.
211	</p>
212	<p>
213	In the above example, the simulation starts at <b>initialStep</b>.
214	After 1 second, <b>transition1</b> fires and <b>step1</b> becomes
215	active. After another second <b>transition2</b> fires and
216	<b>initialStep</b> becomes again active. After a further
217	second <b>step1</b> becomes again active, and so on.
218	</p>
219	<p>
220	In JGrafcharts, Grafcet and Sequential Function Charts, the
221	network of steps and transitions is drawn from top to bottom.
222	In StateGraphs, no particular direction is defined, since
223	steps and transitions are blocks with input and output connectors
224	that can be arbitrarily placed and connected. Usually, it is
225	most practical to define the network from left to right,
226	as in the example above, since then it is easy to read the
227	labels on the icons.
228	</p>
229	<h4><font color=\"#008000\">Conditions and Actions</font></h4>
230	<p>
231	With the block <b>TransitionWithSignal</b>, the firing condition
232	can be provided as Boolean input signal, instead as entry in the
233	menu of the transition. An example is given in the next
234	figure:
235	</p>
236	<p align=\"center\">
237	<img src=\"../Images/StateGraph/UsersGuide/StepAndTransition3.png\">
238	</p>
239	<p>
240	Component \"step\" is an instance of \"StepWithSignal\" that is
241	a usual step where the active flag is available as Boolean
242	output signal. To this output, component \"Timer\" from
243	library \"Modelica.Blocks.Logical\" is connected. It measures the
244	time from the time instant where the Boolean input (i.e., the
245	active flag of the step) became true upto the current
246	time instant. The timer is connected to a comparison
247	component. The output is true, once the timer reaches
248	1 second. This signal is used as condition input of the
249	transition. As a result, \"transition2\" fires, once step
250	\"step\" has been active for 1 second.
251	Of course, any other
252	Modelica block with a Boolean output signal can be
253	connected to the condition input of such a transition block
254	as well.
255	</p>
256	<p>
257	Conditions of a transition can either be computed by
258	a network of logical blocks from the Logical library as
259	in the figure above, or via the \"SetBoolean\" component
260	any type of logical expression can be defined in textual
261	form, as shown in the next figure:
262	</p>
263	<p align=\"center\">
264	<img src=\"../Images/StateGraph/UsersGuide/StepAndTransition4.png\">
265	</p>
266	<p>
267	With the block \"<b>SetBoolean</b>\", a time varying expression
268	can be provided as modification to the output signal <b>y</b>
269	(see block with icon text \"timer.y > 1\" in the figure above).
270	The output signal can be in turn connected to the condition
271	input of a TransitionWithSignal block.
272	</p>
273	<p>
274	The \"<b>SetBoolean</b>\" block can also be used to
275	compute a Boolean signal depending on the active step.
276	In the figure above, the output of the block with the
277	icon text \"step.active\" is
278	true, when \"step\" is active, otherwise it is false
279	(note, the icon text of \"SetBoolean\" displays the modification
280	of the output signal \"y\").
281	This signal can then be used to compute desired <b>actions</b>
282	in the physical systems model. For example, if a <b>valve</b>
283	shall be open, when the StateGraph is in \"step1\" or
284	in \"step4\", a \"SetBoolean\" block may be connected to the
285	valve model using the following condition:
286	</p>
287	<pre>
288	valve = step1.active <b>or</b> step2.active
289	</pre>
290	<p>
291	Via the Modelica operators <b>edge</b>(..) and <b>change</b>(..),
292	conditions depending on rising and falling edges of
293	Boolean expressions can be used when needed.
294	</p>
295	<p>
296	In JGrafcharts, Grafcet, Sequential Function Charts and StateCharts,
297	<b>actions</b> are formulated <b>within a step</b>. Such actions are
298	distinguished as <b>entry</b>, <b>normal</b>, <b>exit</b> and
299	<b>abort</b> actions. For example, a valve might be opened by
300	an entry action of a step and might be closed by an exit
301	action of the same step. In StateGraphs, this is (fortunately)
302	<b>not possible</b>
303	due to Modelicas \"single assignment rule\" that requires that every
304	variable is defined by exactly one equation. Instead, the
305	approach explained above is used. For example, via the
306	\"SetBoolean\" component, the valve variable is set to true
307	when the StateGraph is in particular steps.
308	</p>
309	<p>
310	This feature of a StateGraph is <b>very useful</b>, since it allows
311	a Modelica translator to <b>guarantee</b> that a given StateGraph
312	has always <b>deterministic</b> behaviour without conflicts.
313	In the other methodologies this is much more cumbersome. For example,
314	if two steps are executed in parallel and both step actions
315	modify the same variable, the result is either non-deterministic
316	or non-obvious rules have to be defined which action
317	takes priority. In a StateGraph, such a situation is detected by
318	the translator resulting in an error, since there are two equations
319	to compute one variable. Additional benefits of the StateGraph
320	approach are:
321	</p>
322	<ul>
323	<li> A JGrafchart or a StateChart need to potentially access
324	variables in a step that are defined in
325	higher hierarchical levels of a model. Therefore, mostly <b>global
326	variables</b> are used in the whole network, even if the
327	network is structured hierarchically. In StateGraphs this
328	is not necessary, since the physical systems outside
329	of a StateGraph might access the step or transition state
330	via a hierarchical name. This means that <b>no global variables</b>
331	are needed, because the local variables in the StateGraph
332	are accessed from local variables outside of the StateGraph.
333	</li>
334	<li> It is simpler for a user to understand the information that
335	is provided in the non-graphical definition, since every
336	variable is defined at exactly one place. In the other
337	methodologies, the setting and re-setting of the same
338	variable is cluttered within the whole network.
339	</li>
340	</ul>
341	<p>
342	To emphasize this important difference between these methodologies,
343	consider the case that a state machine has the following
344	hierarchy:
345	</p>
346	<pre>
347	stateMachine.superstate1.superstate2.step1
348	</pre>
349	<p>
350	Within \"step1\" a StateChart would, e.g., access variable
351	\"stateMachine.openValve\", say as \"entry action: openValve = true\".
352	This typical usage has the severe drawback that it is not possible
353	to use the hierarchical state \"superstate1\" as component in another
354	context, because \"step1\" references a particular name outside of this
355	component.
356	</p>
357	<p>
358	In a StateGraph, there would be typically a \"SetBoolean\" component
359	in the \"stateMachine\" component stating:
360	</p>
361	<pre>
362	openValve = superstate1.superstate2.step1.active;
363	</pre>
364	<p>
365	As a result, the \"superstate1\" component can be used in
366	another context, because it does not depend on the environment
367	where it is used.
368	</p>
369	<h4><font color=\"#008000\">Execution Model</font></h4>
370	<p>
371	The execution model of a StateGraph follows from its
372	Modelica implementation: Given the states of all steps, i.e.,
373	whether a step is active or not active, the equations of all
374	steps, transitions, transition conditions, actions etc. are
375	sorted resulting in an execution sequence to compute
376	essentially the new values of the steps. If conflicts occur,
377	e.g., if there are more equations as variables, of if there
378	are algebraic loops between Boolean variables, an exception
379	is raised. Once all equations have been processed, the
380	<b>active</b> variable of all steps are updated to the newly
381	calculated values. Afterwards, the equations are again
382	evaluated. The iteration stops, once no step changes
383	its state anymore, i.e., once no transition fires anymore.
384	Then, simulation continuous until a new event is triggered,
385	(when a relation changes its value).
386	</p>
387	<p>
388	With the Modelica \"sampled(..)\" operator, a StateGraph might also
389	be executed within a discrete controller that is called
390	at regular time instants. In a future version of the StateGraph
391	library, this might be more directly supported.
392	</p>
393	<h4><font color=\"#008000\">Parallel and Alternative Execution</font></h4>
394	<p>
395	Parallel activities can be defined by
396	component <b>Parallel</b> and alternative activities
397	can be defined by component <b>Alternative</b>.
398	An example for both components is given in the next figure.
399	</p>
400	<p align=\"center\">
401	<img src=\"../Images/StateGraph/UsersGuide/Parallel1.png\">
402	</p>
403	<p>
404	Here, the branch from \"step2\" to \"step5\" is executed in parallel
405	to \"step1\". A transition connected to the output of a parallel
406	branch component can only fire if the final steps
407	in all parallel branches are active simultaneously.
408	The figure above is a screen-shot from the animation of the
409	StateGraph: Whenever a step is active or a transition can fire,
410	the corresponding component is marked in <b>green</b> color.
411	</p>
412	<p>
413	The three branches within \"step2\" to \"step5\" are
414	executed alternatively, depending which transition condition
415	of \"transition3\", \"transition4\", \"transition4a\" fires first.
416	Since all three transitions fire after 1 second, they are all
417	candidates for the active branch. If two or more transitions
418	would fire at the same time instant, a priority selection
419	is made: The alternative and parallel components have a
420	vector of connectors. Every branch has to be connected to
421	exactly one entry of the connector vector. The entry with
422	the lowest number has the highest priority.
423	</p>
424	<p>
425	Parallel, Alternative and Step components have vectors of
426	connectors. The dimensions of these vectors are set in the
427	corresponding parameter menu. E.g. in a \"Parallel\" component:
428	</p>
429	<p align=\"center\">
430	<img src=\"../Images/StateGraph/UsersGuide/Parallel2.png\">
431	</p>
432	<p>
433	Currently in Dymola the following menu pops up, when a branch
434	is connected to a vector of components in order to define
435	the vector index to which the component shall be connected:
436	</p>
437	<p align=\"center\">
438	<img src=\"../Images/StateGraph/UsersGuide/Parallel3.png\">
439	</p>
440	<h4><font color=\"#008000\">CompositeSteps, Suspend and Resume Port</font></h4>
441	<p>
442	A StateGraph can be hierarchically structured by using a <b>CompositeStep</b>.
443	This is a component that inherits from <b>PartialCompositeStep</b>.
444	An example is given in the next figure (from Examples.ControlledTanks):
445	</p>
446	<p align=\"center\">
447	<img src=\"../Images/StateGraph/UsersGuide/CompositeStep1.png\">
448	</p>
449	<p>
450	The CompositeStep component contains a local StateGraph that is
451	entered by one or more input transitions and that is left
452	by one or more output transitions. Also, other needed signals
453	may enter a CompositeStep. The CompositeStep has similiar properties
454	as a \"usual\" step: The CompositeStep is <b>active</b> once at least
455	one step within the CompositeStep is active. Variable <b>active</b>
456	defines the state of the CompositeStep.
457	</p>
458	<p>
459	Additionally, a CompositeStep has a <b>suspend</b> port. Whenever the
460	transition connected to this port fires, the CompositeStep is left
461	at once. When leaving the CompositeStep via the suspend port, the internal
462	state of the CompositeStep is saved, i.e., the active flags of all
463	steps within the CompositeStep. The CompositeStep might be entered via
464	its <b>resume</b> port. In this case the internal state from the
465	suspend transition is reconstructed and the CompositeStep continues
466	the execution that it had before the suspend transition fired
467	(this corresponds to the history ports of StateCharts or JGrafCharts).
468	</p>
469	<p>
470	A CompositeStep may contain other CompositeSteps. At every level,
471	a CompositeStep and all of its content can be left via its suspend ports
472	(actually, there
473	is a vector of suspend connectors, i.e., a CompositeStep might
474	be aborted due to different transitions).
475	</p>
476	</html>
477	"));
478	end OverView;
479
480	class FirstExample "A first example"
481
482	annotation (Documentation(info="<html>
483	<h3><font color=\"#008000\" size=5>A first example</font></h3>
484	<p>
485	A first example will be given here (not yet done).
486	</p>
487	</html>
488	"));
489	end FirstExample;
490
491	class ApplicationExample "An application example"
492
493	annotation (Documentation(info="<html>
494	<h3><font color=\"#008000\" size=5>An application example</font></h3>
495	<p>
496	In this section a more realistic, still simple, application example
497	is given, to demonstrate various features of the StateGraph library.
498	This example shows the control of a two tank system from the master thesis
499	of Isolde Dressler
500	(<a href=\"Modelica://Modelica.StateGraph.UsersGuide.Literature\">see literature</a>).
501	</p>
502	<p>
503	In the following figure the top level of the model is shown.
504	This model is available as StateGraph.Examples.ControlledTanks.
505	</p>
506	<p align=\"center\">
507	<img src=\"../Images/StateGraph/Examples/ControlledTanks1.png\">
508	</p>
509	<p>
510	In the right part of the figure, two tanks are shown. At the top part,
511	a large fluid source is present from which fluid can be filled in
512	<b>tank1</b> when <b>valve1</b> is open. Tank1 can be emptied via
513	<b>valve2</b> that is located in the bottom of tank2 and
514	fills a second <b>tank2</b> which in turn is emptied via
515	<b>valve3</b>. The actual levels of the tanks are measured
516	and are provided as signals <b>level1</b> and <b>level2</b>
517	to the <b>tankController</b>.
518	</p>
519	<p>
520	The <b>tankController</b> is controlled by three buttons,
521	<b>start</b>, <b>stop</b> and <b>shut</b> (for shutdown)
522	that are mutually exclusive. This means that whenever one button is
523	pressed (i.e., its state is <b>true</b>) then the other two
524	buttons are not pressed (i.e., their states are <b>false</b>).
525	When button <b>start</b> is pressed, the \"normal\" operation
526	to fill and to empty the two tanks is processed:
527	</p>
528	<ol>
529	<li> Valve 1 is opened and tank 1 is filled.</li>
530	<li> When tank 1 reaches its fill level limit,
531	valve 1 is closed. </li>
532	<li> After a waiting time, valve 2 is
533	opened and the fluid flows from tank 1 into tank 2.</li>
534	<li> When tank 1 is empty, valve 2 is closed. </li>
535	<li> After a waiting time, valve 3 is opened and
536	the fluid flows out of tank 2</li>
537	<li> When tank 2 is empty, valve 3 is closed</liI>
538	</ol>
539	<p>
540	The above \"normal\" process can be influenced by the following
541	buttons:
542	</p>
543	<ul>
544	<li> Button <b>start</b> starts the above process.
545	When this button is pressed after a \"stop\" or
546	\"shut\" operation, the process operation continues.
547	</li>.
548	<li> Button <b>stop</b> stops the above process by
549	closing all valves. Then, the controller waits for
550	further input (either \"start\" or \"shut\" operation).</li>
551	<li> Button <b>shut</b> is used to shutdown the process,
552	by emptying at once both tanks. When this is achieved,
553	the process goes back to its start configuration.
554	Clicking on \"start\", restarts the process.</li>
555	</ul>
556	<p>
557	The implementation of the <b>tankController</b> is shown in
558	the next figure:
559	</p>
560	<p align=\"center\">
561	<img src=\"../Images/StateGraph/Examples/ControlledTanks2.png\">
562	</p>
563	<p>
564	When the \"<b>start</b>\" button is pressed, the stateGraph is
565	within the CompositeStep \"<b>makeProduct</b>\". During normal
566	operation this CompositeStep is only left, once tank2 is empty.
567	Afterwards, the CompositeStep is at once re-entered.
568	</p>
569	<p>
570	When the \"<b>stop</b>\" button is pressed, the \"makeProduct\"
571	CompositeStep is at once terminated via the \"<b>suspend</b>\" port
572	and the stateGraph waits in step \"<b>s2</b>\" for further
573	commands. When the \"<b>start</b>\" button is pressed, the CompositeStep
574	is re-entered via its <b>resume</b> port and the \"normal\"
575	operation continues at the state where it was aborted by the
576	suspend transition. If the \"<b>shut</b>\" button is pressed,
577	the stateGraph waits in the \"<b>emptyTanks</b>\" step, until
578	both tanks are empty and then waits at the initial step
579	\"<b>s1</b>\" for further input.
580	</p>
581	<p>
582	The opening and closing of valves is <b>not</b> directly
583	defined in the stateGraph. Instead via the \"<b>setValveX</b>\"
584	components, the Boolean state of the valves are computed.
585	For example, the output y of \"setValve2\" is computed as:
586	</p>
587	<pre>
588	y = makeProduct.fillTank2.active or emptyTanks.active
589	</pre>
590	<p>
591	i.e., valve2 is open, when step \"makeProduct.fillTank2 or when
592	step \"emptyTanks\" is active. Otherwise, valve2 is closed.
593	</p>
594	</html>
595	"));
596	end ApplicationExample;
597
598	class ReleaseNotes "Release notes"
599
600	annotation (Documentation(info="<html>
601	<h3><font color=\"#008000\" size=5>Release notes</font></h3>
602	<h3><font color=\"#008000\">Version 0.87, 2004-06-23</font></h3>
603	<ul>
604	<li> Included in Modelica standard library 2.0 Beta 1 with the new block connectors.
605	Changed all the references to the block connectors and the Logical library
606	correspondingly.</li>
607	</ul>
608	<h3><font color=\"#008000\">Version 0.86, 2004-06-20</font></h3>
609	<ul>
610	<li> New components \"Alternative\" and \"Parallel\" for alternative and
611	parallel execution paths.</li>
612	<li> A step has now a vector of input and output connectors in order
613	that multiple connections to and from a step are possible</li>
614	<li> Removed components \"AlternativeSplit\", \"AlternativeJoin\",
615	\"ParallelSplit\" and \"ParallelJoin\" since the newly introduced
616	components (\"Alternative\", \"Parallel\", vector connectors of steps)
617	have the same modeling power but are safer and more convenient.</li>
618	<li> Removed the timer in a step (attach instead Logical.Timer to
619	the \"active\" port of a \"StepWithSignal\" component). Note, that in
620	most cases it is more convenient and more efficient to use the
621	built-in timer of a transition.</li>
622	<li> Component \"StepInitial\" renamed to \"InitialStep\".</li>
623	<li> New component \"Timer\" within sublibrary Logical.</li>
624	<li> Updated and improved documentation of the library.</li>
625	</ul>
626	<h3><font color=\"#008000\">Version 0.85, 2004-06-17</font></h3>
627	<ul>
628	<li> Renamed \"MacroStep\" to \"CompositeStep\" and the ports of the MacroStep
629	from \"abort\" to \"suspend\" and \"histoy\" to \"resume\".</li>
630	<li> Nested \"CompositeStep\" components are supported, based on the
631	experimental feature of nested inner/outer components
632	introduced by Dymola. This means that CompositeSteps can
633	be suspended and resumed at every level.</li>
634	<li> New example \"Examples.ShowExceptions\" to demonstrate the new
635	feature of nested CompositeSteps.</li>
636	<li> New package \"Logical\". It contains all components of
637	ModelicaAdditions.Blocks.Logical, but with new block connectors
638	and nicer icons. Additionally, logical blocks are also added.</li>
639	<li> Improved icons for several components of the StateGraph library.</li>
640	</ul>
641	<h3><font color=\"#008000\">Version 0.83, 2004-05-21</font></h3>
642	<ul>
643	<li> The \"abort\" and \"history\" connectors are no longer visible in the
644	diagram layer of a CompositeStep since it is not allowed to connect
645	to them in a CompositeStep.</li>
646	<li> Made the diagram/icon size of a CompositeStep smaller (from 200/-200 to
647	150/-150).</li>
648	<li> Improved icons for \"SetBoolean/SetInteger/SetReal\" components.</li>
649	<li> Renamed \"ParameterReal\" to \"SetRealParameter\".</li>
650	</ul>
651	<h3><font color=\"#008000\">Version 0.82, 2004-05-18</font></h3>
652	<p>
653	Implemented a first version that is provided to other people.
654	</p>
655	</html>
656	"));
657	equation
658
659	end ReleaseNotes;
660
661	class Literature "Literature"
662
663	annotation (Documentation(info="<html>
664	<h3><font color=\"#008000\" size=5>Literature</font></h3>
665	<p>
666	The StateGraph library is based on the following references:
667	</p>
668	<dl>
669	<dt>Arzen K.-E. (2004):</dt>
670	<dd> <b>JGrafchart User Manual. Version 1.5</b>.
671	Department of Automatic Control, Lund Institute of Technology,
672	Lund, Sweden, Feb. 13<br> </dd>
673	<dt>Dressler I. (2004):</dt>
674	<dd> <b>Code Generation From JGrafchart to Modelica</b>.
675	Master thesis, supervisor: Karl-Erik Arzen,
676	Department of Automatic Control, Lund Institute of Technology,
677	Lund, Sweden, March 30<br> </dd>
678	<dt>Elmqvist H., Mattsson S.E., Otter M. (2001):</dt>
679	<dd> <b>Object-Oriented and Hybrid Modeling in Modelica</b>.
680	Journal Europeen des systemes automatises (JESA),
681	Volume 35 - n. 1.<br> </dd>
682	<dt>Mosterman P., Otter M., Elmqvist H. (1998):</dt>
683	<dd> <b>Modeling Petri Nets as Local Constraint Equations for
684	Hybrid Systems using Modelica</b>.
685	SCSC'98, Reno, Nevada, USA,
686	Society for Computer Simulation International, pp. 314-319.
687	</dd>
688	</dl>
689	</html>
690	"));
691
692	end Literature;
693
694	class Contact "Contact"
695
696	annotation (Documentation(info="<html>
697	<h3><font color=\"#008000\" size=5>Contact</font></h3>
698	<dl>
699	<dt><b>Main Author:</b>
700	<dd><a href=\"http://www.robotic.dlr.de/Martin.Otter/\">Martin Otter</a><br>
701	Deutsches Zentrum für Luft und Raumfahrt e.V. (DLR)<br>
702	Institut für Robotik und Mechatronik<br>
703	Abteilung für Entwurfsorientierte Regelungstechnik<br>
704	Postfach 1116<br>
705	D-82230 Wessling<br>
706	Germany<br>
707	email: <A HREF=\"mailto:Martin.Otter@dlr.de\">Martin.Otter@dlr.de</A><br>
708	</dl>
709	<p><b>Acknowledgements:</b></p>
710	<ul>
711	<li> The development of this library was strongly motivated by the
712	master thesis of Isolde Dressler
713	(<a href=\"Modelica://Modelica.StateGraph.UsersGuide.Literature\">see literature</a>),
714	in which
715	a compiler from JGrafChart to Modelica was designed and
716	implemented. This project was supervised by Karl-Erik Arzen
717	from Departement of Automatic Control, Lund Institut of
718	Technology, Lund, Sweden.</li>
719	<li> This library profits also from the experience gained
720	in the focused research program (Schwerpunktprogramm)
721	\"Continuous-Discrete Dynamic Systems\" (KONDISK), sponsored by the
722	Deutsche Forschungsgemeinschaft under grants OT174/1-2 and EN152/22-2.
723	This support is most gratefully acknowledged.
724	</li>
725	<li> The implementation of the basic components of this library by describing
726	finite state machines with equations is based on
727	(Elmqvist, Mattsson and Otter, 2001),
728	which in turn uses ideas from (Mosterman, Otter and Elmqvist, 1998),
729	see <a href=\"Modelica://Modelica.StateGraph.UsersGuide.Literature\">literature</a></li>
730	</ul>
731	</html>
732	"));
733
734	end Contact;
735
736	end UsersGuide;
737
738	package Examples
739	"Examples to demonstrate the usage of the components of the StateGraph library"
740
741	model FirstExample "A first simple StateGraph example"
742	extends Modelica.Icons.Example;
743	InitialStep initialStep annotation(extent=[-48,0; -28,20]);
744	Transition transition1(enableTimer=true, waitTime=1)
745	annotation(extent=[-20,0; 0,20]);
746	Step step annotation(extent=[10,0; 30,20]);
747	Transition transition2(enableTimer=true, waitTime=1)
748	annotation(extent=[40,0; 60,20]);
749	equation
750
751	annotation (
752	Diagram,
753	experiment(StopTime=5),
754	experimentSetupOutput,
755	Documentation(info="<html>
756
757	</html>"));
758	connect(initialStep.outPort[1], transition1.inPort)
759	annotation(points=[-27.5,10; -14,10],style(color=0, rgbcolor={0,0,0}));
760	connect(transition1.outPort, step.inPort[1])
761	annotation(points=[-8.5,10; 9,10], style(color=0, rgbcolor={0,0,0}));
762	connect(step.outPort[1], transition2.inPort)
763	annotation(points=[30.5,10; 46,10],style(color=0, rgbcolor={0,0,0}));
764	connect(transition2.outPort, initialStep.inPort[1]) annotation(points=[51.5,
765	10; 70,10; 70,32; -62,32; -62,10; -49,10], style(color=0, rgbcolor={0,0,
766	0}));
767	end FirstExample;
768
769	model FirstExample_Variant2
770	"A variant of the first simple StateGraph example"
771	extends Modelica.Icons.Example;
772	InitialStep initialStep annotation(extent=[-70,0; -50,20]);
773	Transition transition1(enableTimer=true, waitTime=1)
774	annotation(extent=[-42,0; -22,20]);
775	StepWithSignal step
776	annotation(extent=[-14,0; 6,20]);
777	TransitionWithSignal transition2
778	annotation(extent=[52,0; 72,20]);
779	Modelica.Blocks.Logical.Timer timer annotation(extent=[6,-40; 26,-20]);
780	Modelica.Blocks.Logical.GreaterEqualThreshold greaterEqual(threshold=1)
781	annotation(extent=[36,-40; 56,-20]);
782	equation
783
784	annotation (structurallyIncomplete,
785	Diagram,
786	experiment(StopTime=5),
787	experimentSetupOutput,
788	Documentation(info="<html>
789
790	</html>"));
791	connect(initialStep.outPort[1], transition1.inPort)
792	annotation(points=[-49.5,10; -36,10],style(color=0, rgbcolor={0,0,0}));
793	connect(transition1.outPort, step.inPort[1])
794	annotation(points=[-30.5,10; -15,10],
795	style(color=0, rgbcolor={0,0,0}));
796	connect(step.active, timer.u) annotation(points=[-4,-1; -4,-30; 4,-30],
797	style(color=5, rgbcolor={255,0,255}));
798	connect(step.outPort[1], transition2.inPort)
799	annotation(points=[6.5,10; 58,10], style(color=0, rgbcolor={0,0,0}));
800	connect(timer.y, greaterEqual.u)
801	annotation(points=[27,-30; 34,-30], style(color