Real-Time Platformslu/cse520s/slides/tao.pdf · 2015-09-27 · Real-Time Platforms! Real-Time OS:...
27
Real-Time Platforms Real-Time OS: Linux Real-Time Middleware: TAO Event service Single-processor scheduling End-to-end scheduling Aperiodic scheduling Real-Time Virtualization: RT-Xen Real-Time Cloud: RT-OpenStack Real-Time Parallel Computing: RT-OpenMP 1
Transcript of Real-Time Platformslu/cse520s/slides/tao.pdf · 2015-09-27 · Real-Time Platforms! Real-Time OS:...
Real-Time PlatformsØ Real-Time OS: LinuxØ Real-Time Middleware: TAO
q Event service
q Single-processor schedulingq End-to-end scheduling
q Aperiodic scheduling
Ø Real-Time Virtualization: RT-Xen
Ø Real-Time Cloud: RT-OpenStackØ Real-Time Parallel Computing: RT-OpenMP
1
Problems with Current Approaches
2
Technical limita,ons with today’s DRE infrastructure • Stovepiped • Proprietary • Bri>le & non-‐adap,ve • Expensive • Vulnerable
Characteris,cs of DRE Systems • Network-‐centric • Stringent quality of service (QoS) demands • Resource constrained • Mission-‐cri,cal control
We increasingly rely on distributed real-‐,me & embedded (DRE) systems
Applications
Endsystem Networks
Operating System
Sensors Applications
Endsystem
Operating System
Applications
Endsystem
Operating System
Actuators
Networks
Controllers
Util
ity
Resources
Utility “Curve”
“Broken” “Works”
Applications
Endsystem Networks
Operating System
Sensors Applications
Endsystem
Operating System
Applications
Endsystem
Operating System
Actuators
Networks
Controllers
Develop & apply the new generation of distributed object computing (DOC) middleware technologies to 1. simultaneously control multiple
QoS properties & 2. improve software development
quality, productivity, adaptability, & assurability
Common Services
Distribution Middleware
Infrastructure Middleware
Domain-Specific Services
Applications
Endsystem Networks
Operating System
Sensors Applications
Endsystem
Operating System
Applications
Endsystem
Operating System
Actuators
Networks
Controllers
Common Services
Distribution Middleware
Infrastructure Middleware
Domain-Specific Services
Common Services
Distribution Middleware
Infrastructure Middleware
Domain-Specific Services
Win2K Linux LynxOS
Solaris VxWorks
Middleware
Middleware Services
Middleware Applications
MIDDLEWARE ARCH RTP
DNS
HTTP
UDP TCP
IP
TELNET
Ethernet ATM FDDI
Fibre Channel
FTP INTERNETWORKING ARCH
TFTP
21st Century 20th Century Benefits of Middleware• Highly scalable QoS• Enable new resource
management capabilities• Support common & open
technology bases • Leverage & enhance advances
in assurance & security
ResourcesU
tilit
y
Desired Utility Curve “Working
Range”
Middleware: A More Effective Approach
4
The past decade has yielded significant progress in QoS-‐enabled middleware, stemming in large part from the following trends:
• NET, J2EE, CCM • Real-time CORBA • Real-time Java • SOAP & Web Services
• The maturation of middleware standards
Hardware
Domain-Specific Services Common Services
Distribution Middleware
Host Infrastructure Middleware
Operating Systems & Protocols
Applications
• Years of iteration, refinement, & successful use
Year 1970 2005 ARPAnet
RPC
Micro-kernels
CORBA & DCOM
Real-time CORBA
Component Models (EJB)
CORBA Component Model (CCM)
Real-time CCM
DCE
Web Services
• The maturation of component middleware frameworks & patterns
Why Are We Succeeding
Application Example: Avionics
5
Key System Characteris,cs • Determinis>c & sta>s>cal deadlines • ~20 Hz
• Low latency & jiGer • ~250 us
• Periodic & aperiodic processing • Complex dependencies • Con>nuous plaMorm upgrades
• Test flown at China Lake NAWS by Boeing OSAT II '98, funded by OS-‐JTF • www.cs.wustl.edu/~schmidt/TAO-‐boeing.html
• Also used on SOFIA project by Raytheon • sofia.arc.nasa.gov
• First use of Real-‐>me CORBA in avionics • Drove Real-‐>me CORBA standardiza>on
Key Results
Goals • Apply COTS & open systems to mission-‐cri>cal real-‐>me avionics
Application Example: Hot Rolling Mills
6
Goals • Control the processing of molten steel moving through a hot rolling mill in real-‐>me
System Characteris,cs • Hard real-‐>me process automa>on requirements • i.e., 250 ms real-‐>me cycles
• System acquires values represen>ng plant’s current state, tracks material flow, calculates new seangs for the rolls & devices, & submits new seangs back to plant
Key SoPware Solu,on Characteris,cs • Affordable, flexible, & COTS • Product-‐line architecture • Design guided by paGerns & frameworks
• Windows NT/2000 • Real-‐>me CORBA
www.siroll.de
Application Example: Image Processing
7
Goals • Examine glass boGles for defects in real-‐>me
System Characteris,cs • Process 20 boGles/sec • ~50 ms per boGle
• Networked configura>on • ~10 cameras
Key SoPware Solu,on Characteris,cs • Affordable, flexible, & COTS • Embedded Linux (Lem) • Compact PCI bus + Celeron processors
• Remote booted by DHCP/TFTP • Real-‐>me CORBA
www.krones.com
CORBA ���Common Object Request Broker Architecture
Ø CORBA specificationsq OMG is the standards body
q Over 800 companies
q CORBA defines interfaces, not implementations
Ø Object Request Brokers (ORB) allow clients to invoke operations on distributed objects transparently ofq Object location
q Programming language
q Operating systemq Communication protocols and interconnect
q Hardware
8
CORBA Reference Model
Ø Client invokes operations on objects.Ø An Object =
q An interface specified by an Interface Definition Language (IDL) q Servant(s) that implements the IDL interface
9
Stubs and Skeletons
Ø Translate between platform-dependent data formats and common data representation.
Ø Generated by an IDL compiler based on the IDL interface.Ø Ensure platform/language transparency.
10
ORB Core
Ø Deliver requests to objects and responses to clientsØ Communicate using a General Inter-ORB Protocol (GIOP)
q e.g., Internet Inter-ORB Protocol (IIOP) on TCP
Ø Typically a run-time library linked to applications
11
Object Adapter
Ø Demultiplexes each incoming request to the right servant/operationØ Make the upcall to the operation
12
Limitations of CORBA
Ø Lacks QoS specification interfaces to applicationsq Applications cannot specify rate, deadline or importance
Ø Lacks QoS enforcementq Does not map task QoS specification to priorities of threads
q Contains significant priority inversion
Ø Lacks performance optimizationq Poor worst-case and average latency
13
Latencies and Priority Inversions
14
The ACE ORB (TAO)
15
Source: D.C. Schmidt, http://www.cs.wustl.edu/~schmidt/tutorials-corba.html
• Open-source Real-Time CORBA
• >> 1M SLOC
• 100+ person years of effort
• Pioneered R&D on DRE middleware design & optimization
TAO Overview
ObjectiveØ Simplify the development of distributed real-time & embedded (DRE) systems
ApproachØ Use standard techology, patterns, & frameworks
16
• Based on ACE wrapper facades & frameworks
• Available on Unix, Win32, MVS, QNX, VxWorks, LynxOS, VMS, etc.
• Thousands of users around the world
• Commercially supported by many companies • OCI (www.theaceorb.com) • PrismTech (www.prismtechnologies.com) • more coming soon… • www.cs.wustl.edu/~schmidt/commercial-‐support.html
Container
ClientOBJREF
in argsoperation()out args +
return
DII IDLSTUBS
ORBINTERFACE
IDLSKEL
Object Adapter
ORB CORE GIOP/IIOP/ESIOPS
Component(Servant)
Services
I/O Subsystem: Priority Inversions
Ø Messages are processed in FIFO order regardless of priorities
Ø Kernel has lower priority than real-time prioritiesq Processing of a high priority message in the kernel can be blocked by a
lower priority task at the application level
17
I/O Subsystem: SolutionsØ Early demultiplexingØ Prioritized kernel processingØ Map task priority to kernel thread
Ø Note: This needs kernel support
18
ORB Core: Priority InversionsØ Communication of different tasks shares a same socket connection.Ø Incoming requests are demultiplexed to threads in FIFO order.
19
ORB Core ���Priority-based Concurrency Architecture
Ø Server sets model: Each priority is processed by a separate thread.Ø A separate connection is maintained for each priority in the server ORB.
q Use buffered connections to reduce run-time overhead.
Ø Suitable for fixed priority scheduling.
20
Object Adapter: ProblemsØ Layered demultiplexing is inefficient in term of
q average latency
q worst-case latency
21
Object Adapter: SolutionsØ Perfect hashing
q Generate a hash function offlineq Computational complexity O(1)
Ø De-layered active demultiplexingq Clients obtain index to (servant, operation) ahead of time
22
Reduce Priority Inversion
Conventional ORB TAO
23
The Evolution of TAO
24
A/V STREAMING
DYNAMIC/STATIC SCHEDULING
A/V Streaming Service • QoS mapping • QoS monitoring • QoS adapta>on ACE QoS API (AQoSA) • GQoS/RAPI & DiffServ • IntServ integrated with A/V Streaming & QuO • DiffServ integrated with ORB
Real-time CORBA 1.0
Sta,c Scheduling (1.0) • Rate monotonic analysis Dynamic Scheduling (1.2) • Earliest deadline first • Minimum laxity first • Maximal urgency first Hybrid Dynamic/Sta,c • Demo in WSOA • Kokyu integrated.
25
SSL Support • Integrity • Confiden>ality • Authen>ca>on (limited) Security Service (CSIv2) • Authen>ca>on • Access control • Non-‐repudia>on • Audit
DYNAMIC/STATIC SCHEDULING
FT-CORBA & LOAD
BALANCING
FT-‐CORBA (DOORS) • En>ty redundancy • Mul>ple models • Cold passive • Warm passive
• IOGR • HA/FT integrated. Load Balancing • Sta>c & dynamic • Integrated in TAO 1.3 • De-‐centralized LB • OMG LB specifica>on
A/V STREAMING SECURITY
Real-time CORBA 1.0
The Evolution of TAO
26
NOTIFICATIONS
A/V STREAMING SECURITY
TRANSACTIONS
DYNAMIC/STATIC SCHEDULING
FT-CORBA & LOAD
BALANCING
No,fica,on Service • Structured events • Event filtering • QoS proper>es
• Priority • Expiry >mes • Order policy
• Compa>ble w/Events Real-‐,me No,fica,on Service
Object Transac,on Service • Encapsulates RDBMs • www.xots.org
Real-time CORBA 1.0
The Evolution of TAO
Acknowledgement
Slides partially borrowed from Doug Schmidt’s Real-Time CORBA tutorial.
27
