Transcript PR-0911167-a-AST - Indico

Linux for Real Time applications in
accelerator control systems
Linux for control systems
1
Andreas Steinbacher 16.11.09
Agenda
•
•
•
•
•
•
•
•
•
•
Why Linux?
Standard CS architecture
What is Real Time ?
What RT do we need ?
Real time Operating Systems
What parameters do we need ?
How do we test ?
The kernel module
The user program
Results
Why Linux?
• Same OS for all control system tiers
• Linux is open, you know how things tick inside,
and you can change them.
• Real Time capabilities look promising,
experience,- but no data exist within CERN.
Standard CS architecture:
Supervisory Control System
Presentation Tier (1)
Network
ProcessingTier (2)
Network
Equipment Tier (3)
Accelerator Control
System
Beam Control System
Network
Frontend Tier (4)
What is realtime?
• Soft Real Time:
• System performs not always within limits 
consequences are not catastrophic.
• System is normally „fast enough“, errors can be
detected in time.
• VOIP, Videoconferences,
• Hard Real Time:
• Crossing limits causes catastrophic consequences.
• System guaranties to be in time.
• Pacemaker, Automotive systems (ABS,ESP, Ignition)
• None Real Time:
• No limits or consequences. „postcard“
Soft Real-Time vs. Hard Real-Time:
Error
Soft RT
Latency
Error
Hard RT
Latency
What RT do we need?
Real time operating systems
• VxWorks, LynxOS, RTEMS, QNX, also: DOS .
• And many more…
http://en.wikipedia.org/wiki/List_of_real-time_operating_systems
• RT_Preemptive
„The RT-Preempt patch converts Linux into a fully
preemptible kernel.“
What parameters do we need?
• Interrupt latency -> maxlat, dist…
• Periodic tasks -> maxlat, dist, jitter
How do we test?
• Defined Scheduler - FIFO/RR
• Defined Priority – 0,10,49,90,99
• Defined Load – ltp´s loadgen
The kernel module
•
Registers an interrupt handler:
ret = request_irq(PARALLEL_PORT_INTERRUPT, &interrupt_handler,IRQF_DISABLED, "parallelport",
NULL);
•
Interrupt handler (triggered by stimulus pulse):
static int interrupt_handler(void)
{
//send signal to user program
kill_fasync(&inputdevice_async_queue, SIGIO, POLL_IN);
return IRQ_HANDLED;
}
•
ioctl - I/O control (triggered by user program)
static int skeleton_ioctl(struct inode *inode, struct file *file,
unsigned int cmd, unsigned long arg) {
….. outb_p(255, BASEPORT);outb_p(0, BASEPORT); //All high, all low
The user program
•
Registers a Signal handler
int InstallMySignalHandler(void)
{
.........
sa.sa_handler = mySignalHandler;
sigaction(SIGIO, &sa, &osa);
//register handler
return 0;
}
•
Signal Handler (triggered by kernel module)
static void mySignalHandler ()
{
ioctl(fd, CASE4, NULL);
}
//tell driver to generate a pulse
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
Results: Round trip time
SWAVE – Periodic tasks
• clock_nanosleep - high resolution sleep with specifiable
clock (ADVANCED REALTIME)
/* wait untill next shot */
clock_nanosleep(0, TIMER_ABSTIME, &t, NULL);
If the flag TIMER_ABSTIME is set in the flags argument, the
clock_nanosleep() function shall cause the current thread to
be suspended from execution until either the time value of
the clock specified by clock_id reaches the absolute time
specified by the rqtp argument, or a signal is delivered to
the calling thread and its action is to invoke a signalcatching function, or the process is terminated. If, at the
time of the call, the time value specified by rqtp is less than
or equal to the time value of the specified clock, then
clock_nanosleep() shall return immediately and the calling
process shall not be suspended.
Results: Periodic tasks RT
Results: Periodic tasks NON RT
Results: Periodic tasks
Conclusion
• From the collected data it can be said that
RT_Preemptive is not suitable for a hard Real
Time system. Even though outliners appear only
<=1 time in a million, they disqualify
RT_Preemptive from being hard RT.
• Also it can be claimed that RT_Preemptive offers
exceptional performance for periodic tasks and
IO-driven applications thus qualifying it to be
suitable for soft RT with reserves for error
avoidance or correction.
• Development side of view: It´s flexible!
• Hard RT should be delegated to hardware.
Outlook:
• Paper on RT_Preemptive performance
• Test net socket RT performance
• Create an application to reconstruct the exact MA
use – case.
End of Presentation:
The time is gone
The song is over
Thought I'd something more to say…