TECHNISCHE UNIVERSITÄT ILMENAU Development of Integrated Hard- and Software Systems: Tasks and Processes Integrated Communication Systems http://www.tu-ilmenau.de/iks
General Development Tasks Analysis of the requirements of the environment to the system Modeling the system to be designed and experimenting with algorithms involved Refining (or partitioning) the function to be implemented into smaller, interacting pieces HW/SW partitioning allocating elements in the refined model to either HW units or SW running on custom hardware or general microprocessors Scheduling the times at which the functions are executed (this is important when several modules in the partition share a single hardware unit) 2
System Development Process The Theory Analysis Waterfall model Design Implementation Development is not a pure top-down process use of subcomponents from the shelf => bottom-up lack of accurate estimation in early phases => feedback lack of confidence in feasibility => feasibility studies, prototyping Integration Maintenance => in practice the development process is a mixture of bottom-up and top-down design 3
Analysis Phase and Subphases Problem analysis Analysis Feasibility study Requirements analysis The goals of the analysis phase are to identify the purpose, merit and risks of developing the product, and to identify the purpose of the product and to understand its exact requirements 4
Problem Analysis Preliminary study to analyse important needs of the environment to be supported by the system discuss principal solution strategies Problem analysis Analysis Feasibility study => Problem definition (German: Lastenheft) project goals (business objectives) product goals, scope and major directions of the development specifies variables and constants of the product to be developed identifies resources necessary to conduct the development (capital investments, human resources) Requirements analysis 5
Feasibility Study (Machbarkeitsstudie) Check the feasibility of the product development and the product technical feasibility (availability of efficient algorithms,...) economic feasibility (time-to-market, market window, investment, pay-off) Focus of the feasibility study are critical issues of the system in order to improve confidence in the successful completion of the project Problem analysis Analysis Feasibility study Requirements analysis => Output (depends on exact focus of feasibility study) info on expected cost and benefits of the project info on technological and financial risks of project needed resources for development and/or marketing evaluation of possible technical alternatives 6
Requirements Analysis Detailed study of the requirements of the system as seen from its environment Identify, analyze and classify the specific requirements of the product to be developed The solution, i.e. the question of how the requirements are met is typically left open Problem analysis Analysis Feasibility study Requirements analysis => Requirements specification (German: Pflichtenheft) Complete and correct Defines output of the development process (deliverables) Definition of the interfaces to the environment Definition of overall functionality of the product Performance requirements Contraints on SW, operating system and HW Possibly guidelines for internal structure of the product 7
Requirements Definition: Contents Identification of the system (interfaces to the environment) Functional requirements (functionality provided at the interfaces) Temporal and performance requirements (throughput, response time, delay, jitter) Fault-tolerance and reliability Quality (absence of errors) Safety Operating platform (OS, general HW) Power consumption Heat disipation Operating environment (operating temperature, shock-, dust-resistance, etc.) Size Mechanical construction EMC (Tx/Rx) Maintainability Extendability Support Documentation Cost (development, deployment and operation) Date of completion... We will see methods to ensure that the requirements are met in the design section 8
Design and Subphases Design Architectural design Detailed design Implementation design Purpose: decide how the system meets the requirements -> inside view focus on the solution 9
Design and Subphases Architectural Design (Top-level Design) define the modules of the system and their interfaces goal: maximize internal coherence and minimize intermodule coordination modules are typically functional entities but may be structural entities as well (structural vs. behavioral modularization) Architectural design Design Detailed design Implementation design Detailed Design (Module Design) define the functional/behavioral details of each module independent of the implementation technique, e.g. its algorithms Implementation Design take into account the details of the used implementation technique, e.g. interfaces to operating systems and hardware When is the behavior of the system decided and when the structure? 10
The Design Space: A Complex Optimization Problem System architecture overall architecture (structural model, or mapping of functions on HW, etc.) Design methods (design tools and specification languages) HW selection (System-on-Chip, ASIC, FPGA, DSP, NP, uc, up) HW design methods (languages, HL-Synthesis, RTL-Synthesis, ) HW description (algorithms and implementation) HW mapping and scheduling SW description (programming languages, algorithms and implementation) SW mapping and scheduling HW/SW interfacing Interfacing with environment (embedding) Operating system (OS) support Make or buy (HW, SW, OS) Available human resources and know-how... 11
Design Models and Views An Overview Different modeling approaches focus on different aspects of the system & & & structural view msc data_transfer application transport network medium network transport application data-oriented view system functional view behavioral view 12
Structural Models Structural models focus on the structure of the system, i.e. its components, modules, etc., rather than its behavior Structural blocks may be abstract (ALUs, processors, memory, busses, chipsets, boards) or detailed (flip-flops, gatter) Examples: netlist, architectural block diagram & & & 13
Behavioral Models Behavioral models describe the behavior of the system or parts hereof Implementation of behaviroal models may be in SW or HW however some models are better suited for HW design others better for SW Examples: C program, Petri net, state diagram, data flow graph o(n) = c1 * i(n) + c2 * i(n-1) KEY_ON => START_TIMER WAIT OFF KEY_OFF or BELT _ON => END_TIMER_5 => ALARM_ON Send msg END_TIMER_10 or BELT_ON or KEY_OFF => ALARM_OFF ALARM Process 1 Process 2 Send Ack Receive Ack 14
Behavior and Structure Models of computation Requirements Structural model Validation Behavior Simulation System Behavior Mapping System Architecture HW/SW partitioning, scheduling Performance Simulation Synthesis Communication Refinement Flow To Implementation 15
Behavior meets Structure: The Optimization Problem Behavioral Space System Platform Structural Space 16
Behavior meets Structure: The Optimization Problem Behavioral Space System Platform There are numerous solutions to define the behavior consistent with the given requirements (algorithms, data structures) There are numerous ways to model the defined behavior of the system There are numerous solutions to define the structure of the system (Microcontroller, DSP, customized HW, configurable HW,...) There are multiple ways to model the defined structure of the system Design is about mapping the behavior (including data and functions) on the structure such that all requirements are fulfilled (cost, time constraints, capacity, reliability, maintainability, power consumption,...) Mapping is a very complex optimization problem Structural Space 17
Design: Behavior vs. Structure Behavioral specifications describe the functionality of the system using some modeling or programming language behavior specifications may be abstract models (state charts, UML, SDL) or concrete programs (C, VHDL, SystemC) behavioral specifications may be executed/implemented on real HW (C program, assembler) or simulated on virtual HW (VHDL, SystemC, SDL) Behavioral specifications ensure that the functional requirements are met however there is no confidence in non-functional aspects of the system, e.g. performance, real-time, fault tolerance, cost, power consumption,... Structural specifications are needed to implement the system in HW So, when is the best point in time to decide the structure? 18
Implementation Prerequisites: Functional details as algorithms, etc. are specified HW components are selected HW/SW partitioning may be decided... Tasks: coding of functions, algorithms, etc. in the selected implementation language test of the modules and components in isolation emulating the environment of the modules/components Notes: provided the design is complete and correct this is straight-forward the implementation phase represents a small part of the development process (appr. 20% for pure SW projects) 19
Validation Methods By construction Property is inherent. By verification Property is provable. By testing Check behavior of (all) inputs. By simulation Check behavior in the model world. By intuition Property is true. I just know it is. By assertion Property is true. Wanna make something of it? By intimidation Don t even try to doubt whether it is true. It is generally better to be higher in this list! :-) Validation is a continuous process applied in different phases of the development process and to different models of the system to ensure conformance with various properties/requirements of the system or its components (behavior, temporal requirements, shock resistance,...) 20
Integration Purpose: ensure compliance with system requirements complete the system for delivery Tasks: System integration: subsequent addition of HW components and SW modules to the system until the final system is established Integration testing: stepwise testing of system (requires knowledge of the system as a whole) System testing: test after all parts have been integrated Notes: Testing may be applied to almost all requirements or properties of systems, system components or modules (functionality, performance, reliability, termal resistance, shock resistance, ergonomics, man-machine interface, documentation,...) Testing is the most popular validation method in practice 21
Maintenance involved during the whole lifetime of a system, from delivery till removal from service deal with changes due to changing environments, changing functional or performance requirements removal of errors Note: often the maintenance cost are much greater than the development cost 22
Process Models Overview Waterfall model (top-down) engineering approach to building a house, bridge, etc. no feedback assumed Iterative waterfall model validation and feedback to earlier stages Evolutionary model system development process is considered an evolution of prototypes requirements are subsequently added to the system Spiral model generalisation of various process models (meta model) multiple development cycles including validation V model continuous validation with real world/environment Component-based (bottom-up) compose the system of a set of predefined components (object-based) 23
Classic Waterfall Model & Iterative Waterfall Model Classic waterfall model (top-down) Analysis Design Implementation engineering approach to building a house, bridge, etc. no feedback assumed Integration Maintenance Iterative waterfall model validation and feedback to earlier stages 24
Evolutionary Model Limits of the waterfall model often the requirements are incomplete in the beginning waterfall model is not appropriate where requirements are not well understood or not well defined with the waterfall model, there are no intermediate product releases Idea of the evolutionary model: provide intermediate product releases refine and extend requirements during the development process analysis design implementation test new prototype needed n y modification of product definition 25
Spiral Model Meta model supporting the flexible combination of the above approaches define objectives, alternatives and constraints evaluate alternatives, identify and resolve risks review results; plan next iteration develop and verify 26
V Model Extension of the waterfall model to integrate quality assurance (verification and validation) requirements definition application scenarios acceptance test validation top-level design High level test cases system test detailed design module implementation test cases test cases module test integration test verification Validation: ensure the system conforms with the needs of the environment (are we building the right system? product quality) Verification: ensures that the outcome of a development phase exactly conforms to the specification provided as input (is the system built right? process quality) 27
Traditional (Early Partitioning) vs. Codesign Approach Early Partitioning (Structure First) system architectur HW/SW Codesign (Behavior First) system description HW descr. SW descr. system architectur HW impl. SW impl. HW impl. SW impl. prototyp/product prototyp/product + optimized descriptions/models for HW and SW parts, respectively - lack of flexibility wrt HW/SW partitioning - problems with HW/SW integration + joint system description/model eases validation and integration - joint description is not optimized for both HW and SW + flexibility wrt. HW/SW partitioning 28
Traditional vs. Codesign Approach (Polis, Cadence VCC) Traditional System Design VCC Separation and Mapping System Behavior System Implementation System Architecture System Performance System Behavior System Architecture 1 2 Mapping Behavior on Architecture Refine 3 4 Implementation of System Data Sheets on paper Executable Data Sheets 29
References System Focus D. Gajski, F. Vahid, S. Narayan, J. Gong: Specification and Design of Embedded Systems. Prentice Hall, 1994. A. Mitschele-Thiel: Systems Engineering with SDL Developing Performance- Critical Communication Systems. Wiley, 2001. (section 2.1.2) J. Teich: Digitale Hardware/Software Systeme. Springer, 1997. Software Focus H. Balzert: Lehrbuch der Software-Technik Band 1: Softwareentwicklung. Spektrum-Verlag, 2001. R. S. Pressman: Software Engineering A Practicioner s Approach. Fourth Edition, McGraw Hill, 1997. 30