GLO Ltd presents StateLogics

1. GLO LtdpresentsStateLogics

2. Who we are • UK Domiciled Company • 4 Employees • Ian Fagg – principal consultant • Bill Pearson - technical lead • Michael Tanaka - operations, marketing • Pat Togia – hci specialist • Patents Pending • Smart Grant for innovation awarded • Privately Funded

3. What we’ve got • Solution for coding state behaviour • Elegant and transparent • Uses standard C and C macros • Minimal runtime memory and processing

4. What you’ve got • Expertise in software technologies • Domain knowledge of Embedded and Reactive systems • Access to our development partners • An interest in new technologies

5. Objectives • Demonstrate, share detail, answer questions • Get your feedback on any aspect • Take away some concrete steps

6. Pwr Low Pwr Low Recharged Finding Empty Litter Recharge Batteries Empty Pwr Low Pwr Low Picked Up Picked Up Found Litter Arrived Arrived Go Dispose Pick Up Litter Full Pwr Low Pwr Low Pwr Low Pwr Low State Transition Diagram • A State Transition Diagram (STD) showing the states of LitterBot and associated transitions • The system is always in one state, lets start with Finding • An event determine & initiates a transitions, dependant on the current state • If Litterbot runs out of power, all original states transition to Go Charge Finding Found Litter Pick Up Litter Go Charge Go Charge

7. Coding state as a FSM • Traditional implementation • State X Event matrix (big memory cost) or • Switch (Case) statements (execution cost) • Neither is easy to debug or enhance • StateLogics • Declare states and transitions in C • Call the state machine the events

8. The problem with FSMs • Atomic states – lots of them • No explicit structure in or among states • But real machines do have structure • Each state implies many real machine conditions • An event may be indifferent to many detailed conditions • A transition may leave many conditions unchanged

9. Pwr Low Recharged Collecting Empty Recharged Recharged Pwr Low Picked Up Found Litter Arrived Pwr Low Pwr Low Full Pwr Low Pwr Low State Charts Simplify • Hierarchy wraps indifferent detail states • The Collecting (litter) wraps up the four lower level states. Now a single Power low transition suffices. • Finding is the initial state within Collecting, started whenever Collecting is entered, in this instance by Recharged. • This introduces hierarchy which is widely understood manage complexity Finding Empty Litter Recharge Batteries Arrived Pick Up Litter Go Dispose Go Charge

10. Operating Operating Advancing Advancing Collecting Collecting Finding Empty Litter Recharge Batteries Finding Empty Litter Recharge Batteries Empty Empty Recharged Recharged Picked Up Picked Up Found Litter Arrived Arrived Arrived Found Litter Arrived Pick Up Litter Go Dispose Go Charge Pick Up Litter Go Dispose Go Charge Pwr Low Pwr Low Full Full State Charts Simplify • Parallelism expresses permutations • To find & dispose of litter and charge itself, LitterBot needs to move around searching until it receives a change of target • This parallel behaviour is now labelled Advancing and separated from the original behaviour, Operating, by a dotted line • Initial states are defined and Active becomes the superstate Active Stopped Arrived To To Moving

11. Recharge Bat Moving Recharge Bat Moving Empty Litter Moving Empty Litter Moving But why? Take it back to STD • Complexity and Multiplicity become a problem • Multiply out all permutations of states • Label all transitions…and you have an unrecognisable mess , then eliminate any invalid states Pick up litter Stopped Finding Moving Finding Stopped Pick up litter Moving Recharge Bat Stopped Go Charge Stopped Go Charge Moving Empty Litter Stopped Go Dispose Stopped Go Dispose Moving

12. Belly Up Lost Traction Righted Collecting Collecting Finding Empty Litter Recharge Batteries Finding Empty Litter Recharge Batteries Empty Empty Recharged Recharged Picked Up Picked Up Found Litter Found Litter Arrived Arrived Arrived Arrived Pick Up Litter Go Dispose Go Charge Pick Up Litter Go Dispose Go Charge Pwr Low Pwr Low Full Full Extend the Statechart • Add new behaviour without adding complexity • Consider when Litterbot loses its traction or falls over • This situation is easily modeled with an external state called Belly Up Active Operating Advancing Stopped Arrived To To Moving

13. Belly Up …the STD is a mess • What was once complex becomes • Untenable (even without the labels!) Pick up litter Stopped Finding Moving Finding Stopped Pick up litter Moving Recharge Bat Stopped Go Charge Stopped Go Charge Moving Empty Litter Stopped Go Dispose Stopped Go Dispose Moving

