AS (ATJ) Specifications and testing requirements for passing iterations 1A, 1B, 2, 3A and 3B

Project: develop control software for the person lift according to specifications

Purpose of this document Lecture slides have extensive information about how the control software is developed This document has a subset of that information needed for passing the project: –Specifications for each iteration –Testing requirements for each iteration Lecture slides explain the process of moving from machine-level requirements to the tested product (required for exam) This document assumes that you have gone through the tutorial in Noppa

How creative can you be in the design? Lecture slides provide the architecture design and leave the detailed design to you However, you can do totally your own architecture based on the specifications is this document as long as you present the tests listed in this document –Recommended only for experienced developers who want to do things their own way Teachers are available to help in problem situations only if you follow the main architectural decisions presented in the lecture slides

Demo interviews When you demonstrate each iteration, we interview you about the maintainability, scalability and reusability implications of your design decisions If you did not follow the architecture in the lecture slides, that is fine, but be ready for this discussion Even if you followed the lecture slides, there is no one correct solution

Test coverage Test coverage is a measure of the degree to which the source code of a program has been tested Good test design gives maximum coverage with minimum number of tests You do not need to use the exact test inputs as presented here, but you must provide similar coverage!

Example of coverage Pressing button for automatic movement drives platform to stored height If current height is less than stored height, platform is driven up –Else, platform is driven down Driving up and driving down involve different sections of code If our test involves driving up once and driving down once, but you present a test that just drives down twice, we will ask you to update the test

Iterations 1A and 1B - Moving the platform manually from the platform - Control place selection - Joystick mode selection

Iterations 1A and 1B Functions: –Moving the platform manually from the platform –Control place selection –Joystick mode selection Tests for iteration 1A require only movement in vertical direction Tests for 1B require that you have both vertical and horizontal movement working

Control place selection A/D InterfaceSignal nameInterpretation boolControl_place_selection0=chassis 1=platform 10 Description: The function either enables the controls on the platform or the chassis (e.g. joystick is on platform). This status information is used to enable or disable other functions (e.g. functions using joystick are disabled if chassis has been selected.) Triggering event: Value of “Control_place_selection” signal changes States in which enabled: All

Joystick mode selection A/D InterfaceSignal nameInterpretation boolJoystick_mode0=moving platform 1=transfer 11 Description: The function toggles the system state between “moving_platform” or “transfer” (driving with wheels) as described in the table. This status information is used to enable or disable other functions (e.g. Moving platform is disabled in transfer mode) Triggering event: Change in value of Joystick_mode signal States in which enabled: control place is platform

Moving the platform manually from the platform A/D (or D/A) Interface Signal nameScalingRangeInterpretation BoolJoystick_center_p osition [0,1]0 = not in center 1 = center position 16-bit ( ) Joystick_up_down0 -> > 1 [-1..1]-1=extreme position down 0=center 1=extreme position up Joystick_left_right-1=extreme position left 0=center 1=extreme position right Up_actuate0 -> 0 1 -> [ ] 0=proportional valve closed 65535=proportional valve fully open Down_actuate Left_actuate Right_actuate 12 Use double in Simulink for 16-bit signals

Moving the platform manually from the platform (In terms of scaled signal values) Description: see tables Safe state: DA = 0; UA = 0; LA = 0; RA = 0 Triggering event: JUD != 0 OR JLR != 0 States in which enabled: control place is platform and joystick mode is moving platform. If disabled, go to safe state. 13 Joystick_up_down (JUD)Down_actuate (DA)Up_actuate (UA) [-1, 0][0, 1] DA = -1 * JUD0 [0, 1]0[0,1] UA = JUD Joystick_left_right (JLR)Left_actuate (LA)Right_actuate (RA) [-1, 0][0, 1] LA = -1 * JLR0 [0, 1]0[0,1] RA = JLR

Test signal You need to create the ”Joystick_up_down” and ”Joystick_center_position” signals for testing Latter is true when former is within some tolerance of the center value

There is only one test for iteration 1A (next 2 slides)

Behavior when place=platform and mode=moving 16 Curving is due to joystick being gradually pushed up Zoomed in version on next slide

Observe behavior close to center position 17 Center value of Joystick_up_down=32768 Joystick_center_position activates at a reasonable time (test block works) Height does not change when center_position is true (note the zoom: Platform_height x10^-4) Height starts increasing immediately when center_position =0 (correct: simulator does not model inertia)

Tests for iteration 1B

First, test horizontal movement just like vertical movement was tested in 1A 19

Further testing To improve coverage, we try: –Movement with different tempo –Moving joystick into both directions, and –Crossing center position several times from both directions 20

