Browse Source

sintactic changes to allow chained declarations of in/out vars and params. Ignored tests done on outdated files, and included tests that are part of the case study described in the paper.

Cláudio Gomes 4 years ago
parent
commit
878514bb9f
13 changed files with 183 additions and 500 deletions
  1. 79 0
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/power_window_case_study/window_sa.BASE.sa
  2. 67 0
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/power_window_case_study/window_sa_canonical.BASE.sa
  3. 1 1
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_algebraic_loop_iteration_BASE.sa
  4. 0 76
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_controller_delay_BASE.sa
  5. 0 41
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_multi_rate_BASE.sa
  6. 11 10
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/src/be/uantwerpen/ansymo/semanticadaptation/tests/SemanticAdaptationGeneratorTest.xtend
  7. 11 11
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/src/be/uantwerpen/ansymo/semanticadaptation/tests/SemanticAdaptationParsingTest.xtend
  8. 0 54
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/controller_sa_BASE_proposed_claudio.sa
  9. 0 61
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/powerwindow_controller_delay_BASE.sa
  10. 0 185
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle.BASE.sa
  11. 0 36
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle_sa_loop_BASE_proposed.sa
  12. 0 22
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle_sa_multirate_BASE_proposed_claudio.sa
  13. 14 3
      DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/src/be/uantwerpen/ansymo/semanticadaptation/SemanticAdaptation.xtext

+ 79 - 0
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/power_window_case_study/window_sa.BASE.sa

@@ -0,0 +1,79 @@
+module Window_SA
+
+semantic adaptation reactive mealy WindowSA windowSA
+at "./path/to/WindowSA.fmu"
+
+/*
+Reactive means that the unit expects the following treatment:
+Supose the external master is at time t, and that there is an FMU f providing inputs to windowsa.
+Then,
+f.doStep(t, H) // f goes from t->t+H 
+u := f.getValues(...)
+windowsa.setValues(u) // Input provided from the future (t+H)
+windowsa.doStep(t, H) // windowsa goes from t->t+H
+v := windowsa.getValues(...)
+
+Delayed unit means that the unit expects the following treatment:
+Supose the external master is at time t, and that there is an FMU f providing inputs to windowsa.
+Then,
+pu := f.getValues(...)
+f.doStep(t, H) // f goes from t->t+H 
+windowsa.setValues(pu) // Input provided at the time t
+windowsa.doStep(t, H) // windowsa goes from t->t+H and does not need input at time (t+H)
+v := windowsa.getValues(...)
+
+
+Mealy unit means the following:
+windowsa.setValues(v1)  // values set at time t
+o1 = windowsa.getValues() // values set at time t
+assert v2 <> v1 // Assumption
+windowsa.setValues(v2)  // values set at time t
+o2 = windowsa.getValues() // values set at time t
+It is probably the case that o1 <> o2
+
+Moore unit means the following:
+windowsa.setValues(v1)  // values set at time t
+o1 = windowsa.getValues() // values set at time t
+assert v2 <> v1 // Assumption
+windowsa.setValues(v2)  // values set at time t
+o2 = windowsa.getValues() // values set at time t
+It must be the case that o1 == o2
+In other words, the output at time t, only depends on the state at time t.
+*/
+
+	
+	/*
+	The definition for the wrappen FMU is now done here.
+	This is because, for adaptations that wrap multiple FMUs as well as other adaptations, the connection information cannot be fully completed in the senario description (see the window_obstacle.sa example).
+	*/
+	for inner fmu Window window
+		at "./path/to/WindowSA.fmu"
+		with input ports displacement (rad), speed (rad/s), reaction_force (N)
+		with output ports height (m), reaction_torque (N.m)
+
+/*
+No need to have input ports declared for this model.
+Every input port of the original FMU will be automatically assumed to be an input port of the adapted FMU.
+
+If there is an input port window.p which is dangling, but is not declared here, then an input port windowsa.p will be created in the adapted FMU, and we will have that window.p -> windowsa.p.
+*/
+
+/*
+Declares two output ports, and specified how height is mapped to disp.
+Here, the units need to be specified, so that the conversion can take place.
+The units of disp can be either obtained from the scenario, or specified explicitly here.
+*/
+output ports disp (cm)  <- height, tau
+/*
+There are alternative ways that this can be interpreted:
+disp  := arbitrary_function(height) * 100 or arbitrary_function(height * 100) (they are not necessarily equal)
+We pick the first one, so what we have is this:
+aux_var := arbitrary_function(height);
+disp := aux_var*100; // This part never has to be coded.
+*/
+
+out rules {
+	true -> {} --> {
+		tau := -reaction_force;
+	};
+}

