Software and Hardware Codesign For Defense Embedded Systems

Software and Hardware Co-design For Defense Embedded Systems S. Umamaheswaran Member (Senior Research Staff) Central Research Laboratory Bharat Electronics Limited. , 1

Overview § What Is an Defense Embedded System? § COTS for Defense Embedded Systems § Software and Hardware Co-Design § RTOS Options 2

Defense Embedded System 3

What Is an Defense Embedded System? § Defense Embedded Systems § Application-specific systems which contain hardware and software tailored for a particular task and are generally part of a larger system (e. g. , Handheld Computer, man pack Radio, radar) Hand Held Computer STARS V 5 W FH RADIO Low Flying Detection Radar ( INDRA II) 4

Characteristics § Application specific - Optimize for cost, area, power, and performance § Digital signal processing - Signals are represented digitally § Reactive - Reacts to changes in the system’s environment § Real-time - Compute certain tasks before deadline § Include requirements that span: § Performance , Reliability , Maintainability, Security 5

GIG - An Example of Defense Embedded System § “Will provide the joint and coalition war fighter with a single, endto-end information system capability… allowing users to access shared data and applications regardless of location, and is supported by a robust network/information-centric infrastructure. ” 6

Defense Embedded Systems: Complexity Issues § Complexity of embedded systems is continually increasing § Number of states in these systems (especially in the software) is very large § Description of a system can be complex, making system analysis extremely hard § Complexity management techniques are necessary to model and analyze these systems § Systems becoming too complex to achieve accurate “first pass” design using conventional techniques § New issues rapidly emerging from new implementation technologies 7

Design Challenges § Low cost § Mixed digital/analog requirements § Light weight § Shrinking time-to-market § Reliability § Short product lifetime § Low power § Real-time processing § Portable § Inherent concurrency § Complexity § HW/SW co-design § Secure § Ease of use 8

Research Topics in Defense Embedded Systems § Power Management § Battery life, reliability and thermal issues, energy harvesting § Coupled with sensor networks § HW/SW co-design, very limited information processing and computing § Energy management § Adaptation to Applications and Environment § Reconfigurable and adaptive Systems § Embedded Software § Security in Embedded Systems § physical attack § Attack through network 9

COTS 10

COMMERCIAL OFF-THE-SHELF (COTS) § Implementation of commercially available technologies for traditionally customized applications § Examples: § Military § Industrial § Space § Applies to Hardware and/or Software 11

COMMERCIAL OFF-THE-SHELF (COTS) § Examples: Software: § Operating Systems (UNIX, Windows/NT, OS 2) § Databases (Oracle, Sybase) § Graphics Packages (GIS) Hardware: § § Busses (VME, PCI, c. PCI, CAN) Processors (TI, Motorola, HP, Sun, Intel) Disk Drives (Western Digital, Red Rock) Peripherals 12

COMMERCIAL OFF-THE-SHELF (COTS) § COTS vs. Custom Advantages: § § § Cheaper (large quantity production) General Purpose (more flexible for different applications) Shortens design-to-production cycles Large user base generally uncovers design defects early Provides current technology solutions Emerging technology tends to be backward compatible with legacy products (allows solutions to advance with technology) § Avoids binding solution to single hardware/software source 13

COMMERCIAL OFF-THE-SHELF (COTS) § COTS vs. Custom Disadvantages: § May not be suitable for all applications: § § § Highly deterministic performance may require special operating system Environmental constraints (temperature, radiation exposure, corrosive exposure) Packaging (size, weight, shape) § Reliability: § May not meet reliability requirements of mission critical systems (flight control, weapons direction, medical equipment) § Obsolescence: § COTS binds user to market trends - critical components may become unavailable and impossible to reproduce 14

COMMERCIAL OFF-THE-SHELF (COTS) § Issues and Considerations when using COTS • Supporting, maintaining, and upgrading systems with long life-cycles (10+years) • Licensing and Data Rights § COTS Software is usually distributed under license (a peruser fee is typical) § COTS documentation is normally copyrighted - distribution as part of another product usually requires special arrangements and a copy fee § Software source code and designs for hardware usually proprietary and protected by copyright or patent - even after it is no longer distributed 15

Co-Design 16