14. Statechart benefits over STD • Hierarchy • Scopes and simplifies transitions • Easy to add behaviour • Parallel • Add parallel threads without disturbing original specification • Result remains comprehensible and elegant. • Best possible fit to problem form • Intuitive understanding of the abstract design • Aids in traceability between the model and reality So how do we implement State Charts?

15. Active Operating Advancing Litterbot Litterbot Active Righted Righted Traction Lost Traction Lost Operating Operating Advancing Advancing To To Collecting Litter Charged Charged Arrived Arrived To To Arrived Arrived Power Low Power Low Found Found Full Full Arrived Arrived Done Done Finding Finding Hierarchy of states • State charts represent an extended hierarchy of parallel as well as exclusive branches • The tree represents the structure of the state chart with Litterbot at the top • Active is the container for two parallel behaviours – Operating and Advancing • Litterbot, Operating, Advancing and Collection Litter all have exclusive sub-states or branches • Let’s not forget the transitions! • The event Arrived can be handled in three distinct places within the tree • The implementation matches the event to the current state and determines what should happen next. Belly Up Go Charge Recharge Batteries Collecting Litter Stopped Moving Finding Pick Up Litter Go Dispose Empty Litter

16. Belly Up Lost Traction Lost Traction Righted Operating Operating Advancing Advancing Collecting Collecting Recharged Empty Empty Arrived To To Full Pwr Low Pwr Low An example –Pwr Low • Litterbot is currently Stopped and Emptying Litter • There 2 active states , 4 active parentstates and 4 transitions possible Active Active Finding Empty Litter Recharge Batteries Stopped Picked Up Found Litter Arrived Arrived To Pick Up Litter Go Dispose Go Charge Moving

17. Litterbot Litterbot Belly Up Belly Up Active Active Righted Righted Traction Lost Traction Lost Operating Operating Advancing Advancing To To To To Go Charge Go Charge Recharge Batteries Recharge Batteries Collecting Litter Collecting Litter Stopped Stopped Moving Moving Charged Charged Arrived Arrived To To To To Arrived Arrived Power Low Power Low Finding Finding Pick Up Litter Pick Up Litter Go Dispose Go Dispose Empty Litter Empty Litter Found Found Full Full Arrived Arrived Arrived Arrived Done Done Finding Finding Hierarchical transformation • The current state is a hierarchical marking of the tree • Valid events can occur at any one of 4 points • Pwr Low event matched to currently active state of Collecting Litter • Exit Actions must be executed up to the highest common state, Operating • Implementation must assert new hierarchial state and execute entry code

18. In Short • State based formalisms model dynamic systems • Such systems are ubiquitous and vital • State Charts transform State Diagrams • Analysis of complex systems becomes easy • State Charts are ideal for design, test and simulation • Direct execution, would lead to effortless implementation • State Chart execution is a complex problem • Find the appropriate transition, assert the new extended state • Multiple parallels, entry code, exit code to consider • Transition code execution on transitions • GLO has a proprietary solution that solves these problems

19. StateLogics • Solution for coding Statecharts • Hierarchic • Parallel • Elegant and transparent • Uses standard C and C macros • Minimal runtime memory and processing

20. State declaration Parameters expected by macro File generated by StateLogics. Declaration must include its header Parent state. Models hierarchy Macro. #include “statename_1.h” STATE(statename_1, fsm_a) char * my_string; int my_int; EVENTS ENTRY (statename_1 *me) {/*C-code_here*/} EXIT (statename_1 *me) {/*C-code_here*/} EVENT(ev_name_1)(statename_1 *me, int a, int b) TO(statename_x) {/*C-code here*/} EVENT(ev_name_2)(statename_1 *me, char * str_arg) TO(statename_y) {/*C-code here*/} ENDSTATE Code to execute on entering this state (entry code) Closes var declarations Standard C variable declarations Data carried by event Exit code Transition Transition code Closes state declaration More transition declarations