+ 67 - 0
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/power_window_case_study/window_sa_canonical.BASE.sa

@@ -0,0 +1,67 @@
+module Window_SA
+
+semantic adaptation reactive mealy WindowSA windowSA
+at "./path/to/WindowSA.fmu"
+
+	for inner fmu Window window
+		at "./path/to/WindowSA.fmu"
+		with input ports displacement (rad), speed (rad/s), reaction_force (N)
+		with output ports height (m), reaction_torque (N.m)
+
+/*
+In the original version, no input ports where declared, so all dangling inputs of the original fmus are bound to the input ports of the adapted FMU.
+In the canonical version, the input and output ports are all declared explicitly, and their bindings are implemented in the in/out rules.
+*/
+
+input ports 	reaction_force,
+				displacement,
+				speed
+
+output ports	disp,
+				tau
+
+
+control {
+	do_step(window, t, H); // includes update_in rules and update_out (update-in rules do not update state)
+	return H;
+}
+
+in var 	stored_windowsa_reaction_force := 0, 
+		stored_windowsa_displacement := 0, 
+		stored_windowsa_speed := 0;
+
+in rules {
+	true -> {
+		/*
+		is_set checks whether the input value is given in the setValues call of the adapted FMU.
+		Notice that in the canonical version, all ports are prefixed.
+		*/
+		if (is_set(windowSA.reaction_force)){
+			stored_windowsa_reaction_force := windowSA.reaction_force;
+		}
+		if (is_set(windowSA.displacement)){
+			stored_windowsa_displacement := windowSA.displacement;			
+		}
+		if (is_set(windowSA.speed)){
+			stored_windowsa_speed := windowSA.speed;
+		}
+	} --> {
+		window.reaction_force := stored_windowsa_reaction_force;
+		window.displacement := stored_windowsa_displacement; 
+		window.speed := stored_windowsa_speed;
+	};
+}
+
+out var stored_window_reaction_torque := 0,
+		stored_window_height := 0;
+		
+out rules {
+	true -> {
+		stored_window_reaction_torque := window.reaction_torque;
+		stored_window_height := window.height;
+	} --> {
+		windowSA.tau := - stored_window_reaction_torque;
+		windowSA.disp := stored_window_height * 100;
+	};
+}
+

+ 1 - 1
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_algebraic_loop_iteration_BASE.sa

@@ -4,7 +4,7 @@ import Controller_SA
 // this one could be joined with the one below, if we assume certain priorities in executing the rules
 semantic adaptation WindowSA window_sa
 at "./path/to/WindowSA.fmu"
-for fmu window
+for fmu Window window
 out rules {
 	true -> { } --> { reaction_torque := -reaction_torque; };
 }

+ 0 - 76
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_controller_delay_BASE.sa

