Demo Foreign

This demo illustrates how a generated controller can be integrated with foreign components. It also shows the deployment of both protection mechanisms based on a mutex and on a thread. For the modeled controller, called Foreign, 10 different architectures have been designed. For 5 architectures the controller is protected by a mutex, and for the 5 other architectures it is protected by a thread.

The functionality of the controller consists of passing a client call to a controlled component, and forwarding the callback of that controlled component to the client. At the right the structure of the controller is presented. The client component is named User, and the controlled component is named Driver.
The class diagrams below show the controller protocol between the User component and the Foreign controller, and the driver protocol between the Foreign controller and the User component.
So, the provided port of the controller consists of a provided interface with function Start(), and a required interface with callback function CbStarted(). The controller has also a required port consisting of a required interface with function Begin(), and a provided interface with callback function CbBegin(). In general, such four interfaces represent all possible types of interfaces to a controller.
The 2 protocols and hence the interfaces are applied at all the designed architectures.
structure of Foreign Controller

Controller Protocol
Driver Protocol
controller protocol driver protocol


The design state machines differ for the two protection mechanisms. In case of protection by a mutex the Start() call results in the call Begin() to the lower level component. The subsequent callback function CbBegin() processed by the RTE callback thread is blocked by the mutex of the Foreign controller, until Start() returns. Then the callback is executed causing another callback to the User client. In the case of protection by a thread the User client is blocked after the Start() call is transformed into a message and queued in the controller's queue. The controller processes that message resulting in the invokation of the Begin() call at the Driver component; then the modeled SyncReturn stereotype will be executed to release the User. The Foreign controller receives the message from the CbBegin() callback function. As a consequence it responds with the CbStarted() callback function. The controller also invokes the Supervisor's Abandon() function. Since no other activity will happen the thread of the Foreign controller ends after informing the Supervisor.

FSM Foreign controller, mutex
FSM Foreign controller, thread
FSM of controller, protected by mutex
FSM of controller, protected by thread

Architecture ExecEnv1

This architecture reflects a console application. The modeled controller Ctlr1 is protected by a mutex. The client User1 and the server Driver1 are foreign components.
The execution of the application is shown in the sequence diagram below (that has been constructed manually). The User1 component starts the application's activity thanks to the overidden TsmRun() function, that is implemented in the UserClass of the User1 component. The outcome of this application is printing the string "CbStarted" to the log file. Note that the callbacks CbBegin and CbStarted are executed by the RTE callback thread represented by the dashed bar at the right of the diagram.

Architecture ExecEnv1 Sequence diagram ExecEnv1

Architecture ExecEnv2

This architecture verifies the modeled controller Ctlr2 against its interfaces. Ctlr2 is protected by a mutex.
The main verification scenario is shown in the sequence diagram below. This scenario has been constructed automatically by TismTool from the verification output.

Architecture ExecEnv2 Sequence diagram ExecEnv2

Architecture ExecEnv3

In this architecture Ctlr3 is protected by a mutex, the client component is a foreign component and the driver has been mocked. However, it is not possible to verify this architecture. The instantiated component User3 of the same type UserForeign as in ExecEnv1 has also a UserClass with overidden TsmRun() function. So, the verifying Supervisor is not able to feed stimuli across the Controller protocol.
Architecture ExecEnv3

Architecture ExecEnv4

In this architecture Ctlr4 is protected by a mutex, the client component is mocked and the driver is a foreign component. Unlike architecture ExecEnv3 this configuration can be verified.
The main verification scenario is shown in the sequence diagram below. The foreign component Driver4 can not be displayed in this scenario. The reason is that a foreign component is not allowed to add log data to the log file that is used to generate the sequence diagram.

Architecture ExecEnv4 Sequence diagram ExecEnv4

Architecture ExecEnv5

In this architecture Ctlr5 is protected by a mutex, the client component is mocked and the driver is a modeled component named Driver5. This configuration can be verified just like architecture ExecEnv4.
The main verification scenario is shown in the sequence diagram below. Unlike architecture ExecEnv4 the modeled component Driver5 is included in this scenario. Since TismTool has generated the source code for Driver5 from the model, also statements have been generated for writing log data to the log file for the sequence diagrams.

Architecture ExecEnv5 Sequence diagram ExecEnv5

Architecture ThreadedExecEnv1

This architecture reflects a console application. The modeled controller ThrCtlr1 is protected by a thread. The client ThrUser1 and the server ThrDriver1 are foreign components.
The execution of the application is shown in the sequence diagram below (that has been constructed manually). The ThrUser1 component starts the application's activity thanks to the overidden TsmRun() function, that is implemented in the UserClass of the ThrUser1 component. The outcome of this application is printing the string "CbStarted" to the log file. Note that the callback CbBegin is executed by the thread of the controller represented by the dashed bar at the left of ThrCtlr1; whereas the callback CbStarted is executed by the RTE callback thread represented by the dashed bar at the right of the diagram.

ThreadedArchitecture ExecEnv1
Sequence diagram ThreadedExecEnv1

Architecture ThreadedExecEnv2

This architecture verifies the modeled controller ThrCtlr2 against its interfaces. ThrCtlr2 is protected by a thread.
The main verification scenario is shown in the sequence diagram below. This scenario has been constructed automatically by TismTool from the verification output.

ThreadedArchitecture ExecEnv2
Sequence diagram ThreadedExecEnv2

Architecture ThreadedExecEnv3

In this architecture ThrCtlr3 is protected by a thread, the client component is a foreign component and the driver has been mocked. Just as in ExecEnv3 it is not possible to verify this architecture.
ThreadedArchitecture ExecEnv3

Architecture ThreadedExecEnv4

