Context Navigation

StateGraph.mo

Revision 921, 116.9 kB (checked in by otter, 9 months ago)
Changed Modelica.StateGraph.Examples.Utilities.Tank: sqrt(..) changed to sqrt(max(0,2ghmax*level)) since a new implementation of sqrt(..) in Dymola may lead to an error here otherwise
Property svn:eol-style set to `native` Property svn:keywords set to `Author Date Id Revision`

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