@@ -1,76 +0,0 @@
-import PowerWindowModel
-
-module Controller_SA
-
-semantic adaptation ControllerSA controller_sa
-at "./path/to/ControllerSA.fmu"
-for fmu controller
-input ports armature_current -> obj_detected, passenger_up, passenger_down, driver_up, driver_down
-output ports up, down
-param REL_TOL := 0.0001;
-param ABS_TOL := 1e-8;
-param CROSSING := 5;
-param init_armature_current := CROSSING;
-param init_up := 0;
-param init_down := 0;
-control { // overwriting master! What to do in case of roll back? How to reuse generic algorithm
-	var step_size; // may be used to determine roll-back
-	if (signal == true or t >= internal_transition) {
-		step_size := do_step(controller, t, e+H); // do a step, then decide next internal transition
-	}
-	return step_size;
-}
-in var stored_armature_current := init_armature_current;
-in var internal_transition;
-in rules {
-	not is_set(internal_transition) -> { internal_transition := get_next_time_step(controller) + t; } --> { };
-	true -> {
-		obj_detected := false;
-		if (not (not is_close(stored_armature_current, CROSSING, REL_TOL, ABS_TOL) and stored_armature_current > CROSSING)
-					and (not is_close(armature_current, CROSSING, REL_TOL, ABS_TOL) and armature_current > CROSSING)) { // crossing, but not within tolerance
-			var negative_value := stored_armature_current - CROSSING;
-			var positive_value := armature_current - CROSSING;
-			var new_step_size := (H * (- negative_value)) / (positive_value - negative_value);
-			discard(new_step_size);
-		} else {
-			if (not (not is_close(stored_armature_current, CROSSING, REL_TOL, ABS_TOL) and stored_armature_current > CROSSING)
-						and is_close(armature_current, CROSSING, REL_TOL, ABS_TOL)) { // crossing within tolerance found
-				obj_detected := true;
-			}
-		}
-		stored_armature_current := armature_current;
-	} --> { };
-	
-}
-out var stored_up := init_up;
-out var stored_down := init_down;
-out rules {
-	true -> { internal_transition := get_next_time_step(controller) + t; } --> {};
-	up == true -> { up := 1; } --> { };
-	up == false -> { } --> { };
-	down == true -> { down := 1; } --> { };
-	down == false -> { } --> { };
-	stop == true -> { up := 0; down := 0; } --> { };
-	stop == false -> { } --> { };
-	true -> { up := stored_up; stored_up := up; } --> { };
-	true -> { down := stored_down; stored_down := down; } --> { }; 
-}
-
-
-// other suggestion for implementing get_next_time_step, making it easier to generate baseDSL code
-/*control { // overwriting master! What to do in case of roll back? How to reuse generic algorithm
-       var step_size; // may be used to determine roll-back
-       if (signal == true or t >= internal_transition) {
-             step_size := do_step(controller, e+H); // do a step, then decide next internal transition
-       }
-       return step_size;
-}
-in var internal_transition;
-in rules {
-       not is_set(internal_transition) -> {
-             if (not is_set(internal_transition)) {
-                    internal_transition := get_next_step(controller) + t;
-              }
-       } --> { internal_transition := get_next_step(controller) + t; };
-}*/
-

+ 0 - 41
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/input/powerwindow_multi_rate_BASE.sa

@@ -1,41 +0,0 @@
-import PowerWindowModel
-
-semantic adaptation WindowSA window_sa
-at "./path/to/WindowSA.fmu"
-for fmu window
-out rules {
-	true -> { } --> { reaction_torque := -reaction_torque; };
-}
-
-semantic adaptation WindowObstacleSALoop window_obstacle_sa_loop
-at "./path/to/WindowObstacleSALoop.fmu"
-for fmu window_sa, obstacle
-// just for the sake of declaring this, look at algebraic loop iteration
-
-semantic adaptation WindowObstacleSAMultirate window_obstacle_sa_multirate //with master // multi-rate for window and object
-at "./path/to/WindowObstacleSAMultirate.fmu"
-for fmu window_obstacle_sa_loop
-input ports motor_speed
-output ports reaction_torque
-param init_motor_speed := 0;
-control {
-	var h_ := H/10;
-	var proposed_h := H;
-	for (var iter in 0 .. 10) {
-		var returned_h := do_step(window_obstacle_sa_loop, t, h_);
-		if (returned_h != h_) { // for backtracking
-			 proposed_h := iter*h_ + returned_h;
-		}
-	}
-	return proposed_h;
-}
-in var stored_motor_speed := init_motor_speed;
-in var linear_increment;
-in rules {
-	true -> {
-		linear_increment := (motor_speed - stored_motor_speed) / 10;
-		stored_motor_speed := motor_speed;
-	} --> {
-		motor_speed := motor_speed + linear_increment;
-	};
-}

+ 11 - 10
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/src/be/uantwerpen/ansymo/semanticadaptation/tests/SemanticAdaptationGeneratorTest.xtend

@@ -10,6 +10,7 @@ import java.io.File
 import org.eclipse.xtext.testing.XtextRunner
 import org.eclipse.xtext.testing.InjectWith
 import org.eclipse.xtext.xbase.testing.CompilationTestHelper
+import org.junit.Ignore
 
 @RunWith(XtextRunner)
 @InjectWith(SemanticAdaptationInjectorProvider)
