The SMM is a standard laboratory equipment for testing control algorithms with hardware-in-the-loop. It consists of two rotating disks connected with a torsional spring. The objective of the control action is to control the speed and angular position of the right-hand disk by acting on the left-hand disk. The system actuator is the electric motor that drives the left-hand disk and that can control both its position and its angular speed. The system sensors are position and angular speed sensors on the right-hand disk. A second motor is available that can apply a torque to the right-hand disk to simulate the presence of a disturbance torque.
In the configuration used for the instantiation of the RT Java Framework, the SMM is used as a single degree of freedom system where the angular speed of the right-hand motor is used to control the speed of the left-hand disk. The left-hand motor is not used.
In this project, a prototype SMM application was instantiated to control the SMM based. Initially, this prototype SMM application was instantiated to run on the JBed RT Java implementation. This page describes the characteristics of this application (the instantiation procedure is as described in another page). In the winter 2002, Alex Blum as part of his graduation project for ETH generated a second version built upon the PERC RT Java implementation. This demonstrates the compatibility of the AOCS Framework with two different run-time systems. At application level, the PERC version of the SMM application differs from the Jbed version in its mode architecture and scheduling approach and it therefore demonstrates the flexibility of the AOCS Framework in generating applications with different characteristics.
The prototype SMM application was built upon Esmertec's JBed running on a RPX Lite board mounting a PowerPC 823 microprocessor. The hardware set-up is shown in the figure:
The item on the left is the PowerPC board. The item on the right is a board with an A/D and D/A converter that was used to interface the PowerPC board to the SMM actuator and sensor.
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 two modes:
Their modes are slaved to the mode of a mission mode manager. This ensures that the 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 not closed-loop control of the swing mass speed.
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 controller mode manager that, upon entry into RUN mode, loads a Ramp Profile manoeuvre.
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 strategy is associated to RUN mode:
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 Jbed board over the FTP socket. It is received by the telemetryReceiver 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 telemetryReceiver 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 Jbed garbage collector. Note that in the Jbed 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 thread (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 buffer 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 manoeuvres is useful immediately after entry into RUN mode when the swing mass speed must be brought from zero to a target value. The second manoeuvre can be launched by telecommand at any time while in RUN mode.
Back To Top, Back to Real-Time Java Project Home
Back To Top, Back to Real-Time Java Project Home
Only one actuator is present in the target control system:
Neither the sensor nor the actuator 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 sensor. The second instance, the actuator unit manager , is used to send the actuation command to the application actuator.
The control cycle for the prototype application has a fixed period with duration of 1 second. 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 Jbed run-time system, the scheduling approach selected for the prototype application is articulated over the following four real-time threads:
All four tasks have fixed priorities: priority 10 for the periodic tasks and priority 5 for the telemetry and telecommand threads. The Jbed run-time systems schedules threads using a fixed priority scheduler with pre-emption and priority inheritance. The priority level of 10 is the highest in the Jbed system and ensures that a thread is never pre-empted.
The basic idea of the proposed scheduling scheme is that all operations that require timing determinism are performed in the (high priority) periodic threads 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 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 thread 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_2 thread runs with a period of 1 second but its release instant is 800 ms after the release instant of periodicTask_1. Its function is to trigger the actuator unit manager component. The periodicity of activation is achieved using the same mechanism based on the Java sleep service used for periodicTask_1.
The TelemetryThread thread runs with a lower priority than the periodic threads 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_1 has completed and should complete before periodicTask_2 begins. This would ensure an orderly forwarding of TM data: the telemetry manager (which is activated by periodicTask_1) 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 stream will not finish before the periodicTask_2 is ready to start. In such a case, the Jbed scheduling mechanism ensures that the telemetry thread is pre-empted and that periodicTask_2 is executed. The telemetry thread will resume execution in the next period. 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_1 that sends it a notify signal after executing all its functionality managers.
The TelecommandReceiver thread runs with a lower priority than the periodic threads and 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 1 second. 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 PeriodicTask_1 and by rasing its priority to the same level as the PeriodicTask_1 and PeriodicTask_2.Note that the Jbed run-time system always creates an additional thread to run the garbage collector. 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 Jbed 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 standard Java sleep service to activate the periodic threads. This mechanism is known to be unsafe because of the possibility of preemption between the time when the calling thread computes the sleep interval and the time when it actually makes the call to method sleep. The ideal solution to this problem is to have a sleep_until method. This is however not provided by Jbed. As an alternative solution, the two periodic threads were run with priority 10 which is the highest priority foreseen by Jbed and that ensures that they are never pre-empted.
Note that Jbed provides primitive constructs to implement periodic threads (through the Task class that extends the Thread class). This mechanism was tried but various implementation problems were encountered and eventually it was decided to revert to standard threads.
Back To Top, Back to Real-Time Java Project Home
| Jbed SMM | Hello World | |
| Memory with reflection and dyn. loading | 1700 kBytes | 1080 kBytes |
| Memory with no reflection and dyn. loading | 938 kBytes | 615 kBytes |
| Memory with no reflection and no dyn. loading | 522 kBytes | 194 kBytes |
In order to appreciate the figures in the table, one has to bear in mind
the Java execution model implemented by Jbed. This is illustrated in the figure:
The Java class files are compiled to native code and linked with the JVM. Two basic linker options affect the memory requirements of an application. The noreflect option determines whether reflection information is included in the executable module. The data in the table shows that its inclusion can nearly double memory occupation. Its benefit is the possibility of using the Java meta-language facilities. The second option concerns the inclusion of the module to perform dynamic class loading. As shown by the table, these modules take about 400 kBytes.
The figures in the table indicate that the basic Jbed run-time system takes less than 200 kBytes. This figure excludes reflection and dynamic loading which would typically not be used in an on-board system. The application-specific code for the prototype SMM application instead takes a little over 300 kBytes (excluding again reflection and dynamic loading). These figures are not very different from those that would be expected if the application had been coded in C++.
CPU measurements were made on each thread (see
description of scheduling policy above). The execution time for one
single cycle for each thread was computed and the results found are:
|
PeriodicTask_1 |
10-15 ms during normal operations, peaks of up to 26 ms during manoeuvre executions and when there is mode change |
| PeriodicTask_2 | 1 ms |
| TelemetryThread | 10-17 ms depending on the amount of TM data |
| TelecommandThread | 1 ms |
The measurements were made with the application running on a PowerPC 823 processor at 66 Mhz. Note that there are no tools for computing the worst case execution times of a Java applications and the above values were derived from observation of a large number of measurements.
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 JbedSmmApplication (this can be downloaded with the framework software). 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 JbedSmmApplication has a subpackage with the same name that contains the classes that implement the application-specific AocsDataPool for the SMM application.
In accordance with the testing concept proposed for the framework, two application executables can be generated from the JbedSmmApplication. The first one is the executable to be downloaded to the Jbed target. Its main class is JbedSmmApplication. The second executable is used for the system-level testing in the desktop environment. Its main class is TestSmmApplication. These two applications are kept as similar as possible. The only differences are:
Back To Top, Back to Real-Time Java Project Home