21. Here is how you use it Include once for system. Generated by StateLogicss Include in any file that uses the fsm. Generated by StateLogics #include “fsm_a_globals.h” #include “fsm_a.h” fsm_a * my_fsm; my_fsm = NEW_FSM_A (); // define driver loop (or whatever) to // call statemachine with an event, eg: ev_name_1 (my_fsm, 10, 37); … ev_name_2 (my_fsm, “a string”); Declare Instantiate • EVENT(ev_name_1)(statename_1 *me, int a, int b) TO(statename_x) {/*C-code here*/} Your usual driver loop / event queue Here this name refers to a macro defined in fsm_a.h, by StateLogicss pre-processor Find out current state and take correct transition, execute transition, exit and entry code

22. State declaration Parent state. Models hierarchy Macro for parallel state. All its siblings are Exclusive. #include “statename_1.h” (statename_1,parent) char * my_string; int my_int; EVENTS ENTRY (statename_1 *me) {/*C-code_here*/} EXIT (statename_1 *me) {/*C-code_here*/} EVENT(ev_name_1)(statename_1 *me, int a, int b) TO(statename_x) {/*C-code here*/} EVENT(ev_name_2)(statename_1 *me, char * str_arg) TO(statename_y) {/*C-code here*/} ENDSTATE ANDSTATE ORSTATE

23. Here is how you use it #include “chart_a_globals.h” #include “chart_a.h” chart_a * my_chart; my_chart = NEW_CHART_A (); // define driver loop (or whatever) to // call statemachine with an event, eg: ev_name_1 (my_chart, 10, 37); … ev_name_2 (my_chart, “a string”);

24. What gets generated C-source using macros C Compiler Header files defining macros Your Executable StateLogicss pre-processor Optionally Statechart

25. C you can see C-source with macros C Compiler Header files with macros Your Executable StateLogicss pre-processor After running pre-processor, you can take away header files and code and forget StateLogics.We do not alter your C – code. We just generate .h files you include. There is no runtime engine. Just C you can see. Optionally Statechart

26. RoamaBot Active Arrived event occurs in two places. Take to most specific valid transition. Home of parentvars Goal and Direction, set and read by its children and so on down Advancing Tracking A new goal may be imposed externally. This would interrupt both On track and Avoiding. Stopped Track position and direction OUT: Arrived Position (p) To (p) Arrived To (p) Maintains Last position and calculates Direction. Emits arrived event when current position coincides with Goal. Exit code for On track saves its goal in local variable. Entry code reasserts this goal in the parent variable shared with Track position. Moving On track Bumped (l, r) Arrived Entry code resets Goal to temporary goal, calculated by avoidance algorithm. Avoiding obstacle More bumps may intervene. Bumped (l, r)

27. RoamaBot Active We can easily extend the behaviour. Here Cease will quit from any state. Exit code will be executed all the way up the tree, stopping at RoamaBot itself. Advancing Tracking Stopped Track position and direction OUT: Arrived Position (p) To (p) Arrived To (p) Moving On track Cease Power save Start Bumped (l, r) Arrived Avoiding obstacle We could also expand Avoiding obstacle if we discover the need for more state behaviour. Bumped (l, r)

28. RoamaBot Active Advancing Tracking Stopped Track position and direction OUT: Arrived Position (p) To (p) Arrived To (p) Moving On track Cease Power save Start Bumped (l, r) Arrived Avoiding obstacle Here RoamaBot is busy avoiding an obstacle. The current (hierachic and parallel) state is marked in red. Valid transitions are blue, invalid ones greyed out. Bumped (l, r)

29. Old state New state RoamaBot RoamaBot Cease Power save Power save Active Active Tracking Advancing Tracking Advancing Stopped Track position and direction Moving Stopped Track position and direction Moving On Track Avoiding obstacle On Track Avoiding obstacle

30. Same implementation for • FSMs • Statecharts And … … • OO • Do you want to inherit and specialise state behaviour?

31. temporal specialisation OO with States

32. State declaration Super state. Statename_1 inherits all variables, events, but can override and add #include “statename_1.h” ORSTATE(statename_1,parent) EXTENDS (super1) char * my_string; int my_int; EVENTS ENTRY (statename_1 *me) {/*C-code_here*/} EXIT (statename_1 *me) {/*C-code_here*/} EVENT(ev_name_1)(statename_1 *me, int a, int b) TO(statename_x) {/*C-code here*/} EVENT(ev_name_2)(statename_1 *me, char * str_arg) TO(statename_y) {/*C-code here*/} ENDSTATE

33. To sum up • Small memory overhead • Very small and constant time to find and maintain current state tree • All statechart constructs (initial, history, condition states, guards, …) • All done in standard C you can understand • You can use this now • Option to add inheritance and specialisation