@@ -17,16 +18,16 @@ class SemanticAdaptationGeneratorTest extends AbstractSemanticAdaptationTest{
 	
 	@Inject extension CompilationTestHelper
 	
-	//@Test def powerwindow_model_only() { __generate('input/powerwindow_model_only.sa') }
-	@Test def powerwindow_algebraic_loop_delay_BASE() { __generate('input/powerwindow_algebraic_loop_delay_BASE.sa') }
-	//@Test def powerwindow_algebraic_loop_delay() { __generate('input/powerwindow_algebraic_loop_delay.sa') }
-	@Test def powerwindow_algebraic_loop_iteration_BASE() { __generate('input/powerwindow_algebraic_loop_iteration_BASE.sa') }
-	//@Test def powerwindow_algebraic_loop_iteration() { __generate('input/powerwindow_algebraic_loop_iteration.sa') }
-	//@Test def powerwindow_controller_delay() { __generate('input/powerwindow_controller_delay.sa') }
-	@Test def powerwindow_controller_delay_BASE() { __generate('input/powerwindow_controller_delay_BASE.sa') }
-	//@Test def powerwindow_multi_rate() { __generate('input/powerwindow_multi_rate.sa') }
-	@Test def powerwindow_multi_rate_BASE() { __generate('input/powerwindow_multi_rate_BASE.sa') }
-	//@Test def powerwindow() { __generate('input/powerwindow.sa') }
+	@Ignore @Test def powerwindow_model_only() { __generate('input/powerwindow_model_only.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_delay_BASE() { __generate('input/powerwindow_algebraic_loop_delay_BASE.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_delay() { __generate('input/powerwindow_algebraic_loop_delay.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_iteration_BASE() { __generate('input/powerwindow_algebraic_loop_iteration_BASE.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_iteration() { __generate('input/powerwindow_algebraic_loop_iteration.sa') }
+	@Ignore @Test def powerwindow_controller_delay() { __generate('input/powerwindow_controller_delay.sa') }
+	@Ignore @Test def powerwindow_controller_delay_BASE() { __generate('input/powerwindow_controller_delay_BASE.sa') }
+	@Ignore @Test def powerwindow_multi_rate() { __generate('input/powerwindow_multi_rate.sa') }
+	@Ignore @Test def powerwindow_multi_rate_BASE() { __generate('input/powerwindow_multi_rate_BASE.sa') }
+	@Ignore @Test def powerwindow() { __generate('input/powerwindow.sa') }
 	
 	def void __generate(String filename) {
 		val f = new File(filename)

+ 11 - 11
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation.tests/src/be/uantwerpen/ansymo/semanticadaptation/tests/SemanticAdaptationParsingTest.xtend

@@ -35,17 +35,17 @@ class SemanticAdaptationParsingTest extends AbstractSemanticAdaptationTest{
 //		print_ast(root)
 //	}
 
-	@Test def powerwindow_model_only() { __parseNoErrors('input/powerwindow_model_only.sa') }
-	@Test def powerwindow_algebraic_loop_delay_BASE() { __parseNoErrors('input/powerwindow_algebraic_loop_delay_BASE.sa') }
-	@Test def powerwindow_algebraic_loop_delay() { __parseNoErrors('input/powerwindow_algebraic_loop_delay.sa') }
-	@Test def powerwindow_algebraic_loop_iteration_BASE() { __parseNoErrors('input/powerwindow_algebraic_loop_iteration_BASE.sa') }
-	@Test def powerwindow_algebraic_loop_iteration() { __parseNoErrors('input/powerwindow_algebraic_loop_iteration.sa') }
-	@Test def powerwindow_controller_delay() { __parseNoErrors('input/powerwindow_controller_delay.sa') }
-	@Ignore @Test def powerwindow_controller_delay_BASE() { __parseNoErrors('input/powerwindow_controller_delay_BASE.sa') }
-	@Test def powerwindow_multi_rate() { __parseNoErrors('input/powerwindow_multi_rate.sa') }
-	@Ignore @Test def powerwindow_multi_rate_BASE() { __parseNoErrors('input/powerwindow_multi_rate_BASE.sa') }
-	@Test def powerwindow() { __parseNoErrors('input/powerwindow.sa') }
-	@Test def powerwindow_inline() { __parseNoErrors('input/powerwindow_inline.sa') }
+	@Test def power_window__window_sa() { __parseNoErrors('input/power_window_case_study/window_sa.BASE.sa') }
+	@Test def power_window__window_sa_canonical() { __parseNoErrors('input/power_window_case_study/window_sa_canonical.BASE.sa') }
+	@Ignore @Test def powerwindow_model_only() { __parseNoErrors('input/powerwindow_model_only.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_delay_BASE() { __parseNoErrors('input/powerwindow_algebraic_loop_delay_BASE.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_delay() { __parseNoErrors('input/powerwindow_algebraic_loop_delay.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_iteration_BASE() { __parseNoErrors('input/powerwindow_algebraic_loop_iteration_BASE.sa') }
+	@Ignore @Test def powerwindow_algebraic_loop_iteration() { __parseNoErrors('input/powerwindow_algebraic_loop_iteration.sa') }
+	@Ignore @Test def powerwindow_controller_delay() { __parseNoErrors('input/powerwindow_controller_delay.sa') }
+	@Ignore @Test def powerwindow_multi_rate() { __parseNoErrors('input/powerwindow_multi_rate.sa') }
+	@Ignore @Test def powerwindow() { __parseNoErrors('input/powerwindow.sa') }
+	@Ignore @Test def powerwindow_inline() { __parseNoErrors('input/powerwindow_inline.sa') }
 	
 	def __parseNoErrors(String filename) {
 		val root = __parse(filename)

+ 0 - 54
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/controller_sa_BASE_proposed_claudio.sa

@@ -1,54 +0,0 @@
-// If the control rules block is defined, then the generic master will not be used. So the code in the block has to ensure that FMUs are run and synchronized correctly. If the block is not defined, then the generic master will be used.
-control rules {
-	// This block gets executed whenever there is a call to doStep of the adapted FMU.
-	var step_size;
-	if ((t + H) >= next_internal_transition) {
-		// Set the last given inputs to the controller
-		controller.setValues("passenger_up", stored_passenger_up)
-		...
-		controller.setValues("driver_stop", stored_driver_stop)
-		
-		step_size := controller.do_step(last_transition_time, (t+H) - last_transition_time); // do a step, then decide next internal transition
-		last_transition_time := t + H
-		next_internal_transition := NULL // reset this to null, so that it will be executed when the next input is given.
-	}
-	return step_size; // For this adaptation, it should never be the case that  step_size < (t+H) - last_transition_time
-}
-
-// Any in or state variable declared at the global level will be part of the state of the adapted FMU, so that rollback can work.
-in var next_internal_transition;
-in var last_transition_time;
-in var stored_passenger_up;
-...
-in var stored_driver_stop;
-// The state of the adapted FMU also includes the aggregation of the states of each original FMU, plus the previous inputs fed to them (this last bit is explained in the hierarchical co-simulation section)
-
-in rules {
-	// This block is run when the setValues function of the adapted FMU is called.
-	// each rule is tried in order and the first one evaluating to true gets executed.
-	not is_set(next_internal_transition) -> {
-		// This block gets executed when the above condition is evaluated to true.
-		next_internal_transition := controller.getMaxStepSize() + t;
-	} --> {
-		// This block is executed whenever the doStep of the adapted FMU is run.
-		// Following its execution, the control rules block will be executed.
-		// If there is no control rules block, this block will still be executed before the generic master is executed, with the inputs being set directly from the inputs to the outputs.
-		// Maybe setting any input port in this block will prevent the generic master from reseting that input port (this has some nuances that need to be investigated)
-		// Nothing to do here.
-	};
-	is_set(next_internal_transition) -> {
-		// Store the inputs to the controller
-		stored_passenger_up := passenger_up;
-		...
-		stored_driver_stop := driver_stop;
-	}
-}
-
-out rules{
-	// These rules are evaluated when a getValues function is called
-	true -> {
-		// This block is executed at the end of the control rules block, or at the end of the execution of a single step of the generic master (in case there is no control rules block)
-	} --> {
-		// This block is executed when there is a call to getValues to the adapted FMU.
-	}
-}

+ 0 - 61
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/powerwindow_controller_delay_BASE.sa

@@ -1,61 +0,0 @@
-import PowerWindowModel
-
-module Controller_SA
-
-semantic adaptation controller_sa
-for fmu controller
-input ports armature_current -> obj_detected, passenger_up, passenger_down, driver_up, driver_down
-output ports up, down
-param REL_TOL = 0.0001;
-param ABS_TOL = 1e-8;
-param CROSSING = 5;
-param init_armature_current = CROSSING;
-param init_up = 0;
-param init_down = 0;
-control var internal_transition;
-control rules { // overwriting master! What to do in case of roll back? How to reuse generic algorithm
-	if (not is_set(internal_transition)) { // only at start of simulation
-		var state := get_state(controller);
-		internal_transition := do_step(controller, MAX) + t; // may return internal transition time or MAX
-		set_state(controller, state);
-	}
-	var step_size; // may be used to determine roll-back
-	if (signal == true or t >= internal_transition) {
-		step_size := do_step(controller, H); // do a step, then decide next internal transition
-		var state := get_state(controller);
-		internal_transition := do_step(controller, MAX) + t;
-		set_state(controller, state);
-	}
-	return step_size;
-}
-in var stored_armature_current := init_armature_current;
-in rules {
-	true -> {
-		obj_detected := false;
-		if (not (not is_close(stored_armature_current, CROSSING, REL_TOL, ABS_TOL) and stored_armature_current > CROSSING)
-					and (not is_close(armature_current, CROSSING, REL_TOL, ABS_TOL) and armature_current > CROSSING)) { // crossing, but not within tolerance
-			var negative_value := stored_armature_current - CROSSING;
-			var positive_value := armature_current - CROSSING;
-			var new_step_size := (H * (- negative_value)) / (positive_value - negative_value);
-			discard(new_step_size);
-		} else {
-			if (not (not is_close(stored_armature_current, CROSSING, REL_TOL, ABS_TOL) and stored_armature_current > CROSSING)
-						and is_close(armature_current, CROSSING, REL_TOL, ABS_TOL)) { // crossing within tolerance found
-				obj_detected := true;
-			}
-		}
-		stored_armature_current := armature_current;
-	} --> { };
-}
-out var stored_up := init_up;
-out var stored_down := init_down;
-out rules {
-	up == true -> { up := 1; } --> { };
-	otherwise up -> { } --> { };
-	down == true -> { down := 1; } --> { };
-	otherwise down -> { } --> { };
-	stop == true -> { up := 0; down := 0; } --> { };
-	otherwise stop -> { } --> { };
-	true -> { up := stored_up; stored_up := up; } --> { };
-	true -> { down := stored_down; stored_down := down; } --> { }; 
-}

+ 0 - 185
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle.BASE.sa

@@ -1,185 +0,0 @@
-import ../powerwindow_model_only.sa
-
-module WindowObstacleSA
-
-semantic adaptation window_obstacle_sa
-
-for fmu window, 
-		obstacle;
-
-param RATE = 10;
-param init_displacement = 10;
-
-var previous_displacement := init_armature_current;
-var stored_displacement := init_displacement;
-var stored_speed := init_speed;
-
-out rules {
-	true -> {
-		stored_armature_current := armature_current;
-		stored_displacement := displacement;
-		stored_speed := speed;
-	} --> {
-		speed := stored_speed;
-		displacement := stored_displacement;
-		armature_current := stored_armature_current;
-	}; 
-}
-
-import PowerWindowModel
-
-/*
-Declares the name of the module. 
-Any importing document can refer to any of the declarations in this document by, e.g., Controller_SA.controller_sa (refers to the adapted FMU created by the code in this page)
-*/
-module Controller_SA
-
-/*
-Declares the name of the adapted FMU.
-The resulting FMU will probably have a name that is something like "Controller_SA.controller_sa".
-There may be extra information required for an appropriate generation of the adapted FMU, so we may have to add extra declarations here.
-I'm thinking of things such as company, documentation, etc...
-For now, this is fine.
-*/
-semantic adaptation controller_sa
-
-/*
-Declares the set of original FMUs to be adapted.
-The names of the original FMU have to be the fully qualified names, that is, Module_Full_Name.FMU_Name.
-*/
-for fmu PowerWindowModel.controller
-
-/*
-Declare the input ports of the adapted FMU.
-Previously, there was a connection "armature_current -> object_detected", but that connection is no longer used, since the port object_detected is set explicitly in the code.
-If these are ommited, then any input port that is not connected in the set of original FMUs declared above, will be assumed to be an input port of the adapted FMU.
-In this later case, there may be ports with the same name, so for the code generation, the output ports of the adapted FMU need to be unique (maybe some prefix should be used).
-*/
-input ports armature_current, 
-			passenger_up, 
-			passenger_down, 
-			driver_up, 
-			driver_down;
-
-/*
-Declares the output ports of the adapted FMU.
-If no ports are declared, then it is assumed that the output ports are the same as the union of the output ports of the connected FMUs.
-The same remarks apply to the uniqueness of the output ports in the adapted FMU.
-*/
-output ports up, down;
-
-/*
-Declares the parameters in the model.
-These will be just constants in the generated code, so they have to be resolved at compile time.
-*/
-param REL_TOL = 0.0001;
-param ABS_TOL = 1e-8;
-param CROSSING = 5;
-param init_armature_current = CROSSING;
-param init_up = 0;
-param init_down = 0;
-
-/*
-Declare state variables.
-These are variables that are apart of the state of the adapted FMU.
-It is important to know them because the rollback support should be provided automatically.
-*/
-var internal_transition;
-var stored_armature_current := init_armature_current;
-var stored_up := init_up;
-var stored_down := init_down;
-/*
-Previously variables were declared as:
-control var internal_transition;
-But, to the best of my knowledge, I don't see the utility of the control var (or the in vars.)
-What's their difference to "in var"
-Are they only available in the control rules block?
-But the in vars are also available in the control rules block...
-So I propose to remove the control/in/out qualifiers, and just assume that any var declared at the global level, will be part of the state.
-What were the arguments to having a distinction between the vars?
-*/
-
-/*
-Declares control block.
-Before it was called control rules, but I suggest just calling it control, because there are no rules. 
-To my understanding, it is called whenever there is a doStep on the adapted FMU.
-If the control rules block is defined, then the generic master will not be used. 
-So the code in the block has to ensure that FMUs are run and synchronized correctly. 
-If the control block is not defined, then the generic master will be used.
-The other blocks (in, out, and so on) will still be executed, even if there is no control rules block.
-*/
-control {
-	var step_size;
-	...
-	return step_size;
-}
-
-/*
-This block is run when the setValues function of the adapted FMU is called.
-*/
-in rules {
-	/*
-	Each of the conditions below are evaluated in order and the first one to evaluate to true is selected.
-	Ambiguity: are all conditions evaluated always, or do we stop at the first one?
-	Assuming there are no side effects, it seems more efficient to stop the first that evals to true.
-	*/
-
-	condition1 -> {
-		/*
-		This block is run when doStep of the adapted FMU is called, and condition1 evals to true.
-		Notice that multiple calls to the setValues function can be made before calling doStep, so these blocks may be run several times. 
-		They should therefore not include counters, or stuff like that depends on the number of calls made by setValues before calling doStep.
-		*/
-	} --> {
-		/*
-		I'm still not sure of the conditions that make this block run.
-		Possible interpretations:
-			- This block runs immediately before the control block is used.
-				Problems: Its pretty much useless for multi-rate adaptations, where the control block may run the internal FMUs multiple times. In those intemediate setValue and doStep calls, the control block code would still have to make the interpolation work. This also violates the data/control separation.
-				Good things: If there is no control rules block, the generic master algorithm would be used, so this interpretation is fine.
-			- This block is called by an explicit instruction within the control rules block.
-				Problems: I cannot think of any right now.
-				Good things: It allows multi-rate adaptation to be done in a somewhat flexible manner.
-		Regardless of the possible interpretations, there is still the problem of how to resolve multiple instructions.
-		What kind of instructions are allowed here?
-		Certainly, when the control rules calls this block, which instructions should be executed? 
-		It may not make sense to execute all of them, if the control just wants to compute one value...
-		
-		Another pitfall of this block is the following scenario: suppose setValue of the FMU is called twice before the doStep is called.
-			In addition, suppose that two different rules were evaluated in each call.
-			Then, when the control rules is executed, the update_in block of the most recently evaluated rule should be the one used, right?
-		*/
-		original_fmu1_input := expression1
-		original_fmu2_input := expression2
-	};
-
-	condition2 -> {
-		in_block2
-	} --> { update_in_block2 };
-	
-	...
-}
-
-out rules {
-	/*
-	This block is run when the control rules block has values to be propagated to the state of the adapted FMU.
-	The same alternative interpretations identified before apply to this block: when should it be called?
-	If the control block is doing a multi-rate adaptation, it makes no sense to call this block at everypoint.
-	We are only interested in getting values at the end of the multi-rate adaptation iteration (or am I missing something?).
-	So, similarly to the previous case, I suggest that there is a function call, that can be used to invoke this block.
-	When there is no control block defined, then this block is called simply at the end of the co-simulation step of the internal generic master.
-	
-	If the control block calls this block multiple times, and multiple rules are selected at each time, then the must recently selected rule will be applied.
-	Do you agree with this?
-	*/
-	
-	condition1 -> {
-		/*
-		This block is run when condition1 is evaluated to true.
-		*/
-	} --> {
-		/*
-		This block is run when getValues is called on the adapted FMU, and the block above was the most recently executed block.
-		*/
-	}; 
-}

+ 0 - 36
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle_sa_loop_BASE_proposed.sa

@@ -1,36 +0,0 @@
-semantic adaptation window_obstacle_sa_loop
-for fmu window_sa, obstacle
-input ports motor_speed
-output ports reaction_torque
-param MAXITER = 100;
-param REL_TOL = 1e-8;
-param ABS_TOL = 1e-8;
-initial state {
-	
-}
-control rules {
-	var reaction_force;
-	var height := window_sa.get("height")
-	var prev_height := height
-	var window_state, obstacle_state;
-	for (var iter in 0 .. MAXITER) {
-		window_state := window_sa.getState()
-		obstacle_state := obstacle.getState()
-		obstacle.set("height", height)
-		obstacle.doStep(t, H)
-		reaction_force := obstacle.get("reaction_force")
-		window_sa.set("reaction_force", reaction_force)
-		window_sa.doStep(t, H)
-		height := window_sa.get("height")
-		if (is_close(prev_height, height, REL_TOL, ABS_TOL)) {
-			break;
-		} else {
-			prev_height := height;
-			obstacle.setState(obstacle_state);
-			window_sa.setState(window_state);
-		}
-	}
-}
-in rules {
-	true ->	{ } --> { window_sa.set("reaction_force", f(in_state)) };
-} 

+ 0 - 22
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/examples/old/window_obstacle_sa_multirate_BASE_proposed_claudio.sa

@@ -1,22 +0,0 @@
-semantic adaptation window_obstacle_sa_multirate
-for fmu window_obstacle_sa_loop
-input ports motor_speed
-output ports reaction_torque
-param init_motor_speed = 0;
-control rules {
-	// motor_speed is being set by the other rule.
-	var h := H/10
-	for (var iter in 0 .. 10) {
-		window_obstacle_sa_loop.doStep(h)
-	}
-}
-in var stored_motor_speed := init_motor_speed;
-in var linear_increment;
-in rules {
-	true -> {
-		linear_increment := (motor_speed - stored_motor_speed) / 10;
-		stored_motor_speed := motor_speed;
-	} --> {
-		motor_speed := motor_speed + linear_increment;
-	};
-}

+ 14 - 3
DSL_SemanticAdaptation/be.uantwerpen.ansymo.semanticadaptation/src/be/uantwerpen/ansymo/semanticadaptation/SemanticAdaptation.xtext

@@ -229,10 +229,21 @@ FunctionDeclaration:
 	'{' statements+=Statement* returnstatement=ReturnStatement '}';
 
 Declaration:
-	'var' name=ID (':=' expr=Expression)? ';';
+//	'var' name=ID (':=' expr=Expression)? ';';
+	'var' declarations+=SingleVarDeclaration ("," declarations+=SingleVarDeclaration)* ';'
+;
+SingleVarDeclaration:
+	name=ID (':=' expr=Expression)?
+;
 
 ParamDeclaration:
-	'param' name=ID ':=' expr=Expression ';';
+	//'param' name=ID ':=' expr=Expression ';';
+	'param' declarations+=SingleParamDeclaration ("," declarations+=SingleParamDeclaration)* ';'
+;
+
+SingleParamDeclaration:
+	name=ID ':=' expr=Expression ';'
+;
 
 ReturnStatement:
 	'return' Expression ';';
@@ -247,7 +258,7 @@ DeclaredParameter:
 //	Port | ParamDeclaration | Declaration | DeclaredParameter | FunctionDeclaration;
 
 LValueDeclaration: // can contain overlapping elements as long as it is only used as reference
-	Port | ParamDeclaration | Declaration | DeclaredParameter;
+	Port | SingleParamDeclaration | SingleVarDeclaration | DeclaredParameter;
 
 Assignment:
 	lvalue=Variable ':=' expr=Expression; // TODO: to what can be assigned? only local vars?