Co-design Definition and Key Concepts § Co-design § The meeting of system-level objectives by exploiting the trade-offs between hardware and software in a system through their concurrent design § Key concepts § Concurrent: hardware and software developed at the same time on parallel paths § Integrated: interaction between hardware and software development to produce design meeting performance criteria and functional specs 17

Motivations for Co-design § Factors driving co-design (hardware/software systems): § Instruction Set Processors (ISPs) available as cores in many design kits (386 s, DSPs, micro controllers, etc. ) § Systems on Silicon - many transistors available in typical processes (> 10 million transistors available in IBM ASIC process, etc. ) § Increasing capacity of field programmable devices - some devices even able to be reprogrammed on-the-fly (FPGAs, CPLDs, etc. ) § Efficient C compilers for embedded processors § Hardware synthesis capabilities 18

Motivations for Co-design § The importance of co-design in designing hardware/software systems: § Improves design quality, design cycle time, and cost § Reduces integration and test time § Supports growing complexity of embedded systems § Takes advantage of advances in tools and technologies § § § Processor cores High-level hardware synthesis capabilities ASIC development 19

Categories of Co-design Problems § Co-design of Defense embedded systems § § Usually consist of sensors, controller, and actuators Are reactive systems Usually have real-time constraints Usually have dependability constraints § Co-design of ISAs § Application-specific instruction set processors (ASIPs) § Compiler and hardware optimization and trade-offs § Co-design of Reconfigurable Systems § Systems that can be personalized after manufacture for a specific application § Reconfiguration can be accomplished before execution of concurrent with execution (called evolvable systems) 20

Components of the Co-design Problem § Specification of the system § Hardware/Software Partitioning § Architectural assumptions - type of processor, interface style between hardware and software, etc. § Partitioning objectives - maximize speedup, latency requirements, minimize size, cost, etc. § Partitioning strategies - high level partitioning § Scheduling § Operation scheduling in hardware § Instruction scheduling in compilers § Process scheduling in operating systems § Modeling the hardware/software system during the design process 21

A Model of the Current Hardware/Software Design Process DOD-STD-2167 A HW Development System Concepts Sys/HW Require. Analysis Sys/SW Require. Analysis Hardware Require. Analysis Prelim. Design Detailed Design HWCI Testing Fabric. System Integ. and test Software Require. Analysis SW Development Prelim. Design Detailed Design Coding, Unit test. , Integ. test Operation. Testing and Eval. CSCI Testing 22

Current Hardware/Software Design Process § Basic features of current process: § System immediately partitioned into hardware and software components § Hardware and software developed separately § “Hardware first” approach often adopted § Implications of these features: § HW/SW trade-offs restricted § Impact of HW and SW on each other cannot be assessed easily § Late system integration § Consequences these features: § Poor quality designs § Costly modifications § Schedule slippages 23

Incorrect Assumptions in Current Hardware/Software Design Process § Hardware and software can be acquired separately and independently, with successful and easy integration of the two later § Hardware problems can be fixed with simple software modifications § Once operational, software rarely needs modification or maintenance § Valid and complete software requirements are easy to state and implement in code 24

Directions of the HW/SW Co-Design Process Integrated Modeling Substrate HWCI Testing HW Development System Concepts Sys/HW Require. Analysis Sys/SW Require. Analysis Hardware Require. Analysis Prelim. Design Detailed Design Fabric. Integrated Modeling Substrate Software Require. Analysis SW Development Prelim. Design Detailed Design Coding, Unit test. , Integ. test System Integ. and test Operation. Testing and Evaluation CSCI Testing 25

Requirements for the Ideal Co-design Environment § Unified, unbiased hardware/software representation § Supports uniform design and analysis techniques for hardware and software § Permits system evaluation in an integrated design environment § Allows easy migration of system tasks to either hardware or software § Iterative partitioning techniques § Allow several different designs (HW/SW partitions) to be evaluated § Aid in determining best implementation for a system § Partitioning applied to modules to best meet design criteria (functionality and performance goals) 26

Requirements for the Ideal Co-design Environment § Integrated modeling substrate § Supports evaluation at several stages of the design process § Supports step-wise development and integration of hardware and software § Validation Methodology § Insures that requirements system implemented meets initial system 27