Using a sine wave as the test input 21 Here the stick passes below the center position of the Y-direction and platform starts moving down. Stick is now above center of Y-direction and platform starts moving up. What if joystick movement is reversed before platform reaches extreme position? Next slide.

Previous test with a lower sine amplitude: platform does not reach extreme position 22 Movement of platform is reversed immediately when joystick crosses center. Correct, because simulator does not model inertia.

Iteraatio 1B demo exercise (scenario) 23 System engineer wants to distribute the software: Joystick signal processing Forming cylinder actuation signals For safety reasons, center_position signal should be sent separately over the network. This guards against corruption of network messages.

1B demo task Modify the software so that Joystick_center_position is processed in the module that creates the Up/Down/Left/Right_actuate signals Then rerun all the earlier tests Check the next slide before starting

Hint for demo exercise Create a block “Forced_Off_Interlock” : Inputs: –Signal_In (double) –Forced_off (boolean) Output: –Signal_Out (double) Behavior: –Forced_off TRUE => Signal_Out:=0 –Forced_off FALSE => Signal_Out:=Signal_In This block will be needed in the later iterations

Iteration 2 - Cylinder limit protection

Cylinder limit protection A/D D/A interface Signal nameScaleRangeInterpretation bool Left_limit 0=extreme position of cylinder not detected 1=extreme position detected Right_limit Down_limit Up_limit 16 bit ( ) Up_actuate 0 -> > 1 [0..1]0=proportional valve closed 1=proportional valve fully open Down_actuate Left_actuate Right_actuate 27

Cylinder limit protection 28 Description: If Left_limit = 0, function does not activate If Left_limit = 1, Left_actuate is forced to zero even if another function gives other actuation signals. This is a safty function and has highest priority. Safe state: Left_actuate = 0 Triggering event: Left_limit = 1 States in which enabled: All Specifications for other signals: replace ”Left” with ”Right”, ”Down”, ”Up”

Same joystick ramp input as in iteration1 29 At upper limit up_actuate forced to zero At lower limit down_actuate forced to zero

Same sine input as in iteration 1B 30

Same low-amplitude sine input as in iteration 1B 31 Test shows that limit protection does not activate when it should not activate – important to test this!

Iteration 3A - Prevention of unintentional movement - Automatic driving to stored position

New input signals in iteration 3A A/DSignal_nameRangeScalingInterpretation boolQuick_height_A[0,1]0=not pressed 1=pressed Quick_height_B Enabling_switch 16-bit ( ) Height_sensor[0..1]0->0, >1 Height of platform from chassis 0=lowest position 1=highest position 33

Automatic driving to stored position Description: Current height can be stored by pressing the quick button A or B for longer than sys_param: quick_position_register_time (hardcode this parameter into your application). Each button can store a separate height. After this, the platform is driven to the stored height by pressing the button shortly and keeping the enabling switch pressed down. If enabling switch is released, manual control is resumed. Horizontal cylinder is not moved. Safe state: cylinders are stopped Triggering event: Button A or B is pressed States in which enabled: control place is platform and joystick mode is moving platform 34

Prevention of unintentional movement Description: Cylinders are not driven if enabling switch is not pressed, regardless of joystick position. Safe state: Cylinders are stopped Triggering event: Enabling switch is pressed States in which enabled: All 35

Joystick is moved gradually from down to up while pressing quick buttons 36 Store height A Reached A but enabling switch is pressed: Stay in auto mode Enabling switch released: start moving under manual control Drive to height A

Zoomed version of previous slide Focus on button B 37 First press takes 100 time steps Height is stored after pressing longer than the value in parameter “quick_position_register_time”. Here the value is 50. Reached stored position B When automatic driving is started, actuation signal goes to maximum (65535) Short press of button B interrupts Manual movement and starts automatic driving, which is done at maximum speed.

This time, the joystick is pulled down 38 Here we test upward driving with button A and downward driving with button B Opposite directions were tested in the previous test. This test increases coverage of the automatic movement logic

This time, we use the button A twice 39 E.g. there might be a bug that keeps using the first stored position Previous tests would not catch that

Iteration 3B - No new functionality - Update the design to group several signals to a single port and wire with buses - Then make sure that your the same tests as in iteration 3B still work

Before you begin Technical assistance on using bus objects is in the document Iter3B_Vinkkeja Lecture slides describe the design rationale in this iteration

New interface specification Use the following interfaces Lecture slides have one solution, but yours may be different, as long as you are ready to discuss its maintainability, scalability and reusability Bus objectSignals SenLimitExt_limit, Ret_limit UI_selectorsJoystick_mode, Quick_height_A, Quick_height_B, Control_place_selection UI_allselectors (of type UI_selectors), Enabling_switch, Joystick_center_position