In this architecture ThrCtlr4 is protected by a thread, the client component is mocked and the driver is a foreign component. Unlike architecture ThreadedExecEnv3 this configuration can be verified.
The main verification scenario is shown in the sequence diagram below. The foreign component ThrDriver4 is not included in this scenario. The reason is that a foreign component is not allowed to add log data to the log file that is used to generate the sequence diagram.

ThreadedArchitecture ExecEnv4
Sequence diagram ThreadedExecEnv4

Architecture ThreadedExecEnv5

In this architecture ThrCtlr5 is protected by a thread, the client component is mocked and the driver is a modeled component named ThrDriver5. This configuration can be verified just like architecture ThreadedExecEnv4.
The main verification scenario is shown in the sequence diagram below. Unlike architecture ThreadedExecEnv4the modeled component ThrDriver5 is included in this scenario. Since TismTool has generated the source code for ThrDriver5 from the model, also statements have been generated for writing log data to the log file for the sequence diagrams. Furthermore, ThrDriver5 is an instance of ThrDriverComp that has been modeled with a thread.

ThreadedArchitecture ExecEnv5
Sequence diagram ThreadedExecEnv5

Valid combinations for generating source code are indicated in the table below.

Target

Generate

Protocols


Ctlr

Simulation code, Verification code

Driver

Simulation code, Verification code

Architecture


ExecEnv1

Source code + main, yielding a Console Application

ExecEnv2

Simulation code, Verification code

ExecEnv3

Not feasible

ExecEnv4

Simulation code, Verification code

ExecEnv5

Simulation code, Verification code

ThreadedExecEnv1

Source code + main, yielding a Console Application

ThreadedExecEnv2

Simulation code, Verification code

ThreadedExecEnv4

Simulation code, Verification code

ThreadedExecEnv5

Simulation code, Verification code

The files in the tables below are free to download.

C# source code generation

Foreign.xml The XMI file of the Foreign UML model.
Foreign.tsm The project file for the TismTool.
ForeignTranslation.tsl
The translation table.
Foreign.pdf The UML diagrams.
Foreign.zip The zipped archive containing the (generated) source code, the verification executable for ThreadedExecEnv5, and for every (valid) architecture the logfiles TismLog_nnnn.txt and TismSeq_nnnn.txt.
AllForeign.zip All the above files zipped together.

Java source code generation

Foreign.xml
The XMI file of the Foreign UML model.
Foreign_Java.tsm
The project file for the TismTool.
ForeignTranslation_Java.tsl
The translation table.
Foreign.pdf
The UML diagrams.
Foreign_Java.zip
The zipped archive containing the (generated) source code, the verification executable jar for ThreadedExecEnv5, and for every (valid) architecture the logfiles TismLog_nnnn.txt and TismSeq_nnnn.txt.
AllForeign_Java.zip
All the above files zipped together.

C++ source code generation (Windows)

Foreign.xml
The XMI file of the Foreign UML model.
Foreign_Cpp.tsm
The project file for the TismTool.
ForeignTranslation_Cpp.tsl
The translation table.
Foreign.pdf
The UML diagrams.
Foreign_Cpp.zip
The zipped archive containing the (generated) source code, the verification executable, and for every (valid) architecture the logfiles TismLog_nnnn.txt and TismSeq_nnnn.txt. The used C++ Boost library has version 1.48.
AllForeign_Cpp.zip
All the above files zipped together.

C source code generation (Windows)

Foreign.xml
The XMI file of the Foreign UML model.
Foreign_C.tsm
The project file for the TismTool.
ForeignTranslations_C.tsl
The translation table.
Foreign.pdf
The UML diagrams.
Foreign_C.zip
The zipped archive containing the (generated) source code, the verification executable, and for every (valid) architecture the logfiles TismLog_nnnn.txt and TismSeq_nnnn.txt. The used OSAL library is based on Windows.
AllForeign_C.zip
All the above files zipped together.

Discussion

TismTool reports the following remarks about the UML model:

I 4550: Different arguments 'bCtrlStart' -> 'bStart' in trigger pp_User->Start(bCtrlStart) @ transition ( Xmi > Data > Repository > Controller > CtlrComp > CtlrClass > CtlrClassFsm >> Transition ) : ( CtlrClassFsm >> Idle ) => ( CtlrClassFsm >> Starting )
I 4550: Different arguments 'MyCtlrlCbPar' -> 'dPar' in trigger rp_Driver->CbBegin(MyCtlrlCbPar) @ transition ( Xmi > Data > Repository > Controller > CtlrComp > CtlrClass > CtlrClassFsm >> Transition ) : ( CtlrClassFsm >> Starting ) => ( CtlrClassFsm >> Idle )
I 4550: Different arguments 'bCtrlStart' -> 'bStart' in trigger pp_User->Start(bCtrlStart) @ transition ( Xmi > Data > Repository > Controller > ThrCtlrComp > CtlrClass > CtlrClassFsm >> Transition ) : ( CtlrClassFsm >> Idle ) => ( CtlrClassFsm >> Starting )
I 4550: Different arguments 'MyCtlrlCbPar' -> 'dPar' in trigger rp_Driver->CbBegin(MyCtlrlCbPar) @ transition ( Xmi > Data > Repository > Controller > ThrCtlrComp > CtlrClass > CtlrClassFsm >> Transition ) : ( CtlrClassFsm >> Starting ) => ( CtlrClassFsm >> Idle )

ad I 4550:
It is up to the designer to change the name of a function parameter. The informing remark is given to stimulate consistency and/or prevent editorial errors.

By downloading and/or using the above items you accept the terms of the Disclaimer. So make sure you have read it before downloading or using anything from this section of the site. In general terms that means you use them at your own risk, and we accept NO RESPONSIBILITY WHATSOEVER for anything that may occur as a result of your use of, or inability to use, any item provided via these pages.