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. |
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 of controller, protected by mutex |
FSM of controller, protected by thread |
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.
|
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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. |
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. |
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. |
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. |
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.