TECHNISCHE UNIVERSITÄT Development of Integrated Hard- and ... · Development of Integrated Hard-...
Transcript of TECHNISCHE UNIVERSITÄT Development of Integrated Hard- and ... · Development of Integrated Hard-...
Development of Integrated Hard- and Software Systems: Tasks and Processes
TECHNISCHE UNIVERSITÄTILMENAU
Inte
grat
ed C
omm
unic
atio
n Sy
stem
sht
tp://
ww
w.tu
-ilm
enau
.de/
iks
Integrated Communication-Systems 2Andreas Mitschele-Thiel 14-Jan-11
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)
Integrated Communication-Systems 3Andreas Mitschele-Thiel 14-Jan-11
System Development Process – The Theory
Analysis
Design
Implementation
Integration
Maintenance
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
=> in practice the development process is a mixture of bottom-up and top-down design
Waterfall model
Integrated Communication-Systems 4Andreas Mitschele-Thiel 14-Jan-11
Analysis
Analysis Phase and Subphases
Problemanalysis
Feasibilitystudy
Requirementsanalysis
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
Integrated Communication-Systems 5Andreas Mitschele-Thiel 14-Jan-11
Problem Analysis
Preliminary study to analyse important needs of the environment to be supported by the system
discuss principal solution strategies
=> 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)
AnalysisProblemanalysis
Feasibilitystudy
Requirementsanalysis
Integrated Communication-Systems 6Andreas Mitschele-Thiel 14-Jan-11
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 toimprove confidence in the successful completion of the project
=> 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
AnalysisProblemanalysis
Feasibilitystudy
Requirementsanalysis
Integrated Communication-Systems 7Andreas Mitschele-Thiel 14-Jan-11
AnalysisProblemanalysis
Feasibilitystudy
Requirementsanalysis
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
developedThe solution, i.e. the question of how the
requirements are met is typically left open
=> 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
Integrated Communication-Systems 8Andreas Mitschele-Thiel 14-Jan-11
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
Integrated Communication-Systems 9Andreas Mitschele-Thiel 14-Jan-11
Design and Subphases
Design
Architecturaldesign
Detaileddesign
Implementationdesign
Purpose: decide how the system meets the requirements -> inside view focus on the solution
Integrated Communication-Systems 10Andreas Mitschele-Thiel 14-Jan-11
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)
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
Design
Architecturaldesign
Detaileddesign
Implementationdesign
When is the behavior of the system decided and when the structure?
Integrated Communication-Systems 11Andreas Mitschele-Thiel 14-Jan-11
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
...
Integrated Communication-Systems 12Andreas Mitschele-Thiel 14-Jan-11
&
&&
Design Models and Views – An Overview
Different modeling approaches focus on different aspects of the system
msc data_transferapplication transport network medium network transport application
systemdata-oriented
viewfunctional
view
structuralview
behavioralview
Integrated Communication-Systems 13Andreas Mitschele-Thiel 14-Jan-11
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
&
&
&
Integrated Communication-Systems 14Andreas Mitschele-Thiel 14-Jan-11
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
Process 1
Send msg
Receive Ack
Send Ack
Process 2
KEY_ON => START_TIMER
END_TIMER_5 => ALARM_ON
KEY_OFF orBELT _ON =>
END_TIMER_10 orBELT_ON orKEY_OFF => ALARM_OFF
WAIT
ALARM
OFF
o(n) = c1 * i(n) + c2 * i(n-1)
Integrated Communication-Systems 15Andreas Mitschele-Thiel 14-Jan-11
Behavior and Structure
SystemBehavior
SystemArchitecture
Mapping
Flow To Implementation
CommunicationRefinement
BehaviorSimulation
PerformanceSimulation
Models of computation
HW/SW partitioning,scheduling
Synthesis
RequirementsStructural model
Validation
Integrated Communication-Systems 16Andreas Mitschele-Thiel 14-Jan-11
Behavior meets Structure: The Optimization Problem
Structural Space
System Platform
Behavioral Space
Integrated Communication-Systems 17Andreas Mitschele-Thiel 14-Jan-11
Behavior meets Structure: The Optimization Problem
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 optimizationproblem
Structural Space
System Platform
Behavioral Space
Integrated Communication-Systems 18Andreas Mitschele-Thiel 14-Jan-11
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?
Integrated Communication-Systems 19Andreas Mitschele-Thiel 14-Jan-11
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)
Integrated Communication-Systems 20Andreas Mitschele-Thiel 14-Jan-11
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 systemto ensure conformance with various properties/requirements of the system or its components (behavior, temporal requirements, shock resistance, ...)
Integrated Communication-Systems 21Andreas Mitschele-Thiel 14-Jan-11
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
Integrated Communication-Systems 22Andreas Mitschele-Thiel 14-Jan-11
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
Integrated Communication-Systems 23Andreas Mitschele-Thiel 14-Jan-11
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)
Integrated Communication-Systems 24Andreas Mitschele-Thiel 14-Jan-11
Classic Waterfall Model & Iterative Waterfall Model
Analysis
Design
Implementation
Integration
Maintenance
Classic waterfall model (top-down)
engineering approach to building a house, bridge, etc.
no feedback assumed
Iterative waterfall model
validation and feedback to earlier stages
Integrated Communication-Systems 25Andreas Mitschele-Thiel 14-Jan-11
Evolutionary Model
Limits of the waterfall model often the requirements are
incomplete in the beginningwaterfall 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
new prototypeneeded
modification of product definition
y
test
n
Integrated Communication-Systems 26Andreas Mitschele-Thiel 14-Jan-11
Spiral Model
Meta model supporting the flexible combination of the above approaches
review results;plan next iteration
define objectives,alternatives and constraints
evaluate alternatives,identify and resolve
risks
developand verify
Integrated Communication-Systems 27Andreas Mitschele-Thiel 14-Jan-11
V ModelExtension of the waterfall model to integrate quality assurance
(verification and validation)
requirements definition
top-leveldesign
detaileddesign
moduleimplementation
moduletest
integrationtest
systemtest
acceptancetest
application scenarios
High level test cases
test cases
testcases
valid
atio
nve
rific
atio
n
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)
Integrated Communication-Systems 28Andreas Mitschele-Thiel 14-Jan-11
Traditional (Early Partitioning) vs. Codesign Approach
Early Partitioning (Structure First) HW/SW Codesign (Behavior First)
system architectur
HW descr. SW descr.
HW impl. SW impl.
prototyp/product
system description
HW impl. SW impl.
system architectur
prototyp/product
+ joint system description/model eases validation and integration
- joint description is not optimized for both HW and SW
+ flexibility wrt. HW/SW partitioning
+ optimized descriptions/models for HW and SW parts, respectively
- lack of flexibility wrt HW/SW partitioning
- problems with HW/SW integration
Integrated Communication-Systems 29Andreas Mitschele-Thiel 14-Jan-11
Traditional vs. Codesign Approach (Polis, Cadence VCC)
Traditional System Design
SystemBehavior
SystemArchitecture
SystemImplementation
SystemPerformance
Data Sheetson paper
VCC Separation and Mapping
SystemBehavior
SystemArchitecture
Mapping
Behavior onArchitecture
Refine
Implementationof System
1 2
3
4
ExecutableData Sheets
Integrated Communication-Systems 30Andreas Mitschele-Thiel 14-Jan-11
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.