发信人: bigapple (红富士), 信区: NTM
标  题: NT for Soft Real-time Control(Backgound)
发信站: 哈工大紫丁香 (Tue Jul 25 10:58:25 2000) , 转信

Background

Deterministic Control in Hard and Soft Real-time Systems
 The issue of deterministic control and the concepts of hard and soft real-tim
e systems lie at the heart of the soft control debate. To begin the discussion
, consider a typical control system. In general, all control systems can be th
ought of as receiving input data, performing some form of processing, and then
 sending output data. The control sequence may be: 
 Started by an external event, such as an I/O scanner interrupt
 Scheduled to occur at a fixed time interval, such as once every 20 mi
lliseconds 
 Occur in a continuous loop, running as fast as possible 
 For example, the Allen-Bradley PLC-5 processor supports all three of these me
chanisms with:
 Process-Input-Interrupt task (PII)
 Selectable-Timer-Interrupt task (STI)
 Main Control Programs (MCPs) 
 Control is said to be deterministic if the controller can guarantee that proc
essing occurs within a fixed range of time. For instance, on a given controlle
r, a 20 millisecond periodic task may actually execute in 20-24 milliseconds. 
For this same task, we might also say that the scan time had a repeatability r
ange of 
4 milliseconds. The design is called deterministic if the worst-case performan
ce is known. The controller may also contain a watchdog thread to verify that 
control has occurred in the proper time interval. If the interval is exceeded 
it may fault the processor and place the I/O in its fail-safe condition.
 The rather esoteric issues of hard and soft real-time arise from the ideas of
 theoretical vs. pragmatic worst case determinism. On the one hand, hard real-
time systems attempt to guarantee worst-case performance by having tightly-con
trolled designs. The approach with hard real-time systems is to be able to the
oretically prove worst-case performance. Furthermore, in hard real-time system
s, the burdens of proof rest on the operating system as well as on the control
 applications and the I/O subsystems. 
 Even in hard real-time systems, the operating system can only guarantee deter
minism to its highest-priority real-time application task or interrupt. All ot
her tasks can be pre-empted by this highest priority task, so their determinis
m depends on both the operating system and the worst-case code path length of 
the highest priority task (worst-case time to complete programmed operations).
 This degradation of determinism cascades downward to lower priority tasks. Co
nsequently, the selection of a real-time operating system by no means guarante
es real-time system performance. There is no established standard that prevent
s virtually any existing operating system from referring to itself as real-tim
e.
  
 On the other hand, the term soft real-time system has evolved to describe con
trollers whose worst-case performance has been observed, not proven. In this c
ase, the complexity of the environment or the use of off-the-shelf components 
makes it impossible to provide a rigorous design proof. Instead, the system is
 tested in the laboratory under simulated stress, and the performance is obser
ved over a long period of time. Design confidence results by devising a repres
entative stress test that exceeds real system stress conditions and observing 
the system for a suitably long time to ensure an accurate analysis. These same
 types of tests are also required for hard real-time systems for design valida
tion. 
 In soft real-time systems, the incorporation of components not specifically d
esigned for real-time determinism may limit system performance. However, the g
oals of high performance and real-time determinism tend to be coherent, so sys
tems that were not designed to be deterministic but to be high performance, of
ten work well as in control systems. 
Understanding Deterministic Control Requirements
 In practice, no real control system provides absolute repeatability, and fort
unately, most real control processes tolerate some level of scan variability. 
Over the years, Rockwell Automation has developed a great deal of expertise in
 understanding scan time and scan repeatability requirements for various types
 of control problems. Though many applications require very tight closure, a b
road range of common applications is more tolerant of variations. Two concepts
 that are useful in understanding scan time requirements are process time cons
tants and machine cycle times.
 The theory of process time constants is derived from the discipline of contin
uous process control, and is generally associated with the proportional integr
al derivative (PID) algorithm. When modeling a system as a first order process
, you can estimate the process time constant with a simple open loop test. Giv
en a step change in the controller’s output, the time it takes for the proces
s variable to achieve 63% of its eventual lined-out response is an estimate of
 the process’ time constant. Physical processes vary dramatically in their ti
me constants. Where the speed of the high-pressure spool of an industrial gas 
turbine may have a 420-millisecond time constant response to movements in its 
fuel valve, the pH of a water treatment settler may have a 2-day time constant
 response to changes in its feed composition.
  
 A general rule-of-thumb for determining scan time requirements for process co
ntrol loops is that the maximum scan time should be no more than one-sixth of 
the process time constant. Consequently, our hypothetical industrial gas turbi
ne should be scanned at least every 70 milliseconds, while our settler may req
uire scanning only once every eight hours. Also, if written in variable time i
nterval form, the PID algorithm is actually quite robust in handling moderate 
to severe scan overruns. Infrequent overruns of more than 50% of the base scan
 rate are easily tolerated. 
 An additional consideration in PID control is the need to minimize dead time 
and dead time variation introduced in the measured value and output values man
ipulated by the PID algorithm. Extremely high-speed applications require speci
alized, tightly coupled analog modules, typically accessed directly through an
 I/O backplane. 
 Machine cycle time rules provide similar guidelines for the proper applicatio
n of discrete control applications. With discrete control, the scan time deter
mines the degree to which the input and the output events are synchronized. A 
general rule of thumb is that scan time variations should not exceed 5% of the
 machine’s cycle time. For many machines this may require fast, dedicated con
