Home

Integration with Operating Systems

1. THREADED_SIMPLE_EXAMPLE If this flag is defined the external tasks in the simple example will be started Implementation Details for Different RTOS VxWorks The Threaded integration for VxWorks is developed and tested using a Solaris Softkernel in Tornado 2 The following vxWorks header files are used ifdef THREADVXWORKS include errno h include vxWorks h include semLib h include msgQLib h msgQCreate msgQDelete ms gQSend msgQReceive msgQNumMsgs include taskLib h taskSpawn include semaphore h POSIX semaphores endif The following VxWorks primitives have been used VxWorks primitives Explanation sem_init POSIX semaphores are frequent sem_wait ly used e g to protect the input sem_post sem destroy Jh queue to synchronize start up msgQCreate Message queues are used in both msgQReceive models in VxWorks The mes msgQSend sage queue is created in the THREADED START THREAD MAC RO msgQDelete 3234 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration VxWorks primitives Explanation taskSpawn taskSpawn is used for creating a taskDelete thread The name entry is not taskSuspend ised taskSuspend is only used by the Main thread It is called from the macro THREADED AFTER_THREAD ST
2. Chapter 65 Integration with Operating Systems 3246 Configuration The TCP IP adapter is configured using compilation flags The basic configuration can be done using the TCP IP Connection Wizard in the Targeting Expert Including the TCP IP adapter The TCP IP adapter requires environment files environment header files and ASCII encoding decoding for correct operation These options are activated when the TCP IP Signal Sending check box is enabled in the Targeting Expert s TCP IP Connection Wizard Server Port Number For a component that receives signals a TCP port number must be spec ified The server thread uses this port number to listen for incoming con nections The port number is set in a text box in the TCP IP Connection Wizard You can also set the port manually by setting the flag XSERVPORT to the desired value If no port number is specified the port number is set to 5000 by default Routing You must manually implement a routing function so that a destination is specified for every SDL signal that is sent to the environment The function must be declared in a C header file The file is specified in a text box in the TCP IP Connection Wizard or by setting the flag XROUTING_INC to the header file name The routing function implementation should be placed in a C file that is compiled and linked with the other code It is specified using either the text box in the TCP IP Connection Wizard or by including it i
3. The makefiles and compilation switches are set up for the application to compile using either the Borland or the Microsoft compiler listed above There is a separate makefile for each compiler simple sdt simple ssy bl1 sbk Examples pr1 spr Ee dynpr1 spr Win32 sctenv c LightIntegration makefile lt possibly links to other files gt MyExtTask c L TightIntegration J makefile scthooks h _ lt other RTOS gt lt possibly links to other files gt L INCLUDE Figure 570 File structure for the Simple example Light Integration Limitations for the Light Integration Please see the Release Guide Building a Light Integration Please see the Building and Running a Light Integration on page 3268 for instructions There are different makefiles provided for Borland compilers and Mi crosoft compilers Telelogic Tau 4 5 User s Manual 3285 Chapter 65 Integration with Operating Systems Tight Integration Limitations for the Tight Integration Please read the Release Guide for details about limitations that apply to all systems using Tight Integration Building a Tight Integration Please see the Building and Running a Tight Integration on page 3270 for instructions There are different makefiles provided for Borland compilers and Mi crosoft compilers Note The command line length limitation for the Borland compiler can sometimes be exceeded If
4. e The trade off between performance and scheduling latency e How complex interaction the system has with the environment e Whether an operating system will be used or not e Memory management Telelogic Tau 4 5 User s Manual 3207 Chapter 65 Integration with Operating Systems Performance vs scheduling latency Generally the Light integration model provides better performance than a Tight integration but worst case scheduling latency is the dura tion of the longest state transition A Tight integration is normally preferable when low scheduling latency is important On the other hand performance suffers from the overhead associated with OS scheduling and inter process communications Another consideration is that blocking calls either inlined in SDL code or as part of environment functions will completely stop execution of a Light integration for the duration of the call Making blocking calls in a Tight integration will only stop the thread making the call The Threaded integration is in a sense a combination of the other two integration models An application part that makes blocking calls can be mapped to a separate OS thread Other parts where fast inter process communication is important can be mapped to another OS thread In ternally in this thread signal exchange will be handled in the same way as in a Light integration Environment interaction If interaction with the environment is simple then a Light integrati
5. ing extract from the SDL_Create function ifdef THREADED if PrsId gt SysD 0 THREADED START THREAD xMainLoop StartUpSig gt Receiver LocalPId gt PrsP gt SysD PrsId gt ThreadParam gt ThreadStackSize PrsId gt ThreadParam gt ThreadPrio PrsiId gt ThreadParam gt MaxQueueLength PrsId gt ThreadParam gt MaxMesSize endif Please note that the thread parameters are taken from the xPrsIdN ode for the process SDL_ STATIC CREATE PROC NAME PREFIX PROC NAME PROC_IDNODE PROC_NAME STRING STARTUP_IDNODE Telelogic Tau 4 5 User s Manual 3227 Chapter 65 Integration with Operating Systems STARTUP _PAR_ TYPE PRIV_DATA TYPE PRIO PAD FUNCTION BLOCK _INST_NUMBER This macro is used for creating static processes processes that are created at system start up It will be called from the yInit func tion and is mapped to the SDL kernel function SDL_Create in the same way as in the SDL_CREATE macro The xMainLoop function is the entry point for the thread First in this function is the macro THREADED THREAD BEGINNING SYSD The main purpose of this macro is to wait for the start up semaphore xInitSem No thread is allowed to start executing until ALL static pro cesses threads have been created Sending Signals In the default model signals are sent in the same way as for a Light in tegration except that they are first linked into
6. pthread_attr_init pthread_attr_setstacksize esdi pthread_attr_setschedpoli cy thread_attr_setdetachstat Ce 7 pthread_attr_setscope The pthread_attr_ primitives are used to set the attributes of a thread before it is created mq_open mq_close mq_receive mq_unlink mq_send These primitive are only used in the alternative signal sending model pthread_create pthread_exit These primitives are used when a thread is created and when it ter minates timer settime timer delete These primitives are used for set ting a timer before the mq_receive is called in the al ternative signal sending model The time out for the timer is the duration for the next internal SDL timer to expire When the timer expires the signal_handler function sets the error message to EINTR Telelogic Tau 4 5 User s Manual July 2003 Threaded Integration Thread Parameters Default values DEFAULT_STACKSIZE 15000 DEFAULT _PRIO 10 DEFAULT _MAXQUEUESIZE 128 DEFAULT _MAXMESSIZE sizeof xSignalNode OSE The Threaded integration for OSE have been developed and tested with an OSE Softkernel version 4 3 on Solaris 2 6 using the gcc compiler version 2 95 The following OSE header file is include ifdef THREADOSE include ose Hendif THREADOSE h The following OSE primit
7. s Manual July 2003 Tight Integration Tight Integration July 2003 Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site Note This presentation is focused on the general principles and models used in a Tight Integration When specific RTOS primitives are needed in the presentation examples from the VxWorks implemen tation are used The implementation and RTOS calls used in other integrations are covered in separate annexes to this chapter one for each supported RTOS There are two models of Tight Integration In the Standard Model one SDL process instance is mapped to one OS task In the Instance Set Model an entire instance set all instances of a process is mapped to one OS task Scheduling between OS tasks is managed by the RTOS sched uler this means that preemption is normally used though only on an in stance set level in the Instance Set Model SDL semantics are preserved in a Tight Integration for example setting a timer implies an automatic reset first The start up of a system i e creation of static processes initialization of synonyms and creation of an environment task and a timer task is handled by a generated initialization function called yInit Normally this function is called from another initialization function where some additional initializations take place before the yInit function
8. yOutputSignalPtr gt SigP yOutputSignalPtr 1 yOutputSignalPtr gt SignalCode SIG NAME yOutputSignalPtr gt Sender SDL SELF The Examples directory contains a simple SDL system that also uses an external process a separate OS task For each supported operating sys tem there is an implementation of this demonstrating how to hook into the integration package Further description of the example can be found in A Simple Example on page 3264 Naming Conventions Names of variables datatypes and support functions in generated code and package files often start with one of the letters x y and z The general rules there are some exceptions are Names and objects starting with an x represent general datatypes and support functions in the kernel Examples extern XCONST struct xVarIdStruct xInputSignal xFindReceiver Names starting with a y are names of IdNodes representing SDL variables process states channels blocks datatypes for signals PAD functions etc in generated code Examples extern XCONST struct xVarIdStruct yVarR_z012 okmess ySigR_z3_ok yPAD _z01 prl Names and objects starting with a z are SDL variables SDL names process state names etc in generated code Examples define z010_ idle 1 z012_okmess Telelogic Tau 4 5 User s Manual 3215 Chapter 65 Integration with Operating Systems The Symbol Table All signals blocks processes channels etc
9. 1 ete 1 case 6 2 xGRSetSymbol 1 3 SDL _NextState VarP yVarP gt State return Telelogic Tau 4 5 User s Manual 3217 Chapter 65 Integration with Operating Systems 3218 Signal Queues Basically every process has at least one signal queue e Ina Light Integration each process instance has an input queue e Inthe Standard Model Tight Integration there is an input queue and a save queue for each instance e In the Instance Set Model Tight Integration there is an input queue and a save queue for every instance set These two queues are shared by all the instances All signals that are sent to a process arrive in the input queue The save queue is used to keep signals that cannot be handled in the current state but should be saved for future use This is tightly connected to the SDL Save concept but is also used in the implementation of timers For a Light Integration there are no save queues Instead all signals that should be saved will remain in the input queue until they can be re ceived Process Priorities The use of process priorities requires some caution Priorities can be set with the PRIO directive in the SDL suite but there is no mapping of priorities for different platforms The generated code will use exactly the values specified in the SDL system This will not be a problem in a Light Integration but for Tight Integrations the result may not be the ex pected Example 536 Process prior
10. Gee aa ma emhathg emnatng x Figure 576 MSC trace for Simple Example 3298 Telelogic Tau 4 5 User s Manual July 2003
11. Pri nextstate Idle Telelogic Tau 4 5 User s Manual 3271 Chapter 65 Integration with Operating Systems Process instance 9901456 Prl nextstate Idle Process instance 9901455 Pri input signal Go Signal Go received in Pri1 Instancel Prl process dynpr1 9901458 created Pri nextstate Wait Process instance 9901456 Prl input signal Go Signal Go received in Prl Instance2 Process instance 9901458 DynPr1 Set timer T1 Process instance 9901459 DynPr1l nextstate wait Process instance 9901458 DynPr1l input signal T1 DynPr1 signal Terminating sent DynPrl1l stopped Process instance 9901455 Prl input signal Terminating Pri signal Ok sent Pri dash nextstate Ok received in MyExtTask with parameter 1 Process instance 99014516 DynPr1 input signal T1 DynPr1 signal Terminating sent DynPr1l stopped Process instance 99014513 Pri input signal Terminating Pri signal Ok sent Pri dash nextstate Ok received in MyExtTask with parameter 2 Standard Model In the standard model each instance of the Pr1 and the DynPr1 processes will be represented by an OS task in all four tasks The environment is represented by a task called MyExt Task This task is external to the SDL system 3272 Telelogic Tau 4 5 User s Manual July 2003 July 2003 A Simple Example Instance Set Model In the instance set model there will be two OS tasks one ea
12. ResetTimer Timer1 k xSDLResetInTimerTask ResetTimer _ T Timer mm T xSDLSet Timer L i Figure 563 Function calls and OS signaling when setting and waiting for a timer UML notation is being used thus the full arrowheads represent function calls and the half arrowheads represent messages Parameters have been left out except for the name of the timer in the ResetTimer request Note that a reset is performed first as required in the SDL specification To be able to implement the full semantics of SDL timers a number of support functions have been implemented e xSDLActive Checks whether an SDL timer is active and returns true or false The function passes the question on to the timer task in the form of a re quest Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration xSDLActiveInTimerTask Called by the timer task upon request Checks if an SDL timer is ac tive and returns true or false xSDLReset Resets an SDL timer by sending a request to the timer task While waiting for a reply all new signals to the calling task are saved in the save queue In the case of an Instance Set Model Tight Integration this means that no instance of the process can execute a transition until a reply is received If the reply states that the timer couldn t be found it might be in the save queue or the input queue of the task because it has recently expired If so it is simply removed SDL se
13. SDL_Pld xThreadedRegExtTask This function will return an SDL Pld representing the calling External process thread It works in the following way 1 Geta ThreadId for the calling process thread 2 Allocate and assign an SDL struct xPrsIdRec representing the ex ternal process thread 3 Call the SDL kernel function xGet PId to get an SDL_PId 4 IfMSC trace is on it will generate an entry for the process thread in the MSC diagram 5 Allocate and initialize an SDL system data record for the external process thread 6 Create a queue for the calling process thread 7 Assign the system data record entry in the SDL_PId 8 Return the SDL_PId xSignalNode xThreadedReceiveSDLSig SDL_Pld This function will wait for an SDL signal indefinitely When a signal ar rives the signal will be taken out of the queue and return the signal If MSC trace is on the signal will also be traced in the MSC diagram xSignalNode xThreadedReceiveSDLSig_WithTimeOut SDL_Pld SDL_Duration This function will work in the same way as xThreadedReceiveSDL Sig except that it will only wait for the specified time THREADED_ASSIGN_SDL_SIG_PARAMS sigptr signame paramno pa ram This macro will use the macro token operator to concatenate the sigptr signame paramno into a simple assignment of the signal param eter with the specified number 3232 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration N
14. Telelogic Support web site The standard product support and maintenance agreement does not assist in adapting to your target environment Customer specific OS integrations All OS integration models can be supported enhanced and custom ized by using Telelogic s Professional Services Other integrations Telelogic has developed a large number of integrations based on the company s vast experience of integrating with all operating systems on the market 3200 Telelogic Tau 4 5 User s Manual July 2003 Introduction Introduction July 2003 The code that is generated by the Cadvanced SDL to C compiler is de signed to run on different platforms This is done by letting all platform dependent concepts be represented by C macros that can be expanded appropriately for each environment There are also types used in the generated code that have to be defined Integration as referred to in this chapter is the process of adapting the generated code to a certain plat form This chapter describes the different models that are supported in Telel ogic Tau Note Throughout this chapter annexes excluded VxWorks terminology has been used whenever there are differences between operating systems Particularly this means that the term task has been used on several occasions The corresponding term would be thread for Win32 and Solaris process for OSE Delta and task for Nucleus Different Integration Models With Ca
15. Integration It contains state informa 3216 Telelogic Tau 4 5 User s Manual July 2003 Common Features July 2003 tion local variables pointers to parent and offspring etc One important entry is the RestartAddress pointing out which transition to execute when the PAD function runs see below Dynamic behavior The dynamic behavior of an SDL process is implemented in a PAD function Process Activity Definition The PAD function is used some what differently in the different integration models e In the Light Integration the scheduler calls the PAD function of the process The PAD function then returns to the scheduler when the transition is finished e Inthe Standard Model Tight Integration the PAD function is called when the process is started and does not return until process termi nation It then contains a main loop where one iteration corresponds to one transition e The Instance Set Model Tight Integration contains a mix of the two Below is the code for ending a transition before and after macro expan sion for a Light Integration SDL symbol Nextstate Generated code before macro expansion NEXTSTATE SDTREF SDL ti RTOS MANUAL SDL simple spr 1 143 55 100 1 ifdef XCASELABELS 1 case 6 endif 2 XAT_LAST SYMBOL 3 SDL_DASH_ NEXTSTATE Generated code after macro expansion for a Light Integration NEXTSTATE SDTREF SDL ti RTOS MANUAL SDL simple spr 1 143 55 100
16. SDL system are handled in the two user written functions xInEnv and xOutEnv There is a template file for writ ing these two function in the standard distribution This file can be found at lt installation directory gt sdt sdtdir lt your platform os version gt sdtdir INCLUDE sctenv c Running a Light Integration under an External RTOS Since there are some fundamental differences between different RTOS we can only give a general idea of how to generate a Light Integration under an external RTOS here Typical things that may be different in different RTOS e If you are allowed to have a main function in your application e If your start up function must be specified in a configuration file e Ifthe cross compiler requires additional OS specific header files to be included e If it is possible to run the application in a simulated target environ ment e Syntax for the makefile Telelogic Tau 4 5 User s Manual 3223 Chapter 65 Integration with Operating Systems 3224 General Steps The normal steps to create a Light Integration under an external RTOS can be summarized as follows 1 Copy the source and header files for an application kernel from the installation of the SDL suite The files are residing in the following directory lt installation directory gt sdt sdtdir lt your host and os version gt sdtdir INCLUDE 2 Generate an lt application gt c file with the SDL to C Compiler Note The code generator
17. The SDL processes run as separate OS tasks as explained below Sched uling is handled by the OS and is normally time sliced priority based and preemptive Communication takes place using the inter process communications mechanisms offered by the OS normally message queues This applies to signals sent between SDL processes as well as signals sent to or re ceived from the environment There are no environment functions as il lustrated in Figure 560 Telelogic Tau 4 5 User s Manual 3205 Chapter 65 Integration with Operating Systems APPLICATION LEVEL T 0000 SDLSYSTEM o OS Task running OS Task running an SDL process an SDL process External OS Task Code written in any language Process 1 Process 2 OS LEVEL a 4 O send __ OS receive primitive j primitiy Figure 560 Signalling in the Tight Integration Model An SDL process sends one internal and one external signal OS primitives are al ways used The SDL system is not an entity of its own Thick borders denote OS tasks Other properties of a Tight Integration e There is a single timer task which handles all SDL timers e SDL Simulators cannot be tightly integrated with an RTOS e Execution trace is available in textual or MSC format Variations on Tight integration Tight integrations come in two varieties the Standard model and the In stance Set model Consider an SDL system with processes as outlined in F
18. User s Manual July 2003 July 2003 Threaded Integration The tcpip directory is referenced relative to the sdtdir variable Hint Using TCP IP with a new sdtdir If you use an sdtdir that is different from the default sdtdir in the SDL suite installation directory be sure to copy the tepip di rectory to the new location Otherwise you may encounter problems in finding the TCP IP files at compilation Note Pointers as Signal Parameters Distributed components execute in separate memory spaces Care must be taken so that pointers are not sent as signal parameters over TCP IP and used in a remote component Routing of Signals For each signal that is sent from your SDL application you must specify a destination in the form of an IP address or host name and a TCP port number This information should be accessed from a routing function which is called when a signal is sent from the SDL application The routing function is made accessible from the TCP IP adapter by set ting the flag XROUTING_INC to the name of a routing header file This is a plain C header file where the macro XFINDDEST OUTSIG SIGNAME IP PORT is defined as a function OUTSIG and SIGNAME are in param eters IP and PORT are out parameters OUTSIG should be declared as xSignalNode From this parameter signal data such as parameters can be accessed SIGNAME holds the name of the signal and is declared as char In many cases the signal name is
19. Windows primitives Explanation CreateSemaphore ReleaseSemaphore CloseHandle WaitForSingleObject These primitives are used for pro tecting input queues other queues and synchronization in start up One extra semaphore xInit Queue is used when a newly cre ated thread is creating his own in put queue PeekMessage This primitive is used in the THREADED THREAD BEGINNING macro in the alternative signal sending model This primitive force the thread to create a mes sage queue It is used together with the xInitQueue semaphore GetMessage Post ThreadMessage a These primitives are used for re ceiving sending messages in the alternative signal sending model SetTimer KillTimer These primitives are used to set an OS timer that will signal the thread when it expires The time out of this timer is the duration until the next internal SDL timer expires for this thread The window message will be set to WM_TIMER if the OS timer ex pires 3240 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration Windows primitives Explanation CreateThread These primitives are used for cre ExitThread ating and terminating threads SetThreadPriority This primitive is used for setting the priority of the thread SuspendThread Called
20. an infinite loop after having created all static processes This loop is used to receive signals sent to the environment queue Use the HOOK_MAIN AFTER SIGNAL RECEPTION to insert code for pro cessing these signals Limitations for Integrations July 2003 In general the same restrictions as for the SDL to C Compiler apply but Tight integrations have some further restrictions The detailed limita tions for Light and Tight integrations are listed in the Release Guide Telelogic Tau 4 5 User s Manual 3263 Chapter 65 Integration with Operating Systems A Simple Example 3264 This section describes an example system named Simple The annexes show how to integrate the example with different operating systems The example demonstrates the following techniques e How to integrate an SDL system with an operating system e How to make the environment communicate with the SDL system in a Light integration e How to make an external process written in C communicate with the SDL system in a Tight integration e How to use the special Tight Integration version of the ADT pidlist pr The Simple System System Simple include pidlist pr N Ig eer Pay l A I I 1 1 SYNONYM prt PldList Pld_Lit Code amp yPrsR_Pr1 i SIGNAL N Go Integer Ok Integer SYNONYM startinstance1 Integer 1 SYNONYM startinstance2 Integer 2 C1 BIi uy for Too Figure 564 System Simple T
21. by the main thread in the macro THREADED AFTER_THREAD STA RT GetCurrent Thread Used in the SuspendThread mac ro Thread Parameters Default values DEFAULT_STACKSIZE 0 Automatically resized by OS DEFAULT _PRIO THREAD PRIORITY NORMAL DEFAULT MAXQUEUESIZE 1024 DEFAULT_MAXMESSIZE sizeof xSignalNode Signal Sending over TCP IP Introduction For applications using the Threaded integration model a plug in mod ule for TCP IP communication is available The module supports signal sending between distributed SDL applications via a TCP IP connection ASCII Encoding Decoding is used for the conversion between signal and transport format The module is delivered as C source code which is integrated and built together with code generated by the CAdvanced SDL to C Compiler The TCP IP adapter supports the four operating systems for which Threaded integrations are available These are Windows Solaris Vx Works and OSE Telelogic Tau 4 5 User s Manual 3241 Chapter 65 Integration with Operating Systems Architecture The TCP IP functions are called from the environment functions xInitEnv and xOutEnv The functions are included by setting the XENV_INC flag to tcpipcomm h The tcpipcomm h file contains define directives that translates macros in the environment file to function calls in the TCP IP adapter When a signal is sent to the environment using the xOutEnv function xSendSignal is cal
22. cc WorkShop Compilers 4 2 with Solaris 2 6 running on a workstation The main differences between the Solaris 2 6 integration and the gener al model are e Inthe file sctsolaris h the macros which contain the Solaris 2 6 specific function calls are implemented The file sctsolaris c contains the Solaris 2 6 integration specific functions e The Solaris 2 6 integration is fully POSIX compliant SDL process es are mapped to POSIX threads using the pthread_create function and POSIX queues are created for each thread using mq_open The threads are suspended when its corresponding queue is empty 3288 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Annex 4 Integration for Solaris 2 6 Running the Test Example Simple Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site Prerequisites This test example is developed as a Solaris 2 6 application on a work station The makefile and compilation switches are set up for the appli cation to run under Solaris 2 6 using the cc WorkShop Compilers 4 2 compiler dtdi E PAE simple sdt RTOS simple ssy bl1 sbk Examples pr1 spr ae dynpr1 spr Solaris Isctenv c LightIntegration makefile lt possibly links to other files gt MyExtTask c L TightIntegration J Makefile scthooks h l _ lt other RTOS gt lt possibly links to other
23. files gt L INCLUDE Figure 571 File Structure for the Simple example Light Integration Limitations for the Light Integration Please see the Release Guide Building a Light Integration Please see the Building and Running a Light Integration on page 3268 for instructions Telelogic Tau 4 5 User s Manual 3289 Chapter 65 Integration with Operating Systems 3290 Tight Integration Limitations for the Tight Integration Please read the Release Guide for details about limitations that apply to all systems using Tight Integration Building a Tight Integration Please see the Building and Running a Tight Integration on page 3270 for instructions Compiler Flags The following defines ifdef are used in this integration SOLARIS INTEGRATION Ensures that the sctsolaris h file is included in each C file Must be set in all cases XOS_TRACE Gives a textual trace for most of the SDL events by us ing printf to some device This flag should not be used together with XMSC_TRACE XMSC_TRACE Will give a textual trace in the format of MSC PR Z 120 by using printf This trace is possible to view in the MSC Ed itor included in Telelogic Tau This flag should not be used together with XOS_TRACE XMSC_EDIToR Used together with the XMSC_TRACE flag the MSC trace is automatically displayed in the MSC Editor Note that you must have the Organizer open on your machine X ONE TASK PER
24. from SDL specifications is handled by the environment functions in the same way as for a Light integration There is though one major difference and that is that it is possible in a Threaded to send signals directly to an SDL pro cess with the SDL_Output function The SDL_Output function is thread safe because of the use of OS semaphores Variations of Threaded Integration There are two different implementation of signal sending between threads in Threaded The default model send signals in the same way as in a Light integration but the input queues are protected by OS sema phores In the alternative model the signals are sent received by OS_Send and OS_ Received In the alternative model there is no use for OS semaphores Which model to use can be decided at compilation time by setting the compilation switch THREADED ALTERNATIVE SIGNAL SENDING Threaded Default The sender of an SDL signal takes a semaphore before accessing the receivers input queue The signal is then linked into the input queue and the semaphore is given back The receiver is normally waiting for a semaphore When a signal is sent the semaphore is released by the sender To send a signal two semaphores are normally needed One semaphore is protecting the input queue and the other is used for synchronizing the sender and the receiv er In Solaris where we use POSIX threads and semaphores they are called xInputPortMutex and
25. in the Make dialog The hs file is included in the application if the compilation switch XINCLUDE_HS FILE is set The SDL_Pld Type The spL_p1d SDL Process ID type has different meanings in the Stan dard and the Instance Set Models In the Standard Model it represents the message queue while it represents the process instance in the In stance Set Model This is because the entire instance set will have the same message queue in the last case ifdef X_ONE_ TASK PER INSTANCE SET typedef xEPrsNode SDL _PId else typedef MSG Q ID SDL PId endif 3250 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration Signals The signal header consists of a struct with information needed to handle the signal inside an SDL system The signal header struct is defined in the RTOS specific file sct lt RTOS gt h typedef struct xSignalHeaderStruct xSignalHeader typedef struct xSignalHeaderStruct int SignalCode xSignalHeader Pre Suc SDL_PId Sender void SigP ifdef X_ONE_TASK PER _INSTANCE_ SET SDL_PId Receiver endif ifdef XMSC_TRACE int Signalld int IsTimer endif xSignalHeaderRec The signal header stores SignalCode in this case an integer two point ers Pre and Suc used when saving the signal in the save queue and Sender holding the spL_ Pid of the sending SDL process In the In stance Set Model there is an extra parameter Receiver necessary to make a distinc
26. in an SDL system have a corresponding representation in the symbol table described in chapter 62 The Master Library This symbol table consists of nodes IdNodes each representing one entity of the system The IdNodes are pointers to structs See the following example extern XCONST struct xPrsIdStruct yPrsR_z02_dynpr1 define yPrsN_z02 dynprl amp yPrsR_z02_ dynpr1 The N_ and the R_ just before z02_dynpr1 indicate if it is a node N_ or a record R_ Memory Allocation The xAlloc function is always used when allocating dynamic memory The function is placed in the sctos c file but in the Tight Integrations the body of the function is found in the sct lt RTOS gt h file Start up The yInit function is called during start up of the SDL system It is responsible for creating all static processes and for initializing SDL syn onyms Implementation of SDL Concepts SDL Processes An SDL process consists of three parts in generated code Instance set common data instance specific data and dynamic behavior Instance set common data Variables and structures that are common to all instances of a process are stored in a record of the type xPrsIdStruct defined in scttypes h This record is referenced by a node in the symbol table Instance specific data Variables and structures of the process instance are declared via the macro PROCESS_VARS This macro is defined in different ways in the Light and the two models of Tight
27. of the new instance in the global symbol tree The start up signal is sent When this signal is received in the task the start transition of the process is executed Process Termination The following actions are carried out when a process terminates 1 The save queue and the message queue are emptied 2 The save queue is deleted 3 A message is sent to the xTimerTask with a request to remove all active timers of the process 4 xFreePrs is called to free the PrsNode 5 The message queue is deleted In some operating systems this is done automatically when the task is deleted 6 The task is deleted PAD functions Each PAD Process Activity Definition function will contain an eternal loop with an OS receive statement When a process instance is created it is the PAD function that is called in the OS Create primitive The start up and execution of a PAD function works like this 1 The support function xInputSignal is called This function will wait for the start up signal that is always received first and then re turn to the PAD function The PAD function goes to the label Label_Execute_ Transition This label is the start of a code block containing a switch statement that evaluates the process variable RestartAddress The code un der each different case then represents a transition At the end of this block the process variable State is updated and execution contin ues at Label New Transition In Label _New Tr
28. primitive PS tie primitive L 4 Figure 558 Signalling in the Light Integration Model An SDL process sends one internal and one external signal xOutEnv must be written to call the OS send primitive Thick borders denote OS tasks Other properties of a Light Integration e The scheduling order can be controlled by process priorities and or signal priorities as set by the PRIO directive e An SDL system can be partitioned i e split into several executa bles Each partition has its own kernel scheduler and set of environ ment functions Partitioning is explained in Partitioning on page 2571 in chapter 57 The Cadvanced Cbasic SDL to C Compiler e Itis easy to go to target Write the environment functions and re compile the standard kernel with a cross compiler Threaded Integration The main difference between a Light integration and a Threaded inte gration is that any part of the SDL system can execute in its own thread in a Threaded integration A thread in a Threaded integration can exe 3202 Telelogic Tau 4 5 User s Manual July 2003 Introduction cute one or several SDL processes or even blocks How the different SDL objects should be mapped to threads is specified in the Deploy ment Editor The user can specify thread specific parameters like STACKSIZE PRIORITY MAXMESSAGEQUEUESIZE and MAXMESSAGESIZE in the Deployment Editor The Deployment Ed itor works together with the Targeting Expert
29. the xNewSignals queue In the xMainLoop function the xNewSignals queue is checked for new entries If a new signal is available it is sent to the process itself with the SDL_Output function See the following extract from the xMainLoop function THREADED LOCK _INPUTPORT xSystemData SysD while xSystemData SysD gt xNewSignals Suc xSig nalNode amp xSystemData SysD gt xNewSignals SDL Output xSystemData SysD gt xNewSignals Suc xSigPrioPar xSystemData SysD gt xNewSignals Suc gt Prio 0 THREADED UNLOCK _INPUTPORT xSystemData SysD The Alternative Signal Sending Model In the alternative signal sending model an OS message signal is sent containing a pointer to the SDL signal For this a message queue must be created for each thread at thread creation How this is done differs from OS to OS See Signalling in Threaded Integration The sender sends the pointer to the SDL signal with the OS_Send prim itive The receiver receives the message extracts the pointer to the SDL 3228 Telelogic Tau 4 5 User s Manual July 2003 Threaded Integration signal and links it into the xNewSignal queue After this the signal is handled in the same way as in the default model New Macros The same source files are used in a Threaded integration as in a Light The only SDL kernel source files that are affected by the Threaded in tegration are scttypes h sctsdl c and scto
30. this happens you should define the DEFINE MACROS at the beginning of the sctwin32 h file Compiler Flags The following defines ifdef are used in this integration e WIN32 INTEGRATION Ensures that the sctwin32 h file is includ ed in each C file Must be set in all cases e XOS_TRACE Gives a textual trace for most of the SDL events by us ing printf to some device This flag should not be used together with XMSC_TRACE e XMSC_TRACE Will give a textual trace in the format of MSC PR Z 120 by using printf This trace is possible to view in the MSC Ed itor included in Telelogic Tau This flag should not be used together with XOS_TRACE e XMSC_EDITOR Used together with the xmMSc_TRACE flag the MSC trace is automatically displayed in the MSC Editor Note that you must have the Organizer open on your machine e X ONE TASK _PER_INSTANCE_SET States that the Instance Set Model is used The Standard Model is otherwise chosen by default e XERR When this flag is defined the return status of all Win32 func tion calls will be printed 3286 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Annex 3 Integration for Win32 XINCLUDE_HS FILE Includes the system signal header file which is required for tight integrations This file maps signal names to in tegers XRTOSTIME Should always be set for all tight integrations XUSING_SccD This should be set when using the preprocessor SCCD to ensure that the wi
31. with Operating Systems Create a task Call xAllocPrs Send the startup signal Assign SDL synonyms The semaphore is used for synchronizing start up of static processes No static process is allowed to execute its start transition before all static processes are created because a start transition can have signal sending to other static instances The MyMain function is placed among other support functions in the file sctsdl c The yInit function is generated by the code generator and placed last in the generated file for the system The Instance Set Model The Instance Set Model is based on the same principles as the Standard Model with the difference that the instance set is the basic unit rather than the process instance Processes Both the instances and the instance sets are represented in the symbol table In addition to the three parts that always make up an SDL process there is also an extra struct for the instance set defining for example the input queue which is common to all the instances Further there is a PAD function for each instance but also for the instance set Process Representation An SDL_PId is represented by an xEPrsNode pointing to an xEPrsStruct An xEPrsNode also represents a process instance in the symbol table both in the Standard Model and the Instance Set Model typedef struct xEPrsStruct xEPrsNode NextPrs SDL_PId Self xPrsIdNode NameNode int BlockInstNumber xPrsNode Va
32. xInputPortCond One OS feature that is needed in Threaded is a Conditional Wait We are only allowed to wait for a signal until the first internal timer expires In POSIX there is a primitive called pthread_cond_wait and in Windows there is a similar concept called Wait ForSingleObject where a time out can be specified In VxWorks and OSE the only con cept where you can specify a time out is OS_Receive For synchroniza Telelogic Tau 4 5 User s Manual July 2003 July 2003 Introduction tion between the sender and receiver we are sending a small OS_Message the character c in these two RTOS Threaded using OS Send and OS Receive In this alternative implementation we are sending the signals using OS_Send and OS_Receive Signals are now sent to OS_Message queues The sender sends the pointer to the SDL signal in an OS_Message to the receiver s OS_Queue When the signal is received the SDL signal is unpacked and linked in to the receivers input queue The advantage with this implementation is that there is now synchroni zation between the sender and the receiver Any number of threads can send signals at the same time to a specific receiver without having to wait for a semaphore Tight integration We also provide an alternate run time model which is called a Tight in tegration because the generated code interacts directly with the under lying operating system when creating processes sending signals etc
33. A RT taskIdSelf Used in taskDelete and taskSus pend Thread Parameters Default values DEFAULT_STACKSIZE 800 DEFAULT _PRIO 100 DEFAULT MAXQUEUESIZE 250 DEFAULT_MAXMESSIZE sizeof xSignalNode Solaris The Threaded integration for Solaris is developed and tested in the fol lowing environment Sun Solaris 2 6 with Sun WorkShop compiler cc version 5 0 Included header files for Solaris elif THREADSOLARIS include lt pthread h gt include lt semaphore h gt ifdef THREADED ALTERNATIVE SIGNAL SENDING include lt mqueue h gt include lt signal h gt include lt time h gt endif THREADED ALTERNATIVE SIGNAL SENDING endif The following Solaris primitives have been used Telelogic Tau 4 5 User s Manual 3235 Chapter 65 Integration with Operating Systems Solaris primitives Explanation sem_init sem_wait sem_post pthread_mutex_init pthread_mutex_lock pthread_mutex_unlock pthread_mutex_destroy pthread_cond_init pthread_cond_wait pthread_cond_timedwait pthread_cond_signal pthread_cond_destroy The sem_ primitives are only used in the start up to synchro nize static processes threads The pthread_mutex_ primitives are used to protect the input queues and other queues The pthread_cond_ primitives are used to synchronize sender and receiver in the default model
34. Chapter 65 July 2003 Integration with Operating Systems This chapter describes how to integrate code generated by the Cad vanced SDL to C Compiler with operating systems The different integration models Light Integration Threaded In tegration and Tight Integration are explained in the introduction There is a separate annex for each supported RTOS where the OS specific parts are described Telelogic Tau 4 5 User s Manual 3199 Chapter 65 Integration with Operating Systems Important You are free to reuse the integrations supplied by Telelogic or mod ify them to your needs The OS integrations are tested by Telelogic but Telelogic does not guarantee that they will perform in your spe cific target environment hardware CPU RTOS version etc Please refer to RTOS integrations on page 9 in chapter 1 Plat forms and Products in the Installation Guide for information about host and target environments where the integration types have been developed and tested Light and Threaded integrations The Light and Threaded integrations are included in the delivery The standard product support and maintenance agreement only in cludes support for the Light and Threaded integrations available from Telelogic if no changes have been made to the integrations Tight Integration The Tight integration is meant to serve as a template to be adapted to your needs It is available for you as a free download from the
35. Compiler Linker Make line in the Partitioning Dia gram Model You should now see the following in the Targeting Ex pert window see The Compile Linker Make Window in Targeting Expert SDL Targeting Expert home develop Ir THREADEXAMPLE Simple pdm File Edit Make Tool W in Grt yee gt gt poooidien W Mo Solaris Mroaded cis Compier source Fies Compier Fiag Adtonal Compier tirer mere Compiler Description The compiler s options should carry the placeholders s source file o object fi I include path i e Include Coder Include Compiler name ged gt Default Options THREADS s o td Default Compile as C Compile as debug Library Aag DTHREADSOLARIS Default Include I 1 sctuseinclude Default Comm Include 1 sctCODERDIR I sct TCPIPDIR Default Obj extension 9 a Default C parser and assembler description The placeholders s input file o output fie should be used in the options C parser name Rei Options F an Md sove DE Cancel Z Help Target executable EADEXAMPLE Simple _DPE981536368 Simple _DPE1 Simple _DPE2 My_Solaris_threaded simple sct Figure 574 The Compile Linker Make Window in Targeting Expert July 2003 Telelogic Tau 4 5 User s Manual 3295 Chapter 65 Integration with Operating Systems 13 Define the following flag THREADED_SIMPLE_EXAMPLE
36. L_20UTPUT_COMPUTED_TO xDefaultPrioSignal xIdNode 0 sig2 ySigN_z3_sig2 TO _PROCESS Env amp yEnvR_env o S ig2 SIGNAL _ ALLOC ERROR_END Generated code after macro expansion for a Light Integration 1 yOutputSignal xGetSignal amp ySigR_z3_sig2 amp yEnvR_env gt ActivePrsList xPrsNode 0 amp yEnvR_env gt ActivePrsList gt Self xSysD SDL_ NULL Var yVarP gt Self 2 SDL Output yOutputSignal xIdNode 0 File Structure Note The source file and examples for Tight Integration are not included in the standard delivery They are available as free downloads from Telelogic Support web site The Generated Files An integration uses one or more of four files that can be generated by the Code Generator All integrations require the C source file lt systemname gt c whereas the interface file lt systemname gt ifc is op tional For a Tight Integration the signal number file lt systemname gt hs may be used and for a Light Integration the file sct env c representing the environment can be used The source file uses the highest level set of macros that are defined in the different integration packages 3212 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Common Features The Integration Packages The files containing the necessary macro definitions and support func tions are organized as shown in Figure 562 For each operating system there is o
37. PROCESS TYPE prl1 z01_ prl1 yPrsN_z01 pr1 z01_prl1 SDL_INTEGER_LIT 2 SDL_INTEGER LIT 2 yVDef_z01_ pri xDefaultPrioProcess yPAD_z01 pri ifdef SDL STATIC CREATE 1 for Temp 1 Temp lt SDL_ INTEGER _LIT 2 Temp 2 SDL_STATIC_CREATE pr1 z01_pr1 yPrsN_z01 pri pr1 ySigN_z01_ pri yPDef_z01_prl1 yVDef_z01 pri xDefaultPrioProcess yPAD z01 pri1 1 endif Generated Code after macro expansion for a Light Integration BRK RK RRR RR KR IK I KR KR KR RK IK IR I RR RR IK IK RR KR OK IK RR KR ORK RK RK RK SECTION Initialization TR IK IK RK RK IR KK KK KKK KR KR IR I RR OR OK IK RR KR OK IK k RR KK k KKK extern void yInit int Temp 1 for Temp 1 Temp lt 2 Temp 2 SDL Create xGetSignal amp ySigR_z01_ pri xSysD SDL_ NULL Var xSysD SDL_ NULL Var amp yPrsR_z0l_pril 1 July 2003 Telelogic Tau 4 5 User s Manual 3219 Chapter 65 Integration with Operating Systems SDL Signals Signal Sending In generated code a signal sending is handled by two macros ALLOC_SIGNAL or ALLOC_SIGNAL_PAR for a signal with parameters and SDL_2O0UTPUT_xxxx there are different macros depending on how the SDL output was defined e g with or without an explicit TO SDL symbol Output Generated code before macro expansion 1 ALLOC _ SIGNAL go ySigN_z03_go TO PROCESS p yPrsN_z09 p XSIGNALHEADERTYPE SIGNAL ALLOC ERROR 2 SDL_20UTPUT_COMPUTED_TO xDefaultPrioSignal xIdNode 0 go yS
38. SignalNode pointer is not used Error Handling The TCP IP adapter contains basic error handling Error checks are per formed when encoding decoding socket and thread functions are in voked If THREADED ERROR is defined an error message is printed on stdout with the name of the function where the error occurred A plat form dependent error code is included in the error message For a de scription of the error code consult the User s Manual of your target op erating system An error implies that the function where the error occurred exits Clean up is performed which means that the application can continue its exe cution A special case to consider is when an error occurs in the server thread function which runs statically during the execution The thread exits and must be restarted manually If THREADED_TRACE is defined the execution of the TCP IP adapter is logged onto stdout when signals are encoded sent received and decod ed Example 538 TCP IP Adapter Error Message An error occurs when a signal should be sent via the TCP IP adapter The following is logged on stdout ERROR xSendSignal SCM_CONNECT 146 The target platform is Solaris The error code indicates that the connec tion was refused probably because a server can not be found at the spec ified address xSendSignal exits and the application continues its exe cution Telelogic Tau 4 5 User s Manual 3245
39. _INSTANCE_SET Should be defined when the al ternative runtime model is to be used XINCLUDE_HS_ FILE Includes the system signal header file which is required for tight integrations This file maps signal names to in tegers XRTOSTIME Should always be set for all tight integrations Telelogic Tau 4 5 User s Manual July 2003 Annex 5 Generic POSIX Tight Integration Annex 5 Generic POSIX Tight Integration Introduction Note The Generic POSIX integration is based on the Solaris integration For a description and instructions on how to generate and run the ex ample see Annex 4 Integration for Solaris 2 6 on page 3288 July 2003 Telelogic Tau 4 5 User s Manual 3291 Chapter 65 Integration with Operating Systems Annex 6 Building a Threaded Integration Introduction This Tutorial on how to create a Threaded integration is developed on a Windows machine and is intended to be run under a Windows OS If you want to use this example on another machine and for another OS please remember to choose the appropriate integration and compiler for your OS in the Targeting Expert Preparations The same SDL source files for the example Simple that is used in the Light integration example will be used in this tutorial Copy the Source files for the Example Simple 1 Create your own test directory and enter it 2 Copy the SDL source files for the example Simple cp lt installation gt sdt sdtdir RTOS Examp
40. ad In our example this means that there should be one thread for all in stances of Prl and one thread for each instance of DynPr1 Double click the component symbol In the Symbol Details window specify that the integration model should be Threaded see Signal ling in Threaded Integration X Symbol Details Component Sit NE x Stereotype H H Integration Model Properties Qualifier Figure 573 Symbol Details for the Component Simple Double click the thread symbol for Pr1 Specify the following Thread Parameters for the Thread P1 Thread Stack Size 2048 Thread Priority 8 Queue Size 128 Max Signal Size 1024 Double click the object symbol and specify that the stereotype should be Process and that the qualifier for Pr1 should be Simple B11 Pr1 Make the appropriate specifications for the object Symbol for DynPr1 Qualifier Simple B11 DynPr1 Telelogic Tau 4 5 User s Manual July 2003 Annex 6 Building a Threaded Integration 7 Save the deployment diagram 8 Select the deployment diagram in the Organizer and open the Tar geting Expert from the Generate menu 9 Choose the integration Threaded Integrations gt Win32 threaded 10 You will be prompted if you want to generate the sdl_cfg h file Se lect No 11 Disable the Generation of Environment Function by deselecting En vironment Functions in the Environment section of the window 12 Click on the
41. alled PidList and an operator called PId_Lit With this ADT it is pos sible to directly address any static process instance in the system both from internal SDL processes and from external OS tasks You can find more information about this feature in How to Obtain PId Literals on page 3178 in chapter 63 The ADT Library Note If you need the pidlist pr ADT in a Tight Integration then you must use the version in the lt installation directory gt sdt sdtdir RTOS SDL directory The Standard Model In the Standard Model of the Tight Integration each SDL process is im plemented as an OS task Preemption and the use of process priorities is only limited to what the OS supports Processes Process Creation An SDL process is created in the following way in the VxWorks inte gration 1 A start up signal is allocated 2 A message queue is created Some operating systems create the message queue automatically when the task is created This is ex plained for each operating system in the annexes to this chapter 3 The task is created with the message queue ID as a start up param eter In the case of VxWorks the task will have a name starting with VXWORKSPAD This is a function which will first initialize some in ternal variables and then call the PAD function Telelogic Tau 4 5 User s Manual 3257 Chapter 65 Integration with Operating Systems 3258 A function xAllocPrs is called to create a representation
42. ample stance of DynPr1 and enters the Wait state In the Wait state it waits for the signal Terminating from the created instance of DynPr1 sends Ok back to the environment and goes back into the Wait state Since the Terminating signal will only be received once the process is going to remain in the Wait state forever Process DynPr1 Process DynPr1 1 1 amei oat laian daai cise O Parent gt Figure 567 Process DynPr1 The dynamic process DynPr1 has no instances at system start and a maximum of two instances Each instance of Pr1 creates one instance of DynPr1 DynPr1 sets the timer t1 to five seconds waits for a timeout sends the signal Terminating to its creator and finally terminates Connection to the Environment The environment is handled in different ways depending on the integra tion model See below for details Telelogic Tau 4 5 User s Manual 3267 Chapter 65 Integration with Operating Systems Building and Running a Light Integration This section will take you through the general steps required to build a Light Integration for the Simple example The procedure works the same for most operating systems Please also check the annexes for im portant information about your operating system General Steps for a Light Integration 1 Create a working directory and an INCLUDE directory below it Note S sdtdir lt installation directory gt sdt sdtdir lt machine dependent dir gt wher
43. ansition a new call is made to xInputSignal and execution then continues at Label_Execute Transition The structure of a PAD function is described below with pseudo code shown in italics Telelogic Tau 4 5 User s Manual July 2003 Tight Integration void yPAD z01_ prl void VarP Variable declarations xInputSignal is called to receive the start up signal goto Label Execute Transition Label_New_Transition xInputSignal is called to receive a signal Label_Execute_ Transition Local declarations switch yVarP gt RestartAddress case 0 Execute the start transition Update the process state variable goto Label New Transition case 1 Execute the transition Update the process state variable goto Label New Transition Scheduling Since each SDL process is implemented as an OS task scheduling be tween processes will be handled completely by the OS Start up Start up of a Standard Model Tight Integration can be described as fol lows pseudocode is shown in italics MyMain initialization of semaphores etc yInit Give startup semaphores taskSuspend Mymain yInit Create the timer task Create an environment task or only an environment queue for i 1 i lt NoOfStaticProcessTypes i for j 1 j lt No0fStaticInstancesOfEachProcesstype j Allocate a startup signal Create a message queue July 2003 Telelogic Tau 4 5 User s Manual 3259 Chapter 65 Integration
44. be fore writing to it THREADED_LISTACCESS_END Release the semaphore protecting a global active or available list THREADED_EXPORT_START Protect export and import actions by taking a semaphore THREADED _EXPORT_END Release the semaphore after ex port and import actions THREADED START THREAD Start a new thread THREADED _STOP_THREAD Terminate a thread THREADED_AFTER_THREAD_STA Synchronize the start up of newly RE created threads THREADED_SEND_OUTPUT Send messages signals Used in both models Textual and MSC Trace in Threaded Textual SDL Trace similar to the Textual Trace in Telelogic Tau Sim ulator can be turned on by selecting the flag SDL trace will set the flag THREADED_XTRACE in the Target Library Kernel window in Targeting Expert On line MSC trace is possible when running an application under a soft kernel on Windows or UNIX Select the flag MSC trace will set the flag THREADED_MSCTRACE in the Target Library Kernel window in Targeting Expert API for interfacing a Threaded Integration An API is available with a number of useful functions MACROS that will facilitate the work of sending receiving signals between external processes threads and an SDL Threaded Application Telelogic Tau 4 5 User s Manual 3231 Chapter 65 Integration with Operating Systems The following functions and MACROS are available
45. ce data of the calling SDL process This is because the procedure must be able to use internal variables in the calling process Before a procedure returns to the caller it performs an xReleasePrd call This function removes the call from the ActivePrd list SDL Timers SDL timers are represented by signals All active timer signals are kept in a sorted list either within the single task of a Light Integration or in a certain timer task in a Tight Integration When a timer expires the sig nal representing it is sent to the SDL process that set it SDL symbol SET Timer Generated code before macro expansion SET T1 SDTREF SDL ti RTOS MANUAL SDL dynpr1 spr 1 119 55 25 1 ifdef XCASELABELS 1 case 2 endif 2 SDL_SET_DUR xPlus_ SDL Time SDL_Now 3 SDL DURATION LIT 5 0 5 0 4 SDL DURATION LIT 5 0 5 0 tl ySigN_z021 t1 yTim_t1 T1 Generated code after macro expansion for a Light Integration SET T1 SDTREF SDL ti RTOS MANUAL SDL dynpr1 spr 1 119 55 25 1 eae eee 1 case 2 2 SDL Set xPlus_ SDL Duration SDL_Now 3 SDL Duration Lit 5 0 xGetSignal 4 amp ySigR_z021_t1 yVarP gt Self yVarP gt Self Telelogic Tau 4 5 User s Manual 3221 Chapter 65 Integration with Operating Systems Light Integration A Light Integration is a stand alone executable which can be generated with or without a simulator An executable that should run under UNIX ca
46. ch for Pr1 and DynPr1 The environment is represented by a task called MyExTask just as in the standard model This task is external to the SDL system How Signals are Sent to and from the Environment There is an external task called MyExt Task which is written in C It sends the signal Go into the SDL system and receives the signal Ok back by using services in the operating system The HOOK MAIN AFTER PROCESS RELEASE macro in scttypes h is used to create MyExt Task as soon as the SDL system allowed to run The source code for the external task is placed in the file MyExtTask c This file is specific to the selected operating system because it calls the operating system directly Telelogic Tau 4 5 User s Manual 3273 Chapter 65 Integration with Operating Systems Tight Integration Code Reference This section explains data types procedures and macros used in a Tight Integration Light Integrations are explained in the Master Library General Macros XPP x The macro xPP is used in function declarations to specify the function parameters It is defined like this define XPP x x if function prototypes according to ANSI C can be used xptrint The following type is also always defined define xptrint unsigned where xptrint should be an int type with the same size as a pointer xPrsNode and xPrdNode typedef struct xPrsStruct xPrsNode typedef struct xPrdStruct xPrdNode xPrsNode and xPrdNode are pointe
47. de some simple functions for getting system time and handling memory allocation depending on compiler and libraries standard C library functions can often be used If you use an OS that takes care of load balancing between CPUs then you should select a Tight integration because load balancing normally uses threads as the load unit to distribute If you want to distribute your SDL System over several nodes CPUs you should use the Threaded integration together with the TCP IP fea ture Considerations when choosing between Tight and Threaded Overall Telelogic recommends using the Threaded integration mode unless there are specific technical reasons to prefer one of the other integration models The two most important reasons for choosing the Threaded model are 1 The Threaded integration out perform a Tight Integration in most situations e g implementation of Timers and creation of tasks is about 100 faster in Threaded 2 In Threaded you are not limited to two partitioning models Any mapping between SDL objects and threads can be specified in the Deployment editor For a more comprehensive list of the differences between Threaded and Tight see the following sections Advantages of Threaded e The default model is very simple to implement for a new OS A working prototype should normally take 2 3 days Telelogic Tau 4 5 User s Manual 3209 Chapter 65 Integration with Operating Systems e The Threaded model can be u
48. dvanced there are three different run time models called Light Integration Threaded Integration and Tight Integration Tight integra tions are then divided into two submodels the Standard model and the Instance Set model All models use the same generated code You will find descriptions of the different models below as well as guidelines for choosing between them Light integration The simplest case is called a Light integration because only a minimum of interaction with the operating system is required a Light integration could even run on a target system without any OS at all The complete SDL system runs as a single OS task Scheduling of SDL processes is handled by the standard kernel running a complete state transition at a time no preemption Worst case scheduling latency is thus the duration of the longest transition Communication between SDL processes is handled by the kernel com munication between the SDL system and the environment is handled in Telelogic Tau 4 5 User s Manual 3201 Chapter 65 Integration with Operating Systems the two user supplied functions xInEnv and xOutEnv These func tions are platform dependent See Figure 558 APPLICATION LEVEL OS task running SDT Light integration External OS task SDL System Process 1 Process 2 SDL Kernel Code written in any language primitive primitive lt a x OS LEVEL OS send ane _ 4 OS receive
49. e lt machine dependent dir gt is sunos5sdtdir on SunOS 5 hppasdtdir on HP and wini386 in Windows 2 Copy all files from sdtdir RTOS Examples Simple lt se lected RTOS gt Light Integration to the working directory 3 Copy the following files to the INCLUDE directory sdtdir INCLUDE sctlocal h sdtdir INCLUDE sctpred c sdtdir INCLUDE sctsdl c sdtdir INCLUDE sctos c sdtdir INCLUDE sctpred h sdtdir INCLUDE scttypes h 4 Open the system file sdtdir RTOS Examples Simple simple sdt WA TAU UY U 5 Change the destination directory to your working directory 6 Set the options Lower Case and Generate environment header file 7 Select the Cadvanced SDL to C Compiler and generate an applica tion 8 Edit the makefile supplied with the example to fit your environ ment Normally you will only have to point out the directory where the RTOS is installed 9 Use the makefile to build an executable 10 Download the executable to target or run it under a kernel simulator soft kernel 3268 Telelogic Tau 4 5 User s Manual July 2003 July 2003 A Simple Example Result From Running the System The output when running the example should be Signal Go received in Pri Instancel Signal Go received in Pri Instance2 Signal Ok received with the following parameter 1 Signal Ok received with the following parameter 2 The xInEnv Function This is where the start up signal Go is sent In a real s
50. ed on a Sun workstation with SunOS Release 5 6 The main differences between the OSE Delta and the OSE Classic mod el are e The OSE Delta model uses three semaphores to avoid synchroniza tion problems in SDL start transitions e The timer is implemented in systimer c which is supplied by ENEA This is not accurate and is only for demonstration purposes You will have to supply a suitable timer implementation for the tar get environment 3278 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Annex 1 Integration for OSE Delta Running the Test Example Simple Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site Prerequisites This test example is developed as an OSE Delta application on a Sun workstation The makefile and compilation switches are set up for the application to run under an OSE Simulator for OS68 If you are using another configuration of OSE you probably need to edit the provided makefile aaa simple sdt l RTOS simple ssy bl1 sbk Examples pr1 spr OSEDelta sctenv c LightIntegration makefile osemain con softose con o ___ dynpr1 spr MyExtTask c L TightIntegration makefile pidlist pr scthooks h sctose_d h sctose_d c lt other RTOS gt osemain con softose con L INCLUDE Figure 568 File structure for the Simple example Light In
51. ed as int or unsigned long int Mapping Between SDL Time and RTOS Time The macro SDL_DURATION_ LIT specifies the mapping between the SDL time in seconds and the local RTOS representation of time In Vx Works the system time is given in ticks and the translation is defined as follows define SDL DURATION LIT R I D I 1000 D 1000000 R is the real type representation of the time in seconds I and D are the integer and decimal parts of an integer type representation of the time I is in seconds and D in nanoseconds The code generator will generate all three numbers but either R or I and D will be used depending on the RTOS Timers All timer activity in the SDL system is handled by a dedicated timer task The timer task accepts requests in the form of messages in Vx Works It then keeps the requests for setting a timer sorted in a timer queue and uses some OS mechanism to wait for the first request to time out The mechanism used can be either an OS timer or a timeout in the waiting for new requests When a request times out the timer task sends a signal back to the task that first sent the request The function calls and Telelogic Tau 4 5 User s Manual 3253 Chapter 65 Integration with Operating Systems 3254 OS signaling involved in setting and waiting for an SDL timer can be viewed in Figure 563 SDL process Timer task T xSDLReset
52. el Result From Running the System The output when running the example depends on what kind of trace has been enabled If you set XMSC_TRACE it should be similar to the follow ing System_Init_ Proc instancehead process Environment msc RTOS Trace Pril instancehead process Prl Pr12 instancehead process Prl Pril condition Idle Pr12 condition Idle Prill in Go 0 from MyExtTask3 Signal Go received in Pri Instancel dynpri4 instancehead process dynpri Prll create dynprl14 Pril condition Wait Pr12 in Go 1 from MyExtTask3 Signal Go received in Pri Instance2 dynpri5 instancehead process dynprl Prl2 create dynpr15 Pr12 condition Wait dynpr14 set T1 2 5000 SDTNOW 269 dynprl14 condition wait dynpri5 set T1 3 5000 SDTNOW 276 dynpri5 condition wait dynpr14 timeout T1 2 SDTNOW 5284 dynprl1i4 out Terminating 4 to Pril dynpri4 endinstance Prill in Terminating 4 from dynpr14 Pr1l1l out Ok 5 to MyExtTask3 Ok received in MyExtTask with paramer 1 dynpri5 timeout T1 3 SDTNOW 5463 dynpri5 out Terminating 6 to Pr12 dynpri5 endinstance Pr1i2 in Terminating 6 from dynpr15 Pr12 out Ok 7 to MyExtTask3 Ok received in MyExtTask with paramer 2 Setting the xOS_TRACE flag should result in the following output Process Pr1 9901455 created Process Pr1 9901456 created Process instance 9901455
53. ever focused on a Light Integration Some things es pecially the listings of data structures are not correct in every detail for Tight Integrations but should still be very useful The Use of Macros A source file generated by an SDL to C compiler is independent from the choice of integration model and operating system Instead of system calls it uses macros that have to be defined elsewhere when the system is built Each SDL concept is represented by one or more C macros These macros will have different definitions for different integration models and operating systems Telelogic Tau provides a number of in tegration packages for this purpose In a Light Integration many macros are expanded into functions of the standard kernel A Tight Integration has lower level macros that are defined in separate files for each oper ating system and finally expanded into OS primitives or certain OS de pendent constructions Below is an example of generated code for signal sending Code in cap ital letters are the SDL suite macros The bracketed numbers indicate corresponding lines of code For a description of the different macros see chapter 62 The Master Library Telelogic Tau 4 5 User s Manual 3211 Chapter 65 Integration with Operating Systems SDL symbol Output Sig2 Generated code before macro expansion 1 ALLOC SIGNAL sig2 ySigN_z3_sig2 TO_PROCESS Env amp yEnvR_env XSIGNALHEADERTYPE SIGNAL ALLOC ERROR 2 SD
54. formation about your operating system Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site General Steps for a Tight Integration 1 Create a working directory and an INCLUDE directory below it Note S sdtdir lt installation directory gt sdt sdtdir lt machine dependent dir gt where lt machine dependent dir gt is sunos5sdtdir on SunOS 5 hppasdtdir on HP and wini386 in Windows 2 Copy all files from sdtdir RTOS Examples Simple lt se lected RTOS gt Tight Integration to the working directory 3 Copy all files from sdtdir RTOS Examples Simple lt se lected RTOS gt Tight Integration INCLUDE to the INCLUDE directory 4 Open the system file sdtdir RTOS Examples Simple simle sdt 5 Change the destination directory to your working directory 6 Set the options Lower Case Generate environment header file and Generate signal number file 7 Select the Cadvanced SDL to C Compiler and generate an applica tion 8 Edit the makefile supplied with the example to fit your environ ment Normally you will only have to point out the directory where the RTOS is installed 3270 Telelogic Tau 4 5 User s Manual July 2003 A Simple Example July 2003 9 Use the makefile to build an executable 10 Download the executable to target or run it under a kernel simulator soft kern
55. from the general model described earlier in this chapter Note Third party products referred to in this manual may have limitations that have impact on the usability of Telelogic Tau Please consult the supplier s support organization or the third party product s technical reference documentation for up to date information about such lim itations Principles This integration is developed using the Microsoft 32 bit C C Com piler Version 11 00 7022 and tested on NT 4 0 NT 3 51 and Windows 95 platforms The integration is also compiled with Borland C 5 2 for Win32 and tested on NT 4 0 NT 3 51 and Windows 95 platforms The main differences between integration with Win32 and the general model are e Threads are created with the Win32 primitive CreateThread The thread is then automatically given an input queue the first time it calls a USER or GDI function e xAlloc is implemented with Win32 function HeapAlloc e xFree is implemented with Win32 function HeapFree e The timer implementation uses the Win32 Get TickCount func tion Running the Test Example Simple Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site 3284 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Annex 3 Integration for Win32 Prerequisites This test example is developed as a Win32 console application on a PC
56. he SDL representation of Simple consists of a single block B11 Seen from the outside the system accepts the signal Go and responds after about five seconds by sending the signal Ok The signal Go may be sent twice to the system Telelogic Tau 4 5 User s Manual July 2003 A Simple Example Block BI1 Block BI1 1 1 sich SIGNAL N Terminating R1 4 fog fa Termina Pri NAME ing DynPr1 0 2 Figure 565 Block BLI Block B11 has two processes The static process Pr1 and the dynamic process DynPr1 DynPr1 is created by Pr1 and can send the signal Ter minating back to its parent Pr1 handles all the interaction with the en vironment through the signals Go and Ok July 2003 Telelogic Tau 4 5 User s Manual 3265 Chapter 65 Integration with Operating Systems Process Pr1 Process Pri 1 1 DCL Param Integer ExtSender Pld itSender sender StartInstance1 StartInstance2 CODE printf Signal Go received in Prt lInstance1 n Ok Param t ExtSender gt Figure 566 Process Prl Process Pr1 is a static process with two instances It has two states Idle and Wait In the Idle state the process waits for the signal Go with an integer parameter representing the instance number of this instance It then prints the instance number to the standard output creates one in 3266 Telelogic Tau 4 5 User s Manual July 2003 July 2003 A Simple Ex
57. ial in OSE Declaration in scttypes h elif THREADOSE extern OSENTRYPOINT xMainLoop else extern void xMainLoop XPP xSystemData j endif Definition in sctsdl c elif THREADOSI pJ Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration OS_ PROCESS xMainLoop else ifndef XNOPROTO void xMainLoop xSystemData SysD else void xMainLoop SysD xSystemData SysD endif endif Definition of NIL NIL is defined in the OSE kernel and must not be redefined in the SDL kernel ifndef THREADOSE define NIL 0 endif THREADOSE Forward declaration of xSignalNode The xSignalNode must have forward declaration very early in the sct types h file since it is used in the union SIGNAL definition typedef struct xSignalStruct xSignalNode union SIGNAL SIGSELECT sigNo xSignalNode SDLSig xSystemDataPtr SysD ifndef THREADOSE typedef struct xSignalStruct xSignalNode endif THREADOSE Windows The Threaded integration for Windows is developed and tested on Win dows 2000 Professional with the Borland C compiler version 5 02 Telelogic Tau 4 5 User s Manual 3239 Chapter 65 Integration with Operating Systems The following header files for Windows are included ifdef THREADWIN32 include limits h include windows h include dos h The following Windows primitives are used in the Threaded integra tion
58. igN_z03_go TO_ PROCESS p yPrsN_z09 p 0 Go SIGNAL ALLOC ERROR_END XBETWEEN SYMBOLS 4 579 Generated code after macro expansion for a VxWorks Tight Integra tion yOutputSignalPtr xAlloc sizeof xSignalHeaderRec yOutputSignalPtr gt SignalCode 2 yOutputSignalPtr gt Sender yVarP gt Self Err msgQSend xTo_ Process amp yPrsR_z09 p char amp yOutputSignalPtr sizeof xSignalHeaderRec 0 0 0 xFree void amp yOutputSignalPtr if Err 1 taskLock printf Error during s found in VXWORKS function s Error code s n OUTPUT msgQSend strerror errno taskUnlock NNNNNNNNNNNKFEHREHE In this example the signal is called go and has no parameters The SDL_2O0UTPUT_COMPUTED_TO macro indicates that it was sent without an explicit TO SDL Procedures An SDL procedure is represented by a function similar to a PAD func tion Before a procedure is called there are two support functions that need to be called xGet Prd and xAddPrdCal1l The xGet Prd function allocates an xPrdStruct for the called proce dure and returns an xPrdNode pointing to the struct 3220 Telelogic Tau 4 5 User s Manual July 2003 SET Now 5 T1 July 2003 Common Features The xAddPrdCall function adds the new procedure call in the calling process ActivePrd list an element in the xPrsStruct The procedure is called with a pointer to the instan
59. igure 561 1 The MSC trace will be printed on standard output To see the trace in an MSC diagram copy the text into a file and read it into the MSC Editor 3206 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Introduction Prs1 ao Prs2 ae Prs3 0 2 Figure 561 A partial SDL system This system will be used for explaining the different models of Tight Integration Tight Standard In the standard model of a Tight integration every SDL process instance is mapped to its own OS task Tasks are created and destroyed dynam ically as SDL process instances are created and terminated The example system will initially run as five OS tasks four for Prs1 and one for Prs2 Up to 13 tasks may be created as needed Tight Instance Set In the Instance Set model of a Tight integration every SDL process in stance set is mapped to its own OS task Tasks are created statically when the SDL system is initialized and are never destroyed Thus there may be OS tasks that have no SDL process instances to run The example system will run as three OS tasks regardless of the number of process instances one task each for Prs1 Prs2 and Prs3 Choosing between Light Threaded and Tight Integration Choosing between the three integration models depends on many fac tors Some of them are related to properties of the SDL system others relate to the target environment Important factors to consider are
60. in the Compiler description Options window This flag will start the External threads in the simple example 14 Define the following Compilation flags THREADED _XTRACE THREADED_MSCTRACE by selecting the flags SDL trace and MSC trace in the Target li brary Kernel window 15 Add the MyExt Task c file as a new source file Click on the Source Files entry in the window and add the MyExt Task c file in the source file list Save the settings You are now prompted again to generate config uration file this time select Yes 16 You should now be back in the Analyze Generate code window and be ready to generate the application Do a full Make and if you have followed the instructions the Target ing Expert will now analyze generate code generate makefile compile and link the application 17 Run the application simple sct Please note that you have to traverse down in the generated directory structure to find the application You will find the application in a subdirectory similar to this path lt your test directory gt Simple DPE981536368 Sim ple DPE1 Simple DPE2 Win32_ threaded The output you should see when you run the application should be as follows 3296 Telelogic Tau 4 5 User s Manual July 2003 Annex 6 Building a Threaded Integration Connected with the Postmaster OUTPUT of go to Pri 1 be Parameter s 1 xxx NEXTSTATE Idle OUTPUT of go to Pri 2 Parameter s 2
61. is called Timers in the system are handled by one central timer task This task re ceives messages each containing a request to set a timer and will send messages back as the timers expire Common Features File Structure The files related to the tight integration concept are placed in the follow ing directory in the installation lt installation directo 1 SDL signals will be implemented as messages in VxWorks Telelogic Tau 4 5 User s Manual 3249 Chapter 65 Integration with Operating Systems ry gt sdt sdtdir RTOS lt operating system gt TightIntegra tion The same files are used for both the Standard Model and the In stance Set Model Each RTOS directory contains the following files e sct lt RTOS gt h This file contains the second level of macros see the comments for scttypes hin The Integration Packages on page 3213 All macros are using OS specific calls or types sct lt RTOS gt c This file contains OS specific support functions e sdt2 lt RTOS gt c Most RTOS require that signals messages are represented with an integer value This is the source file for a utility program for gener ating signal identities Each signal will be assigned an integer value The output will be a file with the suffix hs This file is automati cally included in the application In the SDL suite the hs file can also be generated by the SDL to C Compiler by turning on the option Generate signal number file
62. ity problems _ Assume that Process1 has its priority set to 100 using the PRIO 100 directive and Process2 has PRIO 50 These priority values will be used as is by the underlying scheduler In the SDL Suite simulators and Light integrations the highest priority is 0 In VxWorks 0 is the highest priority whereas in pSOS the highest priority is 255 Thus the simulated system a Light integration for any operating system and a Tight integration for VxWorks will all run Process at a higher priority than Process1 In contrast a Tight integration for pSOS will run Process at a higher priority than Process2 Telelogic Tau 4 5 User s Manual July 2003 Common Features Process Creation Regardless of the integration model there are a number of things that have to be done when an SDL process instance is created The structs that represent the instance have to be created It needs a representation in the symbol tree and a signal queue except in the Instance Set Model of Tight Integration where the signal queue belongs to the instance set A Start up signal is also always allocated and sent to the process SDL symbol SDL Static Create Generated code before macro expansion Prt 2 2 BR RRR KK KK IKK KKK IR KK KOK RK KR KK KK IRR IKK IR KK IK KR RR KE SECTION Initialization RRR RR IK IK KK RR KR KR IK KR I RK RR IK IK KK RRR RR IK KR KR KK k k k k RR KR KK f extern void yInit XPP void INIT _
63. ives have been used OSE Primitives Explanation create_sem wait_sem signal_sem DE These primitives are used for pro tecting input queues other queues and for synchronizing start up receive These primitive are used for re TEC Ve W ENO Mec y ceiving sending signals in both send models Receive send is also used to pass the start up parameter xSysD to a new thread since OSE does not support start up parameters in the create_process primitive alloc These primitives are used for al free_buf locating and returning OSE sig nals July 2003 Telelogic Tau 4 5 User s Manual 3237 Chapter 65 Integration with Operating Systems 3238 OSE Primitives Explanation start This primitive is used for starting a newly created thread kill_proc This primitive terminates a thread stop This primitive stop the execution of a thread Used in the THREADED AFTER _THREAD STA RT macro current process Used in the kill_proc and stop calls create_process This primitive is used for creating Threads Thread Parameters Default values DEFAULT_STACKSIZE 1024 DEFAULT _PRIO 8 DEFAULT _MAXQUEUESIZE 1024 DEFAULT_MAXMESSIZE sizeof xSignalNode Declaration of xMainLoop The declaration and definition of the thread s entry point xMain Loop is spec
64. kes a printout THREADED ERROR REPORT NEG Checks the value of the return variable and if ERROR makes a printout THREADED ERROR REPORT OP N_NEG G Checks the value of the return variable and if ERROR makes a printout HREADED_ERROR_REPORT WAI NEG Checks the value of the return variable and if ERROR makes a printout HREADED GLOBAL VARS Global variable defines HREADED GLOBAL INIT Initialization of global variables like semaphores HREADED THREAD VARS Definitions of thread variables HREADED THREAD INIT Initialization of thread variables HREADED THREAD BEGINNING Wait for xInitSem to be released HREADED LOCK INPUTPORT Protect the input queue by taking the semaphore HREADED UNLOCK INPUTPORT Releasing the semaphore for the input queue HREADED WAIT AND UNLOCK INPUTPORT Wait for next message signal to arrive or the next internal timer to expire THREADED SIGNAL AND UNLOC K_INPUTPORT Send a signal and release the semaphore for the input queue Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration MACRO NAME Explanation THREADED LISTREAD START Protect global active and avail able lists with a semaphore be fore reading it THREADED LISTWRITE_START Protect global active and avail able lists with a semaphore
65. le Sim ple s 3 Copy the environment file from the Win32 ThreadedIntegration di rectory cp lt your Installation gt sdt sdtdir RTOS Examples Sim ple Win32 ThreadedIntegration MyExtTask c 4 Start the SDL suite and open the system file for the Simple example Partition the system using the Deployment Editor 1 Create a new deployment diagram and call it Simple 2 Edit the deployment diagram according to the figure below see _ Signalling in Threaded Integration 3292 Telelogic Tau 4 5 User s Manual July 2003 Annex 6 Building a Threaded Integration X DP Editor Simple 1 rw Simple sdp S o x File Edit View Pages Diagrams Window Tools Help Process Process Pri DynPr1 Figure 572 Deployment Diagram for the example Simple 3 Make sure that you got the multiplicity right on the aggregation line from the component to thread To check this you can double click on the line The right value should be 1 On aggregation line from component to thread Pr1 On aggregation line from component to thread DynPrl July 2003 Telelogic Tau 4 5 User s Manual 3293 Chapter 65 Integration with Operating Systems 3294 The multiplicity on the aggregation lines specifies how the compo nent should be mapped to threads A means that each instance of the component should be mapped to an individual thread Aname means that the entire component should be mapped to a thre
66. le files using the Threaded integration model From component 1 two different signals can be sent Sig should be sent to component 2 and Sig should be sent to component 3 Component 2 resides on a host called host 2 It uses port number 7001 for listening for incoming connections which means that XSERVPORT is set to 7001 XSERVPORT 7001 Component 3 resides on host3 and listens on port number 7001 XSERVPORT 7001 Please note that the ports are not in conflict since the hosts are different For component 1 a routing function is implemented The flag XROUTING_INC is set to router h The routing header file has the following contents H define XFINDDEST OUTSIG SIGNAME IP PORT xGetDestination OUTSIG SIGNAME IP PORT The routing C file router c contains the implemented function include stdlib h void xGetDestination xSignalNode sig char sigName char IPAddr int Port if strcemp sigName Sigl 0 strcpy IPAddr host2 0 Port 7001 Dereferencing else if strcemp sigName Sig2 0 strcpy IPAddr host3 0 3244 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration Port 7001 return router c is then compiled and linked together with the generated code the coder library and the TCP IP adapter This example shows a fairly trivial routing scenario The routing is based only on the name of the signal The x
67. led A connection is set up with a remote server The signal destination is specified using a user implemented function When the connection is accepted the signal is encoded into ASCII format and sent via a TCP IP socket The session is then closed From xInitEnv a thread is started which polls a socket for incoming connections When a connection from a remote client is accepted a new thread is started which receives and decodes data for one signal When the signal is decoded it is inserted in the signal queue of the SDL sys tem The thread finishes its execution after the connection is closed An executing SDL system thus acts as a server when signals are re ceived from the environment and as a client when a signal should be sent to the environment The environment file of an SDL application may not be modified if the TCP IP adapter is to be used Making modifications may override the TCP IP signal sending functionality If you want to use the TCP IP adapter together with other external code from an environment file please consult Configuration on page 3246 File Structure The TCP IP adapter consists of four files located in sdtdir tcpip e tcpipcomm c should be compiled and linked with the generated C code e tcpipcomm his aC header file which is included from the generat ed environment file e tcpipthr h and tcpipsock h are header files that are included from tcpipcomm c and tcpipcomm h 3242 Telelogic Tau 4 5
68. mantics require that a reset is always performed implicitly prior to setting a timer xSDLReset InTimerTask Called by the timer task when a request has been made for resetting a timer Checks the timer queue to see if the timer to reset is there If the timer is found it is removed and the data area it holds is freed A message is sent back to the task that made the request telling whether the timer was found or not xSDLSet Called by the timer task when a request has been made for setting a timer This function sorts the request into the timer queue Addressing SDL Processes There are two ways to address SDL processes from an external task Ei ther the xFindReceiver function can be called to find an arbitrary re ceiver or the file pidlist pr can be used to provide a list of the SDL processes and then address the receiver explicitly via the input queue ID of its OS task The xFindReceiver Function When sending a signal into the SDL system where the receiver is not known a support function called xFindReceiver can be used This function takes the following parameters The ID of the signal Telelogic Tau 4 5 User s Manual 3255 Chapter 65 Integration with Operating Systems 3256 The sender ID in this case an SDL_PId representing the environ ment An optional VIA list The following files are needed to get access to SDL types signal num bers and signal parameter types scttypes h lt system_name gt hs and lt
69. ml yVarP gt z023 paraml Signal reception The support function xInputSignal is used for receiving signals in both models of Tight Integration The implementation and the parame ters are different though Timer Signals A timer signal is defined similarly to an ordinary signal but will contain some additional elements representing time out time etc The timer header struct looks like this typedef struct xTimerHeaderStruct xTimerHeader typedef struct xTimerHeaderStruct int SignalCode xTimerHeader Pre Suc SDL _PId Sender void SigP ifdef X_ONE_ TASK PER INSTANCE SET SDL_PId Receiver endif ifdef XMSC_TRACE int Signalld int IsTimer endif SDL Time TimerTime 3252 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration int TimerToSetOrReset xbool yEq xbool TestParams xTimerHeader Param xTimerHeaderRec Note An ordinary signal is identical to the first part of a timer signal This makes it possible to type cast between the two types as long as only elements in the common part of the headers are used Time When the System time is required for example when using NOW the macro SDL_Now is used The macro is in turn mapped to the function SDL_Clock in sctos c This function is implemented differently depending on the RTOS representation of time In VxWorks it returns the result of calling the RTOS function tickGet SDL_Time is normally implement
70. mpty e sctcommon h This file contains general macros for all Tight Integrations sctos c This file contains functions that are operating system and or compil er dependent like allocation and free of dynamic memory e sctpred hand sctpred c This is the header and source file where all the SDL predefined datatypes are implemented _gcetedl act This file contains SDL support functions the timer task and the tim er support functions It is non OS specific and calls many second level OS specific macros defined in sct lt RTOS gt h e scttypes h This file contains the general datatype definitions for signals IdNodes etc It also contains the macro definitions found in gener ated code Note that this file is non OS specific This means that if a call to an OS specific primitive is needed then a second level of macro is defined according to the following model In the generated code ALLOC SIGNAL PAR ok ySigN_z3 ok TO PROCESS Env amp yEnvR_env yPDef_z3_ok In scttypes h Telelogic Tau 4 5 User s Manual July 2003 July 2003 Common Features define ALLOC SIGNAL PAR SIG NAME SIG IDNODE RECEIVER SIG PAR TYPE RTOSALLOC SIGNAL PAR SIG_ NAME SIG IDNODE RECEIVER SIG PAR TYPE In sct lt RTOS gt h define RTOSALLOC SIGNAL PAR SIG NAME SIG _IDNODE RECEIVER SIG PAR TYPE yOutputSignalPtr xAlloc sizeof xSignalHeaderRec sizeof SIG PAR _TYPE
71. n the com piler settings manually See Example 537 for an example of how a rout ing function is implemented Using the TCP IP Adapter with Other Environment Functionality The TCP IP adapter header file t cpipcomm h is included from the en vironment file of a component The file tcpipcomm h contains de fine statements for macros in the environment functions that invoke TCP IP functions Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration If you want to use other functionality in parallel with the TCP IP adapt er these macros can be defined outside tcpipcomm h By setting the flag XEXTENV_INC to the header file you wish to use your header file is included from tcpipcomm h This enables you to insert your code with out modifying tcpipcomm h Please note that the XEXTENV flag can not be set in the TCP IP Connection Wizard It must be set manually Before using the XEXTENV_INC flag look carefully at the define state ments in tcpipcomm h These must be valid for proper operation of the TCP IP adapter Hint Using External env Code with the TCP IP Adapter When combining the TCP IP adapter with other environment func tions always preprocess the environment file to verify that the code is expanded as expected Example 539 External Code in Combination with the TCP IP Adapter A file called mycomm h contains declarations of functions that should be used in parallel with the TCP IP adapter From
72. n use the precompiled kernels Only the environment functions need to be written by the user PAD Functions The PAD function is called by the scheduler when its process is in turn to execute a transition The scheduler calls the PAD function with a symbol table node of the type xPrsNode pointing to the instance spe cific data of the instance that is scheduled Start Up A Light Integration starts when the generated main function is called The start up phase works like this pseudocode shown in italics void main void xMainInit Code from MAIN xMainLoop void xMainInit void xInitEnv Init of internal structures You must supply the xInitEnv function to initialize external code and hardware etc this is of course application dependent This func tion is placed in the same program module environment module as the xInEnv and xOutEnv functions The xMainLoop function con tains an eternal loop which constitutes the scheduler itself See below 3222 Telelogic Tau 4 5 User s Manual July 2003 Light Integration July 2003 void xMainLoop void while 1 xInEnv if a timer has expired send the corresponding timer signal else if aprocess can execute a transition remove the signal from the input port set up Sender in the process to Sender of the signal call the PAD function for the process Connection to the Environment Signals going in and out of the
73. nction xMain Loop SYSD A variable of type xSystemData THREAD STACKSIZE The stacksize for the thread is specified in the Deployment Edi tor HREAD PRIO The thread priority specified in the Deployment Editor HREAD MAXQUEUESIZE The maximum number of mes sages signals in the input queue of the thread as specified in the Deployment Editor This parame ter is only used if the alternate signal sending model is used 3226 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Threaded Integration Parameters Explanation THREAD _MAXMESSIZE The maximum size of a mes sage signal This parameter is ig nored at the moment in both im plementation models The maxi mum size of a message signal in the alternate signal sending mod elis always the size of the pointer to an SDL signal sizeof xSig nalNode Note Thread parameters for individual threads can be specified in the De ployment Editor If no values are specified default values will be used SDL_CREATE PROC_NAME PROC_IDNODE PROC NAME STRING This macro is used for creation of dynamic processes processes created during run time It is defined exactly the same way in Threaded as in Light It will call the SDL kernel function SDL _Create SDL_Create will create a new thread if for instance there should be one thread for each instance of an SDL process See the follow
74. ndows header files are not included on the preprocessor pass The files are included though on the compiler pass and this ensures that the preprocessed C files only contain the expanded the SDL suite macros It also helps greatly to speed up the process Note that this flag only works with the Microsoft compiler and should not be used with any other compiler XWINCE This flag allows you to compile the integration for Mi crosoft WinCE target systems This flag should not be used together with the MSC trace flags Telelogic Tau 4 5 User s Manual 3287 Chapter 65 Integration with Operating Systems Annex 4 Integration for Solaris 2 6 Introduction This annex describes briefly the Solaris 2 6 model and primitives used in the SDL Suite Solaris 2 6 tight integration The presentation is fo cused on the differences from the general model described earlier in this chapter One section describes how to set up and run a simple test example for a tight integration Note The Solaris 2 6 tight integration is fully POSIX compliant For this reason it will not work with earlier versions of Solaris Note Third party products referred to in this manual may have limitations that have impact on the usability of Telelogic Tau Please consult the supplier s support organization or the third party product s technical reference documentation for up to date information about such lim itations Principles This integration is developed using
75. ne package for the Light Integration and one for the Tight In tegration Although the files in different packages may have the same name they do not necessarily contain the same code The principles for Tight Integration packages are described more thoroughly in Tight In tegration on page 3249 Details about each operating system can be found in the annexes sdtdir simple sdt RTOS simple ssy Examples Simple bl1 sbk pr1 spr dynpr1 spr VxWorks lt other RTOS gt sctcommon h scthooks h_template sctos c INCLUDE Sctpred c sctpred h sctsdl c scttypes h SDL pidlist pr Special version for Tight Integrations sctvxworks c m VxWorks TightIntegration sctvxworks h sdt2vxworks c lt other RTOS gt Figure 562 File structure for the RTOS integrations Telelogic Tau 4 5 User s Manual 3213 Chapter 65 Integration with Operating Systems 3214 There is also an INCLUDE directory containing source files common to all supported operating systems These files are described in File Structure on page 2951 in chapter 62 The Master Library Below are some additional comments on these files e scthooks h This file contains macro hooks into the system These hooks are used for customizing a Tight Integration for example by adding ex ternal tasks See the examples to find out how this is done All the hook macros are initially e
76. obably need to edit the pro vided makefile sdtdir simple sdt i RTOS simple ssy bl1 sbk Examples pr1 spr VxWorks ISctenv c eae ___ dynpr1 spr LightIntegration makefile lt possibly links to other files gt MyExtTask c L TightIntegration Makefile scthooks h _ lt other RTOS gt lt possibly links to other files gt L INCLUDE Figure 569 File structure for the Simple example Note A VxWorks application is not allowed to contain a main function The name of the generated main is changed to root with the com pilation switch DXMAIN_NAME root 3282 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Annex 2 Integration for VxWorks Light Integration Limitations for the Light Integration Please see the Release Guide Building a Light Integration Please see the Building and Running a Light Integration on page 3268 for instructions Tight Integration Limitations for the Tight Integration Please read the Release Guide for details about limitations that apply to all systems using Tight Integration Building a Tight Integration Please see the Building and Running a Tight Integration on page 3270 for instructions Telelogic Tau 4 5 User s Manual 3283 Chapter 65 Integration with Operating Systems Annex 3 Integration for Win32 This annex briefly describes integration with Win32 The presentation is focused on the differences
77. on is the best choice especially if the system sends many signals and receives few You can generate templates for the environment functions from the SDL suite and just add code for converting between the signal represen tation and the actual environment hardware or software If interaction with the environment is complex then a Tight integration is probably the easiest to use since you only need to interface to the op erating system queues This is the case if you need process behavior in the interaction for example to establish a communications session be fore sending the signal Other cases where a Tight integration might be the best choice are e when the environment consists of many OS tasks written in other languages than SDL e when external processes send signals directly to SDL processes rather than to the SDL system in general e when there are many signals passing to and from the environment 3208 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Introduction In a Threaded integration the integration with the environment should normally be handled in the environment functions in the same way as for a Light integration It is possible though in Threaded to send signals directly to an SDL process with the SDL_Output function without in volving the xInEnv function Operating system issues If you will not use an OS at all then you have to select a Light integra tion In addition you will have to provi
78. on or the third party product s technical reference documentation for up to date information about such lim itations Principles This integration is developed with VxWorks Tornado 1 0 version and tested under VxSim version 5 3 on a Sun workstation with SunOS 4 1 4 The main differences between VxWorks and the general model are e The VxWorks msgQReceive copies the Signal into a buffer when it is received The sender makes free of the signal immediately after it has been sent and the receiver allocates a buffer signal before a receive statement e An extra optimization flag XOPTSIGNALALLOC has been introduced for the VxWorks tight integration When freeing a signal s memory we place it in an availlist so that subsequent signal memory alloca tion calls can check to see if suitable sized memory already exists which may be reused Otherwise memory is allocated as normal July 2003 Telelogic Tau 4 5 User s Manual 3281 Chapter 65 Integration with Operating Systems Running the Test Example Simple Note The source file and examples for Tight Integrations are not included in the standard delivery They are available as free downloads from Telelogic Support web site Prerequisites This test example is developed as a VxWorks Tornado application on a Sun workstation The makefile and compilation switches are set up for the application to run under an VxSim target simulator If you are using another configuration of VxWorks you pr
79. option Cadvanced must be used 3 Generate an environment header file an option in the Organizer Make dialog 4 Edit the sctenv c template file to handle your in and out environ ment signals Include the generated lt application gt ifc file the environment header file 5 Create a makefile or edit the generated makefile Write entries for the kernel source files the environment file and the application file 6 Set the appropriate compilation switches for your RTOS and your compiler 7 Compile the application and the kernel file to create a relocatable object file 8 Download Telelogic Tau 4 5 User s Manual July 2003 Threaded Integration Threaded Integration July 2003 Introduction The first part of this section is about the Threaded integration The sec ond part is about the TCP IP feature With the Threaded and TCP IP features you can partition an SDL system into several threads that can execute in a distributed environment Implementation Details for Threaded The main areas where a Threaded differs from a Light integration are e Symbol table structures and global variables e Process creation e Signal sending Symbol Table Structures and Global Variables Each thread has a global variable of type xSystemData in Threaded In Light there is only one global variable of this type for the entire system In Threaded this variable is initialized in yInit and is one of the pa rameters in the macro fo
80. ote This macro should only be used with simple datatypes where assign ments can be done using the simple assignment operator THREADED_GET_SDL_SIG_PARAM sigptr signame paramno param This macro will assign the user s param the value of the signal parame ter with the specified number Note This macro should only be used with simple datatypes where assign ments can be done using the simple assignment operator SDL_Output This is the standard SDL kernel function that should be used when send ing signal into a Threaded Application The following must be done be fore a signal can be sent from an external process thread into a Threaded Application 1 Use the xThreadedRegExtTask xThreadedRegExtTask_WithQueue function to get an SDL_PId 2 Call the SDL kernel function xGetSignal with the following pa rameters signalId Receiver Sender 3 Assign signal parameters using the API macro THREADED ASSIGN SDL SIG PARAMS 4 Call the SDL_Output function with the SDL signal For an example see Annex 6 Building a Threaded Integration THREADED_START_EXTTASK This macro is normally empty It is called after all static SDL threads are created in the THREADED AFTER THREAD START macro last in gen erated c file for application By defining this macro to user can make the application start external tasks Telelogic Tau 4 5 User s Manual 3233 Chapter 65 Integration with Operating Systems
81. queue id of the receiver s instance set is accessed through NameNode in the receiver s xEPrsStruct and the variable PROCID Example from xSDLReset InTimerProcess Err msgQSend MSG_Q ID yInSignalPointer gt Sender gt NameNode gt PROCID char yInSignalPointer sizeof xTimerHeaderRec 0 0 In this case the receiver is the same as the original sender Telelogic Tau 4 5 User s Manual 3261 Chapter 65 Integration with Operating Systems Signal sending A support function xHandle_Sig is used when sending signals instead of the macro RTOSSEND as in the Standard Model This difference is shown in bold in the code below ifdef X_ONE_TASK PER _INSTANCE_ SET define SDL _2O0UTPUT PRIO VIA SIG_NAME SIG _IDNODE RECEIVER SIG PAR SIZE SIG NAME STRING XOS_TRACE OUTPUT SIG NAME STRING XMSC_TRACE OUTPUT RECEIVER yOutputSignalPtr SIG NAME STRING xHandle Sig yOutputSignalPtr SDL_SELF SIG_PAR_SIZE RECEIVER RTOSTASK_TYPE RECEIVER gt NameNode gt PROCID RTOSHANDLESIG PAR else define SDL _2OUTPUT PRIO VIA SIG NAME SIG _IDNODE RECEIVER SIG PAR SIZE SIG _NAME STRING XOS_TRACE OUTPUT SIG_ NAME STRING XMSC_TRACE OUTPUT RECEIVER yOutputSignalPtr SIG _NAME STRING RTOSSEND SyOutputSignalPtr RECEIVER SIG PAR SIZE endif Scheduling Scheduling between instance sets is handled by the operating
82. r creating a new thread The data structure xSystemData has a couple of new entries ifdef THREADED xInputPortRec xNewSignals THREADED THREAD VARS endif The entry xNewSignals is used when a new signal is received The sig nal is first linked into the receiver s xNewSignals queue before it is handled in the receiver s xMainLoop The entry THREADED THREAD VARS is a macro that contains different thread variables like the semaphore handles xInput Port Global variables are declared in the macro THREADED GLOBAL VARS elif THREADSOLARIS define THREADED GLOBAL VARS pthread_mutex t xbListMutex Telelogic Tau 4 5 User s Manual 3225 Chapter 65 Integration with Operating Systems pthread_mutex_t xExportMutex sem_t xInitSem int xNumberOfThreads int QueueCounter int xInitPhase pthread_attr_t Attributes endif THREADED ALTERNATIVE SIGNAL SENDING endif Process Creation There are three macros related to the creation of threads in a Threaded e HREADED_START_THRI HREAD PRIO THREAD MAXQUEUESIZE THREAD MAXMESSIZE EAD F SYSD THREAD STACKSIZE This macro is used if there is only one thread to be created for all instances Instance Set of an SDL process or another SDL object The parameters are Parameters Explanation F The entry point of the thread i e the SDL kernel fu
83. rP xEPrsRec 3260 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration Instance Set Data The datatype xPrsInstanceSetVars is only used in the Instance Set Model It defines common data for all instances of the set like the save queue and the size of the instance data typedef struct xSignalHeader SaveQ xSignalHeader CurrentInSaveQ xSignalHeader yInSignalPtr char name 100 unsigned PrsDataSize xPrsInstanceSetVars PAD functions In the Instance Set Model there is a PAD function for each process in stance but also for each instance set The instance set PAD functions will be called at system start up and contain an eternal loop in the same fashion as PAD functions in the Standard Model Instance PAD func tions are only called to execute transitions Process Creation All instance sets even for dynamic processes are created at system start up Since the OS task and the signal queues are created with the in stance set the creation of an instance requires less labor than in the Standard Model For the instance set creation the macro INIT_PROCESS_TYPE is used Process Termination The instance set task is never terminated Termination of a process in stance will not remove the save queue the input queue and the task This is done at system termination All queues including the active tim er queue are emptied of messages to the terminated process though Signal queues The message
84. rs to structs holding instance data for an instance of a process or a procedure Note that some parts of the structs are OS dependent xInputAction xNotInSignalSet These defines specify the different ways of handling a signal Macros to Exclude Unnecessary Code The following macros are defined to exclude unnecessary code for IdNode variables etc define XNOSTARTUPIDNOD define XOPTSIGPARA define XOPTDC define XOPTFPAR define XOPTSTRUCT define XOPTLIT p3 3274 Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration Code Reference define XOPTSORT define XNOUSEOFSERVICE Macros to activate Signal Free Functions The following macro must be defined to activate the Signal Free Func tions This is necessary if signals and timers with string parameter dy namic allocated are used to avoid memory leaks define XFREESIGNALFUNCS If strings not are used as parameters in signals this flag should not be set cause it does lead to some performance deterioration Normally this de fine is set in the make file For timer string parameters the define define XTIMERSWITHSTRINGPARAMS must be set The following macro must be defined to activate the Signal Free Func tions This is necessary if signals and timers with string parameter dy namic allocated are used to avoid memory leaks define XFREESIGNALFUNCS Default Priorities One group of macros defines defa
85. s procedures and procedures without a state START_STATE Each state in a process and procedure is represented as an integer The Start state will always have the value 0 3276 Telelogic Tau 4 5 User s Manual July 2003 Tight Integration Code Reference Using OSE Trace Features Note Telelogic has noticed that the OSE trace feature can make the appli cation crash in some situations This seems to happen when a SDL process OSE task sends a signal immediately before terminating If you come across this problem first check if the application works correctly when generated without OSE trace July 2003 Telelogic Tau 4 5 User s Manual 3277 Chapter 65 Integration with Operating Systems Annex 1 Integration for OSE Delta Introduction This annex briefly describes the OSE Delta models and primitives used in the SDL suite OSE tight integration The presentation is focused on the differences from the OSE classic model described in the previous annex One section describes how to set up and run a simple test example in both a light and tight integration Note Third party products referred to in this manual may have limitations that have impact on the usability of Telelogic Tau Please consult the supplier s support organization or the third party product s technical reference documentation for up to date information about such lim itations Principles This integration is developed with OSE Delta Soft Kernel 3 2 and test
86. s c Most of the OS specific code is found in the scttypes h file The fol lowing macros are new for Threaded MACRO NAME Explanation THREADWIN3 2 Main macro for Threaded Win dows integration THREADSOLARIS Main macro for Threaded Solaris integration THREADVXWORKS Main macro for Threaded Vx Works integration HRAEDOSE Main macro for Threaded OSE integration THREADED_ALTERNATIVE_SIGN Main macro for using the alterna AL SENDING tive signal sending model THREADED _POSIX_THREADS Main macro for the Threaded in tegration model defining the ker nel specifics THREADED Internal macro used only in the kernel source files THREADED TRACE Enabling textual execution trace THREADED OSTRACI 5a This macro is mapped to a printf statement THREADED_ERROR Enabling textual error printout when calling OS primitives THREADED_ERROR_VAR Defines a variable used in THREADED ERROR_RESULTS Telelogic Tau 4 5 User s Manual 3229 Chapter 65 Integration with Operating Systems 3230 MACRO NAME Explanation HREADED ERROR RESULT Stores the return result after call ing an OS primitive HREADED_ERROR_REPORT Checks the value of the return variable and if ERROR makes a printout THREADED ERROR_REPORT NUL Checks the value of the return variable and if ERROR ma
87. sed together with the TCP IP feature e The Threaded model is supporting all partitioning models 1 pro cess instance 1 or many process instance set 1 or many blocks 1 en tire system mapped to one Thread e The user can easily specify Thread specific parameters like stack size Thread priority Thread message queue size and maximum message size for each Thread The Thread specific code for all supported OS is placed in one file Advantages of Tight e Simple mapping od SDL concepts to OS primitives e Simple interactions with environment at least in the default model by direct call to the OS message passing primitives e Support textual and MSC pr textual trace in console window when executing Disadvantages of Threaded e Slightly more difficult to interact with the environment An external function thread must use the SDL_Output function when sending signals to an SDL process Disadvantages of Tight e Very difficult and time consuming to support a new OS e Can only support two partitioning models e Very inefficient Timer model 3210 Telelogic Tau 4 5 User s Manual July 2003 Common Features Common Features July 2003 This section describes the parts of the integration that are common to the different models but also some important differences Note Many of the data structures and macros described in this section are described in more detail in chapter 62 The Master Library That chapter is how
88. sufficient routing information The IP and PORT variables should be set to the host address and port number IP should be declared as char and PORT as int The routing function should be implemented in a C file which is com piled and linked together with the application The server IP address should be given as char e g 255 255 255 255 dotted decimal notation or server the_company com hostname notation The server port number should be given as int e g 8888 Telelogic Tau 4 5 User s Manual 3243 Chapter 65 Integration with Operating Systems On the server side the IP address is inherent to the host that the appli cation resides on The port number on which a server should listen for incoming connections should be specified using the flag XSERVPORT Note Usage of Port Numbers Generally TCP port numbers below 1024 are reserved by operating system services or internet applications For instance the port num bers 21 and 23 are used by FTP and port number 80 is used by HT TP If a port number is occupied you will get an error message at start up and the server thread will not start It is recommended that you select port numbers larger than 1024 for your SDL application Example 537 TCP IP Adapter Routing Settings This example shows a situation where different signals should be direct ed to different recipients An SDL system is partitioned into three com ponents i e executab
89. system Within the instance sets however scheduling is based on the signal queue When the instance set PAD function is executing it takes the first signal in the input queue and calls the PAD function of the ad dressed SDL process The instance PAD function then executes one transition and returns control to the scheduling loop of the instance set PAD function Integrating with external code You can easily integrate the SDL system with external code for exam ple written in C Just use the hooks described below for inserting C statements in the main function of the SDL system The hooks are in the form of define macros located in a file called scthooks h A file called scthooks h_template with empty macros can be found in the INCLUDE directory Use this file as a template for your own application You will find usage examples in the Examples directory HOOK _GLOBAL DECLARATIONS This hook lets you declare function prototypes etc at file scope 3262 Telelogic Tau 4 5 User s Manual July 2003 Limitations for Integrations HOOK_MAIN DECLARATIONS This hook lets you declare variables for use in the main function HOOK MAIN START OF CODE Any code inserted here will execute first in the main function HOOK MAIN AFTER PROCESS RELEASE Any code inserted here will execute as soon as all static processes have been created and are allowed to run HOOK_MAIN AFTER SIGNAL RECEPTION The main function of the SDL system enters
90. system_name gt ifc Example of how to use the xFindReceiver function include scttypes h include lt system_name gt ifc include lt system_name gt hs void MyExtTask void xSignalHeader yOutputSignalPtr int Err Allocate signal header and signal parameter buffer yOutputSignalPtr xSignalHeader xAlloc sizeof xSignalHeaderRec sizeof yPDef go Setup signal header yOutputSignalPtr gt SignalCode go yOutputSignalPtr gt Sender xEnvPId Give value 100 to integer parameter yPDef_go yOutputSignalPtr 1 gt Param1 100 Send signal from environment Err msgQSend xFindReceiver go xEnvPrs 0 char yOutputSignalPtr sizeof xSignalHederRec sizeof yPDef_ go 0 0 The following types signal definitions and global variables are used in the example xEnvPId An SDL Pld representing the environment from scttypes h xEnvPrs A PrsNode representing the environment from scttypes h xSignalHeader A datatype representing an SDL signal from scttypes h Telelogic Tau 4 5 User s Manual July 2003 July 2003 Tight Integration e yPDef_go A datatype representing the signal parameter types from lt system_name gt ifc e go An SDL signal from lt system_name gt ifc The File pidlist pr An alternative way to get the PId for the Receiver is to use an ADT de fined in the ADT library called pidlist pr This file defines an ADT c
91. tegration Limitations for the Light Integration Please see the Release Guide Telelogic Tau 4 5 User s Manual 3279 Chapter 65 Integration with Operating Systems 3280 Building a Light Integration Please see the Building and Running a Light Integration on page 3268 for instructions Tight Integration Limitations for the Tight Integration Please read the Release Guide for details about limitations that apply to all systems using Tight Integration Building a Tight Integration Please see the Building and Running a Tight Integration on page 3270 for instructions How Signals are Sent to and from the Environment The signal Go is sent from an external task MyExt Task The code for this task is placed in the program file MyExt Task c This is the same as used for OSE Classic Telelogic Tau 4 5 User s Manual July 2003 Annex 2 Integration for VxWorks Annex 2 Integration for VxWorks Introduction This annex describes briefly the VxWorks models and primitives used in the SDL Suite VxWorks tight integration The presentation is focused on the differences from the general model described earlier in this chap ter One section describes how to set up and run a simple test example in both a light and tight integration Note Third party products referred to in this manual may have limitations that have impact on the usability of Telelogic Tau Please consult the supplier s support organizati
92. the xInitEnv function an initialization function should be called InitCcomm From the xInEnv function a function for polling communication ReadComm should be invoked In mycomm h the following is inserted define XENV_INIT Initcomm xInitSignalSender xInitSignalReceiver define XENV_IN START ReadComm 1 xInitsignalSender and xInitSignalReceiver are taken from tcpipcomm h which contains the following ifndef XENV_INIT define XENV_INIT xInitSignalSender xInitSignalReceiver i endif ifndef XENV_IN_STAR define XENV_IN_STAR endif The defines in tcpipcomm h are overridden Still the original calls are invoked which ensures that the TCP IP adapter executes properly Telelogic Tau 4 5 User s Manual 3247 Chapter 65 Integration with Operating Systems 3248 Using Thread Parameters Some thread parameters in the TCP IP adapter can be set to fine tune performance of your Threaded SDL application The TCP IP adapter threads do not use OS queues Two parameters can be set Thread Pri ority and Thread Stack Size These are set manually using flags They can not be set using the TCP IP Communication Wizard The server wait thread uses the following flags XSERVTHRPRIO XSERVTHRSTACK The signal receiver threads use the following flags XRECVTHRPRIO XRECVTHRSTACK Set the flags to values that are specific to the target platform used Telelogic Tau 4 5 User
93. tion between the SDL processes in an instance set task If the signal contains parameters they are allocated in the same function call Example OutputSignalPtr xAlloc sizeof xSignalHeaderRec sizeof yPDef_z05_s2 The second parameter to the xAlloc function is a struct representing the signal parameters of the signal In this case with one integer it is de fined in the following way typedef struct SIGNAL VARS SDL_Integer Param1 yPDef_z05_s2 The macro SIGNAL_VARS is in most RTOS empty There is an extra element in the SignalHeader defined as a void point er This pointer SigP is set to point to the parameter area OutputSignalPtr gt SigP OutputSignalPtr 1 Telelogic Tau 4 5 User s Manual 3251 Chapter 65 Integration with Operating Systems This pointer is used in the Signal Free Function to address the parame ter part of either a signal structure as also a timer signal structure Note The SDL signal parameters are always named Param1 Param2 etc Assignment of the signal parameter is done in generated code and not in a macro Example SIGNAL ALLOC ERROR yAssF_SDL_Integer yPDef_z05_s2 OUTSIGNAL DATA PTR gt Paraml yVarP gt z023 paraml XASS The macro OUTSIGNAL_DATA PTR macro is defined define OUTSIGNAL DATA PTR yOutputSignalPtr gt SigP After expansion of the whole expression the code will be yPDef_z05_s2 xSignalHeader yOutputSignalPtr 1 gt Para
94. to generate a Threaded in tegration Note A Threaded integration can only be generated using the Deployment Editor and the Targeting Expert i e the make feature in the Orga nizer CANNOT be used Communication and execution control in one thread is handled by the SDL kernel and not the OS kernel See Figure 559 This model shows the default Threaded integration where OS semaphores are the only OS primitives used in the signal sending The xMainLoop function is the entry point for each thread a APPLICATION LEVEL OS task in SDT Threaded OS task in SDT Threaded SDL System Partition 1 SDL System Partition 2 coe ae i we SDL Kernel SDL send I i primitive primitive Environment functions OS semaphores To protect the receiver s input queue Figure 559 Signalling in Threaded Integration SDL Kernel functions are used for sending signals within or between threads Thick borders denote threads Telelogic Tau 4 5 User s Manual 3203 Chapter 65 Integration with Operating Systems 3204 Semaphores are used frequently in Threaded to protect globally acces sible data like input queues and export queues Semaphores are also used in the start up to synchronize the execution of newly created threads We must ensure that no thread is allowed to start executing un til ALL threads have been created in the start up phase Communication with external threads Threads not made
95. ult priorities for processes and sig nals ifndef xDefaultPrioProcess define xDefaultPrioProcess RTOSPRIODEFAULT endif ifndef xDefaultPrioSignal define xDefaultPrioSignal RTOSPRIODEFAULT endif Macros to Implement SDL First in this section is a macro defining the symbol table root xIdNode xSymbolTableRoot Telelogic Tau 4 5 User s Manual 3275 Chapter 65 Integration with Operating Systems XPROCESSDEF_C and XPROCESSDEF_H These macros define the start up function for a PAD function It is this function that is called in the task creation As mentioned before this function will after some variable initializations call the PAD function The definition of the start up function varies in different RTOS that is why there is a second OS specific macro here STARTUPSIGNAL ALLOCPRSSIGNAL etc Each signal in an application is assigned a unique integer value The values 31992 through 32000 are reserved for internal signals like the start up signal Variables in the PAD Function PROCESS_VARS PROCEDURE_VARS These macros define the elements in the xPrsStruct and xPrdStruct respectively YPAD_YSVARP This macro defines a variable representing a pointer to a signal s param eter area YPAD_YVARP This macro defines the variable yvarP which represents the process in stance data LOOP_LABEL LOOP_LABEL_PRD LOOP_LABEL_PRD_NOSTATE These three macros define the eternal loop inside processe
96. xxx NEXTSTATE Idle Signal Go received in Pr1 Instancel CREATE DynPr1 1 xxx NEXTSTATE Wait Signal Go received in Pri Instance2 CREATE DynPr1 2 SET on timer t1 at 17 5580 NEXTSTATE Wait_t1 NEXTSTATE Wait SET on timer t1 at 17 5880 NEXTSTATE Wait_t1 TIMER signal was sent Timer ean Receiver DynPri 1 Now 17 5650 OUTPUT of t1 to DynPri 1 PROCEDURE START Prd doing much PROCEDURE RETURN Prd OUTPUT of terminating to Pr1 1 TIMER signal was sent Timer ae Receiver DynPri 2 Now 17 6050 OUTPUT of t1 to DynPr1 2 STOP no signals were discarded PROCEDURE START Prd OUTPUT of ok to enu 1 Parameter s Signal Ok received with the following parameter 1 xxx NEXTSTATE Wait doing much PROCEDURE RETURN Prd OUTPUT of terminating to Pr1 2 STOP no signals were discarded OUTPUT of ok to enu 1 Parameter s 2 Signal Ok received with the following parameter 2 xx NEXTSTATE Wait Figure 575 Textual SDL trace for Simple example July 2003 Telelogic Tau 4 5 User s Manual 3297 Chapter 65 Integration with Operating Systems MSC SimulatorTrace Smito tra generaeay DLSMIED 4 3 ta Bidder Ertracko Pri M EE 4 m Darr 26 process process process process Pri Pri ectrask Erak ewo EX PAZ Etras 03 Erasoa ne lt gt go e oD go process Pri f o Daris nemm Es process ngam E
97. ystem xInEnv may be used for polling hardware devices for data The code looks like this xSignalNode S static int SendGo 0 if SendGo lt 1 if SendGo 0 S xGetSignal go prif il xEnv yPDef_go S gt Paraml startinstancel else S xGetSignal go pri 2 xEnv yPDef_go S gt Paraml startinstance2 SDL Output S xSigPrioPar xDefaultPrioSignal xIdNode 0 SendGo The signal Go is sent the first and the second time xInEnv is called The parameters startinstancel and startinstance2 are integer con stants defined in the SDL system as integer SYNONyYM s They are made available by generating and including the file simple ifc The xOutEnv Function The code in xOutEnv for receiving the signal Ok looks like this if S gt NameNode ok printf Signal Ok received with the following parameter lu n yPDef_ok S gt Param1 xReleaseSignal S return The signal Ok also has an integer parameter the value of this should be 1 if it is sent by Pr1 instance one and 2 if it is sent by instance two Telelogic Tau 4 5 User s Manual 3269 Chapter 65 Integration with Operating Systems Building and Running a Tight Integration This section will take you through the general steps required to build a Tight Integration for the Simple example The procedure works the same for most operating systems Please also check the annexes for im portant in

Integration with Operating Systems

Contents

Download Pdf Manuals

Related Search

Related Contents