However, the telemetry thread performs two operations
that are not RT-safe:
The prototype SMM application was run on Newmonics PERC on a Standard PC Intel Pentium III 1 GHz microprocessor. The connection to the Model was provided by a Me2600i PCI-Card by Meilhaus Electronic GmbH. The Me2600i was used for A/D and D/A conversions. No data storage system like hard disk drive was used, so everything was directly loaded into memory.
Back To Top, Back to Real-Time Java Project Home
On the target PERC is running on VxWorks 5.4. It has to be stressed that, at the time of writing, PERC is not compatible to VxWorks 5.5.
Back To Top, Back to Real-Time Java Project Home
The following components in the prototype application are mode-dependent:
The first three components have the following three modes:
Their modes are slaved to the mode of a mission mode manager. This ensures that their mode changes are synchronized.The SBY mode is the default mode entered immediately after start-up. In SBY, the application processes telecommands and generates telemetry. There is no closed-loop control of the swing mass speed or position. In RUN_SPEED mode the right-hand disk's speed is controlled and in RUN_POSITION mode its position is controlled.
The telemetry manager has the following two modes:
The telemetry manager cyclically alternates between these two modes. To each mode, there corresponds one telemetry layout. TM_FMT1 is the default mode entered after start-up.
There are no mode change actions associated to the mode managers with the exception of the system mode manager that, upon entry into the RUN_POSITION mode, sets the value of the reference equal to the value of the position sensor.
The secure switching between the modes eg. from RUN_SPEED mode to RUN_POSITION mode is solved by the SMM GroundStationSimulator.
Back To Top, Back to Real-Time Java Project Home
Back To Top, Back to Real-Time Java Project Home
The recovery action associated to the above checks is always the same: system reset recovery action.
Back To Top, Back to Real-Time Java Project Home
The following recovery strategies are associated to the RUN modes:
The two recovery actions are linked together and the first one is executed first.
Back To Top, Back to Real-Time Java Project Home
A telecommand is sent by the ground station simulator as a telecommand string that contains 3 or more integers. The interpretation of these integers is as follows:
The telecommand string is sent to the target PC over the FTP socket. It is received by the telecommandReceiver thread that loads it into the telecommand loader. The telecommand loader decodes the string and dynamically instantiates a telecommand component to execute the telecommand. Note that the telecommand loader is activated in the non-real-time part of the application (it is activated by the telecommandReceiver thread) and therefore the poor timing predictability of the memory allocation operation does not pose problems. The memory associated to a telecommand object is automatically released by the PVM (PERC VM) garbage collector. Note that in the PERC implementation of the JVM, operation of the garbage collection is compatible with real-time operation. After the telecommand loader has constructed a new telecommand objects, it loads it into the telecommand manager which is then responsible for executing it.
Back To Top, Back to Real-Time Java Project Home
Telemetry data are sent by the telemetry manager to a telemetry stream component. In the case of the prototype application, the telemetry stream writes the telemetry data to an integer array which acts as a telemetry buffer. From an implementation point of view, two TM buffers are maintained: the active and the idle buffer. The active buffer is the one which is being filled in by the telemetry manager. The idle buffer is available for forwarding to the ground station simulator. The telemetry stream toggles between these two buffers: when it has finished writing one frame to the currently active buffer, it makes the idle buffer into the active buffer and vice-versa.
The forwarding of the TM buffer data to the ground station simulator is done by a dedicated active component - the tmSender component - which is activated by a dedicated thread - the telemetryThread (see scheduling approach). When it is activated, the tmSender component retrieves the idle buffer from the telemetry stream component and processes it. Since the telemetry stream and the tmSender components should never be operating on the same TM buffer, the tmSender replaces the TM buffer it retrieves from the telemetry stream with a new and empty buffer. Note that the tmSender is activated by a non-RT thread.
In summary, the TM buffers are being filled by a RT task but are flushed by a non-RT thread. This separation is necessary because the flushing of the TM data to the ground station simulator is not compatible with RT operation (it contains for instance dynamic memory allocation operations and the data are sent to the ground station simulator over a public network where delays are possible). Hence, the possibility exists that some TM frames be lost but the RT task is protected from interference by the non-RT thread.
The telemetry buffer is assembled by the telemetry stream component as an array of integers with the following format:
The telemetry buffer is sent by the tmSender component as a string with the following format: the string contains the elements of the TM buffer separated by blank characters and is terminated by a <new line>.
Back To Top, Back to Real-Time Java Project Home
The first manoeuvre is useful immediately after entry into one of the RUN modes when the swing mass speed or position must be brought to a target value. The second manoeuvre can be launched by telecommand at any time while beeing in one of the two RUN modes.
Back To Top, Back to Real-Time Java Project Home
Back To Top, Back to Real-Time Java Project Home
Two actuators are present in the target control system:
Neither the sensors nor the actuators are redundant.
Back To Top, Back to Real-Time Java Project Home
Back To Top, Back to Real-Time Java Project Home
Except for the unit manager, all other active components are instantiated only once. Two instances of the unit manager are instead used. The first instance, the sensor unit manager, is used to acquire the measurements from the application sensors. The second instance, the actuator unit manager , is used to send the actuation commands to the application actuator and to the disturbance.
The control cycle for the prototype application has a fixed period with duration of 200 milliseconds. The only scheduling constraints that apply to the scheduling of the above active components are as follows:
In view of the above and in view of the capabilities of the PERC run-time system, the scheduling approach selected for the prototype application is articulated over the following five real-time threads:
All five tasks have fixed priorities: the periodic tasks have the priotity they got from timer with which they are implemented. The telemetry thread has priority 7 and telecommand thread has priority 6. It is supposed that the periodic tasks have all priority 10 since their priority can not be set and the applications runs properly also with higher priorities for telemetry and telecommand threads but there is no proof of it. The PERC run-time systems schedules threads using a fixed priority scheduler with pre-emption and priority inheritance. For equal priorities round robin scheduling is used. The priority level of 10 is the highest in the PERC system and ensures that a thread is only pre-empted by other threads of priority of 10 by using round robin. Note that on VxWorks round robin can be disabled for the PERC run-time system.
The basic idea of the proposed scheduling scheme is that all operations that require timing determinism are performed in the (high priority) periodic tasks, implemented as timertasks at fixed rate in a timer, whereas the (lower priority) telemetry and telecommand threads are used for operations that are not RT-safe. In particular, the management of the TCP/IP socket that supports the TM/TC link is performed in the telemetry and telecommand threads. In order to ensure that there is no disruption of the scheduling of the periodic threads, the interaction between them and the telecommand and telemetry threads is kept to a minimum and is tightly controlled to ensure that potentially blocking calls that are performed from the telemetry/telecomand threads on objects that are used by the periodic threads have a predictable and limited blocking time.
The PeriodicTask_1 is released first and triggers the sensor unit manager component.
The PeriodicTask_2 defines the control cycle for the prototype application. Its main function is to trigger the following framework active components (in the order in which they are listed):
The PeriodicTask_3 is triggered by the timer as the last task every period. Its function is to trigger the actuator unit manager component.
The triggering of all periodic tasks is done every period by the timer.
The TelemetryThread runs with a lower priority than the periodic tasks and its function is to send the telemetry buffer to the ground station simulator through the FTP socket. This is done by activating the TmSender active component (see telemetry policy above). Ideally, the telemetry thread should be activated immediately after the periodicTask_2 has completed and should complete before periodicTask_3 begins. This would ensure an orderly forwarding of TM data: the telemetry manager (which is activated by periodicTask_2) fills in a TM buffer which is then emptied by the telemetry thread. This ideal case is illustrated in the figure:
Hence, the possibility exists that the telemetry thread will not finish before the periodicTask_3 is ready to start. In such a case, the PERC scheduling mechanism ensures that the telemetry thread is pre-empted and that periodicTask_3 is executed. The telemetry thread will resume execution as soon as possible. This may cause one TM buffer not be forwarded to the ground station (loss of one frame of telemetry).
The synchronization between the periodic tasks and the telemetry thread is performed as follows. The telemetry thread goes to sleep on a call to wait after it has forwarded one TM frame. It is awakened by periodicTask_2 that sends it a notify signal after executing all its functionality managers.
The TelecommandReceiver thread runs with the lowest priority and can be preemted by every other task. Its function is to collect telecommands from the TCP/IP socket. Whenever it is awakened, it checks whether a new telecommand has been received and, if so, it loads it into the telecommand loader (see the telecommand policy above). The telecommand loader will dynamically create an object to encapsulate the telecommand and will then load it into the telecommand manager. The telecommand receiver then goes to sleep for a period of 200 milliseconds. It would also be possible to let the telecommand thread running all the time but since the period is only 200 milliseconds it does not make sense to let it run all the time because the telecommands of the ground station simulator are operated by hand. The telecommand receiver thread runs completely asynchronously from all other application threads. If the ground station sends two telecommands in between two successive awakenings of the telecommand receiver thread, the earlier of the two telecommands will be lost. Processing of telecommands could be made more deterministic by linking its release to the end of PeriodicTask_2 and by raising its priority to the same level as the periodic Tasks.Note that the PERC run-time system creates an additional thread to run the garbage collector which priority can also be set while the garbage collector is not disabled in the PERC VM. This thread normally runs in the background with lowest priority. However, if a task makes a request for a memory allocation that cannot be serviced due to a lack of free memory, the garbage collector is invoked with a priority equal to that of the calling task. Finally, when PERC VM is running under the control of a remote terminal (as would be the case for testing), two additional threads are created by the run-time system to manage the debugger connection to the remote terminal.
Finally, it must be stressed that the implementation proposed above relies on the Timer class for the periodic tasks and the standard Java sleep service for the other threads. The periodic tasks running on the timer are not pre-emted using round robin and the triggering time of single tasks can only be called "around" the wanted start time but there is all in all no time shift.
Note that PERC provides no other constructs to implement periodic threads Java provides by the Thread class and the Timer class, but it has to be stretched out that there is a special sleep service provided by PERC using milli- and nanoseconds as parameters. This service is not used for the telecommandThread since there is no such time accuracy needed for this thread.
Back To Top, Back to Real-Time Java Project Home
| PERC SMM | Hello World | "naked" PVM | |
| Memory with static linking of native methods | 10937 kBytes | 9445.3 kBytes | 9444 kBytes |
In order to appreciate the figures in the table, one has to bear in mind
the Java execution model implemented by PERC. This is illustrated in the figure:
The Java class files are ROMized to an image file and linked with the JVM. Before generating the image, the ROMizer compiles the class files into native code. There are two possibilities to link the native methods. One is to link it statically into the executable module or to load them directly into VxWorks and link them dynamicly. Since there is no data storage system used only static linking was available.
The figures in the table indicate that the basic PERC run-time system takes about 9 MBytes. An interesting observation can be made when linking the executable module (application + PVM) directly into VxWorks while generating the VxWorks image instead of loading it during runtime. Then the whole system (application + PVM + VxWorks) occupies 8.12 MBytes. The application-specific code for the prototype SMM application takes a little less then 1.5 MBytes when loading it during runtime.
For the CPU measurements a special measurement application using most of the
classes used in the original application was created. There are only two other
classes used: TimeVxPercSmm_1 is used instead of
PercSmmTimer_1 as the main class and also a
special instantiator class is used. Both classes
can be found in the same packages in which the original application classes are.
Note that changes only valid for the time measurements have to be done in the
framework. Once changed, the original SMM application is not runnable anymore,
so make sure to make backup copy before changing the framework. All needed
changes are described in the documentation of TimeVxPercSmm_1
class. The measurement application performs measurements for every single
managerfunctionality with the exception that failure detection and failure
recovery are performed together because of there strong connection.
Measurements can be performed for the idle and the worst case by calling the
manager as an application parameter. Most of the time, a second parameter has to
be provided that describes the number of iterations the manager shall be called.
In certain cases the number of iterations is not needed or the connection to the
ground station simulator is demanded (see table below). Following combination
can be performed:
|
name parameter |
iteration parameter | Ground Station demanded | Description |
| sensor | YES | NO | PeriodicTask_1 |
| actuator | YES | NO | PeriodicTask_3 |
| controllerSBY | YES | NO | controller of SBY mode |
| controllerPOS | YES | NO | controller of RUN_POSITION mode |
| controllerSPEED | YES | NO | controller of RUN_SPEED mode |
| failureIdle | YES | NO | detection and recovery |
| failureWorstCase | YES | NO | detection and recovery |
| manoeuvreIdle | YES | NO | no manoeuvre |
| manoeuvreRamp | YES | NO | generating ramp manoeuvre |
| manoeuvreWave | YES | NO | generating wave manoeuvre |
| periodicTask2 | YES | NO | PeriodicTask_2 idle |
| telecommandIdle | YES | NO | telecommand manager, idle |
| telecommandWorstCase | YES | NO | telecommand manager, worst case |
| telemetryIdleShort | YES | NO | telemetry manager, first telemetry format |
| telemetryIdleLong | YES | NO | telemetry manager, second telemetry format |
| telemetryWorstCaseLong | YES | NO | telemetry manager, worst case |
| telemetrySendIdle | NO | YES | TelemetryThread idle |
| telemetrySendWorstCase | NO | YES | TelemetryThread worst case |
| telecommandReceive | YES | YES | TelecommandThread |
The results of all worst case measurements of the tasks are listed in the
table below:
|
PeriodicTask_1 |
75.1 us |
| PeriodicTask_2 | 333.4 us |
| PeriodicTask_3 | 26.8 us |
| TelemetryThread | 800 us |
| TelecommandThread | 50 us |
Note that the worst case measurements of PeriodicTask_2 are summarized of the worst case measurements of all its managers. There are no tools for computing the worst case execution times of a Java applications provided by PERC.
Back To Top, Back to Real-Time Java Project Home
The software for the application-specific part of the SMM Application is organized as a single package called PercSmmApplication. The structure of this package mirrors that of the RtjAocsFramework package that contains the framework code proper. For instance, package RtjAocsFramework has a subpackage AocsData that contains the classes required to support the AOCS Data concept. Package PercSmmApplication has a subpackage with the same name that contains the classes that implement the application-specific AocsDataPool for the SMM application.
It has to be stressed out that the FrameworkConfiguration class in the RtjAocsFramework.Factories package is also application specific.
In accordance with the testing concept proposed for the framework, two application executables can be generated from the PercSmmApplication. The first one is the executable to be downloaded to the PERC target. Its main class is PercSmmTimer_1 (there is also an executable to be downloaded to the PERC target where all tasks are implemented with threads instead of using timer. It is called PercSmm_1). The second executable is used for the system-level testing in the desktop environment. Its main class is TestSmm_1. These two applications are kept as similar as possible. The only differences are:
Back To Top, Back to Real-Time Java Project Home