AMUSE provides now the functionallity to use Embedded Devices based on Compact Framework using HTTP communication between the simulation in Enterprise Architect and the state machine on an Embedded Device.

I will describe it based on a Windows Mobile 6 and “Sending a Message” example.

StateMachine

To use this service it is necessary to build a Compact Framework compatible WinForm application.

Ad the class file (not the designer file) in EA and draw the state machine.

EAclass

In this example we use a Trigger to change the state between „FillOutMessage“ state and „CheckContent“ state.

In „CheckContent“ state the “content” attribute will be checked. If the “content” attribute is not set, the “contentError” attribute will be set to true, otherwise false.

The guard checks if the “content” attribute is empty or not. If it is not empty, the “showErrorMsg” operation in the state “ShowError”will be executed. After that the state „FillOutMessage“ will be activated and waits until the Trigger will be fired again.

If the “contentError” attribute is set to false, the state „SendContent“ will be activated and after that the StateMachine will be finished.

This is the mobile application i used for this example:

CF_AmuseClient

The trigger “ClickSend” can be fired with the button on the mobile device.

The “content” attribute can be set with the „set content“ button on the mobile device. The “content” attribute will get the value from the TextBox.

Start the Workflow in EA

start workflow

The server component of the http communication will be started. A TCP Listener will be started and listens on a port. The simulation will be linked with the server communication component.

The Form, which includes the state machine and the client communication, will be compiled for Compact Framework, deployed and remotely started on the mobile device with the information on which http adress the client have to send the HTTP requests (local IP where the Simulation is running + port).

Back to the Example – here are the first lines of the Simulation Output

  1. Activate – StateMachine
  2. Activate – InitForm
  3. Entry – StateMachine/InitForm
  4. Do – StateMachine/InitForm
  5. Exit – StateMachine/InitForm
  6. DeActivate – InitForm
  7. Effect – StateMachine/InitForm_to_StateMachine/FillOutMessage
  8. Effect – StateMachine/InitForm_to_StateMachine/FillOutMessage
  9. Activate – FillOutMessage
  10. Entry – StateMachine/FillOutMessage
  11. NextStepPerformed – StateMachine/InitForm
  12. Do – StateMachine/FillOutMessage
  13. Do – StateMachine/FillOutMessage
  14. Exit – StateMachine/FillOutMessage
  15. DeActivate – FillOutMessage
  16. Effect – StateMachine/FillOutMessage_to_StateMachine/CheckContent
  17. Effect – StateMachine/FillOutMessage_to_StateMachine/CheckContent
  18. Activate – CheckContent

The simulation will be set to activate when the „InitializeStateMachine“ command from the Simulation is send to the client, processed on the client, the state machine in the client is set to active and the change is fired to the server. The client also processes the InitForm, the Entry, Do, Exit, DeActivate state and executes the transition. The client notiefies the server about each change via HTTP requests.

When the state machine is active the simulation sends NextStep commands which will be fetched from the client via the polling. After a transition has been executed in the state machine the NextStep performed command will be notified to the simulation. So the simulation knows that the next NextStep command can be executed. And so on…

Here you can see a demonstration of the new functionallity:

[mediaplayer src=’/wp-content/uploads/amuse_using_embedded_device.wmv’ ]