trollers, however, many machines have less severe requirements. Additional com
plexity may be involved when large interposing relays, solenoid valves, or oth
er electromechanical devices introduce delays in the control action. These req
uirements vary significantly with application type. 
General PLC Performance Capabilities
 Another useful way to understand control system requirements is to look at th
e capabilities of modern controllers. Programmable Logic Controllers (PLCs) ha
ve been in use for more than two decades, continually evolving to incorporate 
the rapid improvements in microprocessor technology. Today PLC processors typi
cally can support scan times in the 5-10 millisecond range, with scan repeatab
ility ranges of 1-4 milliseconds (depending on the PLC model) for selectable-t
imer-interrupt style tasks. Dedicated PLC processors can provide even faster s
can times for special applications. Certain modern PLC processors also support
 “interrupt” tasks, such PII of the PLC-5 processor, typically that enables 
a program to detect and act on an event within 0.5 to 2.0 milliseconds.
  
 Performance characteristics of PLC processors depend on architectural and app
lication factors. The controller’s interrupt activity for servicing system ti
mers and communication interfaces impacts scan repeatability. Other intermitte
nt events that impact repeatability include:
 Processing serial input 
 Handling keypad entry 
 Performing error handling for communications 
 Servicing network requests 
 Performing controller housekeeping
 The design of the PLC application code can also impact scan repeatability. PL
C processors that support conditional branching, looping and subroutine calls 
will have variable code path lengths that lead to natural variations in scan t
imes. Typical scan times for large real-world PLC applications range from 15-1
00 milliseconds. Less time critical MCP-style tasks often tolerate scan time v
ariations of 25-50 milliseconds. For many PLC applications and simple General 
Motion Control (GMC) applications, these performance variations do not present
 a problem. 
 For higher-speed applications, STI-style tasks and/or small dedicated PLC pro
cessors are more prudent selections. These applications usually contain relati
vely simple programs and require tight coupling to their I/O hardware. In addi
tion, there are certain applications that either require better performance th
an can be provided by general purpose PLC processors. Three such application a
reas are: 
 advanced applications of General Motion Control (GMC)
 many applications of Computer Numeric Control (CNC)
 high-speed coordinated drive control
 In addition to the controller, the I/O modules, adapters, racks, and cabling 
are key components of all control systems that impact scan times and repeatabi
lity. Many I/O systems can introduce scan time and repeatability issues that e
xceed those seen in the controllers. For example, a 10Mbps Ethernet™-bas
ed 
I/O system that uses a master/slave protocol to scan networked I/O adapters wi
ll typically have 8-10 millisecond round-trip scan times. One source of scan t
ime variation in this system would be recovering from a transmission error det
ected by a cyclic redundancy check (CRC) for packet integrity. Even if the req
uest succeeds in one retry, it introduces 8-10 milliseconds of variability in 
the I/O processing scan.
  
System Integrity and Fail-safe I/O Operations
 Beyond deterministic performance, three other critical issues impact the safe
 use of any control system: 
 System integrity 
 Rapid fault detection
 Guaranteed fail-safe I/O operations
 During normal operations, control scanning occurs with some typical pattern o
f variation. However, it is absolutely critical that the I/O enters the select
ed fail-safe output state should any of the components in a control system fai
l. Since there are many potential failure modes for each of the control system
’s components, this is a very non-trivial exercise.
 Key failure modes of a controller include: 
 halting (by executing corrupt or defective code)
 power supply failure 
 receiving a non-maskable interrupt (NMI) due to a memory parity error
 
 binding in an infinite loop (by executing corrupt or defective code) 
 generating an unexpected processor exception (by executing corrupt or
 defective code) 
 To improve system integrity, PLC processors are designed to do extensive syst
em integrity checks continuously and during their housekeeping cycles so they 
don’t continue to run after a component failure. Processor exception-handling
 traps many of these failure modes. Typically, PLC systems generate a critical
 fault (i.e., the red light fault of the PLC-5 processor) in response to these
 types of exceptions.
 Additionally, the I/O interface scanners must be designed to reliably detect 
when the PLC processor fails and place their outputs in the fail-safe conditio
n. Controller failure detection is usually performed using a watchdog timer, w
hich is located in the I/O interface scanner module, that must be periodically
 reset by the controller to maintain I/O operations. This is not enough. Becau
se the I/O interface scanner module may also fail the I/O link adapters must a
lso have watchdog timers for the I/O interface scanner. 
 Since the failure modes of the control processor include immediate halting, t
he I/O subsystem cannot depend on any action from the PLC processor to help it
 determine when to go fail-safe. All microprocessors can potentially clear/dis
able interrupts and halt if they execute corrupt code in a privileged mode. Si
nce stack corruption prior to a return instruction can vector the processor an
ywhere within the kernel, misaligned code may be executed and the processor ma
y simply halt.
  
Summary
 This section of the paper has provided some background and context informatio
n for understanding control system requirements and for assessing the performa
nce, design, and reliability of the Windows NT operating system. When we later
 discuss the performance results we achieved with the Windows NT operating sys
tem, we will be able to discuss them within the context of actual control syst
em requirements and to compare them with actual PLC capabilities as a benchmar
k for deterministic control. In addition, we covered some key issues regarding
 system integrity and fail-safe I/O operations that are every bit as important
 in assessing the Windows NT operating system for “soft” real-time performan
ce. 
 In the next section, we present the test results of the Windows NT operating 
system in detail and general conclusions about t

--
※ 来源:．哈工大紫丁香WWW bbs.hit.edu.cn. [FROM: 203.123.2.2]