Typical Co-design Process FSMdirected graphs Another HW/SW partition System Description (Functional) Concurrent processes Programming languages HW/SW Partitioning Unified representation (Data/control flow) SW Software Synthesis HW Interface Synthesis System Integration Hardware Synthesis Instruction set level HW/SW evaluation 28

RTOS 29

RTOS § Three groups § Small, fast, proprietary kernels § Real-time extensions to commercial operating systems § Research operating systems § Small, fast, proprietary kernels § homegrown § commercial offerings: § QNX, PDOS, p. SOS, VCOS, VRTX 32, Vx. Works, Windows CE 30

RTOS § To reduce the run-time overheads incurred by the kernel and to make the system fast, the kernel § § § has a small size responds to external interrupts quickly minimizes intervals during which interrupts are disabled provides fixed or variable sized partitions for memory management as well as the ability to lock code and data in memory § provides special sequential files that can accumulate data at a fast rate 31

RTOS § To deal with timing constraints, the kernel § provides bounded execution time for most primitives § maintains a real-time clock § provides primitives to delay processing by a fixed amount of time and to suspend/resume execution § Also, the kernel § performs multitasking and intertask communication and synchronization via standard primitives such as mailboxes, events, signals, and semaphores. § For complex embedded systems, these kernels are inadequate as they are designed to be fast rather than to be predictable in every aspect. 32

Common RTOS Features § Utilities § Bootstrapping support § “Headless” operation § Display not necessary § APIs (Application Programming Interfaces) § Multiple threads and/or processes § Mutex /semaphore support with priority inheritance support § Timers/clock § Graphics support § Device drivers § Network protocol stack 33

RTOS Considerations § What processor(s) does it run on? § 8 -bit, 16 -bit, 32 -bit, … § Intel Pentium® Processor, Power. PC, Arm/Strong. Arm Intel Xscale®, MIPS, Super. H, DSP, FPGA… § IBM and Intel® Network Processors § What board(s) does it run on? § Complete software package for a particular hardware board is called a BSP (Board Support Package) § What is the software environment? § § § Compilers and debuggers Cross-compilation + symbolic debugging on target? Profilers (CPU, memory) Test coverage tools Native simulation/emulation support? 34

Metrics in Real-Time Systems (1/2) § End-to-end latency: § E. g. worst-case, average-case, variance, distribution § Can involve multiple hops (across nodes, links, switches and routers) § Behavior in the presence or absence of failures § Jitter § Throughput: § How many X can be processed? § How many messages can be transmitted? § Survivability: § How many faults can be tolerated before system failures? § What functionality gets compromised? 35

Metrics in Real-Time Systems (2/2) § Security: § Can the system’s integrity be compromised? § Can violations be detected? § Safety: § Is the system “safe”? § Can the system get into an ‘unsafe’ state? Has it been ‘certified’? § Maintainability: § How does one fix problems? § How does the system get upgraded? § Dynamism and Adaptability: § What happens when the system mission changes? § What happens when individual elements fail? § Can the system reconfigure itself dynamically? 36

Emerging RTOS Requirements § Full-featured operating system § Support for new processors and devices § Support for Internet protocols and standards § Support for Multimedia protocols and standards § Support for File Systems § Memory protection § Resource protection, security § Development tools and libraries § GUI Environment Do this with low and predictable overheads. 37

Examples of RTOS • Proprietary: § § § § § Ardence RTX Be. OS Chorus. OS DNIX DSOS emb. OS (Segger) ITRON integrity Lynx. OS Micro. C/OS-II MQX RTOS [5] Nucleus OS-9 OSEK/VDX OSEKtime PDOS Phar Lap ETS • Proprietary: § Phar Lap ETS § Pike. OS § Portos § p. SOS § QNX § RMX § RSX-11 § RTOS-UH § RTXC § Salvo RTOS [6] § SINTRAN III § Symbian OS § Thread. X § VRTX § Vx. Works § Windows CE § µn. OS § UNIX-RTR • Open source: – e. Cos – Fiasco – Free. RTOS – Linux – Phoenix-RTOS – Nut/OS – Prex – RTAI – RTEMS – RTLinux – SHa. RK – TRON Project – Xenomai 38

THANK YOU sumamaheswaran@bel. co. in 39