IA2

-1MCSE Jos Onokiewicz jos.onokiewicz@han.nl November 2011

Alle figuren, tabellen en grafieken in deze presentatie is of eigen materiaal of bevat een bronvermelding op dezelfde pagina. Niets uit deze uitgave mag worden vermenigvuldigd en/of openbaar gemaakt worden, hetzij mechanisch of elektronisch door middel van druk, fotokopie, microfilm, geautomatiseerde systemen of op welke andere wijze dan ook, zonder voorafgaande schriftelijke toestemming. Daarvoor kan men zich richten tot de directeur van de betreffende opleiding van de Faculteit Techniek van de HAN.
2

IA2 overview
System engineering System and programming concepts

Software engineering

Development of measurement, test and control systems

LabVIEW programming

Contents
Engineering System and its environment Requirements management Stakeholders Problem statement Functional and nonfunctional requirements Dictionary System and software concepts Events Concurrency Hard and soft real time

Engineering
5

System and its environment 1

System = controlled process + controller unit realises a goal in its environment
environment commands display

controller unit

input

controlled process

output

System and its environment 2

In the environment of a system the next actors can be found: Users (process operators) Maintenance engineers Test engineers ... Other technical systems
7

Systems development steps

Initiation, define scope of the project, vague estimates, system concept Analysis Design Implementation, Integrating and Testing Acceptance, Installation and Deployment Maintenance

V-model steps are the basis for project management

8

System development life cycles 1

Different development strategies exists: Waterfall approach ..... ..... ..... ..... Iterative/incremental approach Increments: a system is developed in a modular way, in every step new features can be added to any module (subsystem).
9

System development life cycles 2

Increment goals can be chosen by the
Project team members (technical focused) Stakeholders (not only technical focused) Tackle high-risk and high-value issues in early iterations

After every increment the result should be a working and tested system!
10

V-model
REQUIREMENTS ANALYSIS Validate requirements OPERATION & MAINTENANCE

TESTING SYSTEM DESIGN SYSTEM TESTING

Verify design

SUBSYSTEM DESIGN

UNIT & INTEGRATION TESTING

CONSTRUCTION

11

Cyclic development process

Source: http://en.wikipedia.org/wiki/Iterative_and_incremental_development
12

Multiple V-model
4 increments design test design test design design test design design test

construction

construction

construction construction
13

System and software engineering

Engineering: is the discipline, skill and profession to apply scientific, mathematical, economic, social and practical knowledge to design and build (technical) systems. Ensures that the stakeholders needs are satisfied throughout a system's entire life cycle. Dealing with a lot of constraints: limited time and all kinds of limited other resources (number of project members, knowledge, programming skills, number of IO, memory size, ...) to realize a system efficiently management and engineering guidelines are necessary.
14

Requirements management 1
Project start
Identify and recruit stakeholders Describe a problem statement Identify and validate requirements

Many projects fail or have bad results because requirements management is ignored!

15

Requirements management 2
Stakeholders/stakeholder classes: customers, soft- and hardware developers, users, project managers, marketing managers, ... Each stakeholder sees the problem from a different perspective. Therefore, you must understand the needs of all stakeholders in order to understand the entire problem domain. You should identify (and recruit) at least one representative from each stakeholder class who will speak for the entire class.
16

Problem statement
A problem statement is a description of the problem. A project proposal is more general. A Problem Statement is a contract negotiated between the engineering and the client or instructor. You must not talk about solutions (design and implementation) instead of making a problem statement. Target group: stakeholders, they need readable and understandable requirements.
17

Problem statement (Six Sigma)

Define the problem - In the problem statement, team members define the problem in specific terms. They present facts such as the product type and the error made. Identify where the problem is appearing - Identifying where the problem is appearing, or manifesting, as specifically as possible helps the team focus its improvement efforts. Describe the size of the problem - The size of the problem is described in measurable terms. Describe the impact the problem is having on the organization - The description of the problem's impact on the organization should be as specific as possible.
Source: http://www.anticlue.net/archives/000750.htm 18

Requirements 1
System identification
Define why the system is build Define what system has to be build Do not define how the system is build (avoid design and implementation decisions)

What is usually in the requirements?

System purpose System behaviour (interaction system and its environment) System dimensions, max. power consumption, ... System (development) constraints
19

Requirements 2
What is usually not in the requirements?
Organizational goals System structure System algorithms User interface definitions Database design Information flow Pricing (debatable)
20

Requirements 3
Functional requirements: Describe the interactions between the system and its environment independent from implementation (System behaviour). Non-functional requirements: User visible aspects of the system not directly related to functional behaviour. They specify attributes of the system, rather than what the system will do. Examples: maximum speed and maximum size. Development requirements: Imposed by the client or the environment (System development).
21

Requirements 4
Requirement types:
Usability Reliability Safety Security Fault tolerance . -ilities

22

Requirements 5
Quality requirements for requirements:
Minimize the number of requirements They must be correct, complete, unambiguous and consistent The goal is to be as precise as possible! SMART
Specific Measurable Abstract Relevant Traceable, track the source of each requirement

Use SI-units (meter, kilogram, seconds, ) Only SMART requirements can be tested!
23

Requirements 6
Most requirements are related to other requirements according to a WHAT-HOW relation WHAT the system has to do Defines the problem (space) HOW the system will do it Elaborates (restricts) the solution (space) Is therefore often an early design decision!

24

SMART Requirements 1
Specific Requirements must be restricted to a particular situation, function, component, relation, or effect. The car will drive at least twice the pace of a human. On a straight course the car will drive at least twice the pace of a human.

25

SMART Requirements 2
Measurable Has concise criteria which unambiguous defines when a requirement is met by the system. On a straight course the car will drive at least twice the pace of a human On a straight course the car will reach a minimum speed of 12km/h within ten metres.

26

SMART Requirements 3
Abstract No early design decision in the requirement (do not restrict the solution space). On a straight course the car will reach a minimum speed of 15 mph within ten metres On a straight course the vehicle reaches a minimum speed of 15 mph within ten metres

27

SMART Requirements 4
Relevant Requirements relate to the systems purpose as stated by a stakeholder or to other requirements. On a straight course the vehicle reaches a minimum speed of 15 mph within ten metres. On a straight course the vehicle reaches a minimum speed of 15 mph within ten metres to guarantee timely arrival of the customers payload.

28

SMART Requirements 5
Traceable Requirements relate to each other or to the systems purpose as listed by an actor

On a straight course the vehicle reaches a minimum speed of 15 mph within ten metres to guarantee timely arrival of the customers payload. (R3.1) On a straight course the vehicle reaches a minimum speed of 15 mph within ten metres to guarantee timely arrival of the customers payload (see also R1.1)
Source: http://jessica80304.wordpress.com/2008/08/04/smart-requirements/

29

FACTS requirements
FACTS (SMART related criteria): Feasible, able to be satisfied Ambiguity-Free, no vague terms Complete, all essential information Testable, able to be verified Simple, short and concise sentence
Source: http://www.incose.org/delvalley/031400r1.pdf
30

Requirements text example

R1. The vehicle can transport 50 humans over a distance of 90 km within one hour without refuelling R1.1. The vehicle can carry a load of 5000kg R1.2. The vehicle will contain fuel a tank which can hold fuel to travel 150km R.1.2.1. The vehicle has a tank which contains 150 liters of diesel R1.3. The vehicle must be able to travel at a speed of 100km/h (see also R.3.7)

R3.7 Maximum speed of a vehicle on the road is 100 km/h.

31

Requirements text example

R1. The vehicle can transport 50 humans over a distance of 90 km within one hour without refuelling R1.2. The vehicle will contain fuel a tank which can hold fuel to travel 150km R.1.2.1. The vehicle has a tank which contains 150 liters of diesel R1. (what) R1.2 (how) R1.2 (what) R1.2.1 (how)

32

Requirements dictionary
Dictionary Part of the requirements document may be one or more dictionaries of often used abbreviations, or ambiguous or complex terms. Goal: to avoid different or even conflicting interpretations of terms by the stakeholder community. A dictionary is not data dictionary for data base development!

33

Exercise 1
Roomba autonomous vacuum cleaner Create a requirements document containing: Problem statement Primary functional requirements Three primary non-functional requirements Dictionary

What problems have you encountered?

34

Exercise 2
RoboCup autonomous robot soccer player Create a requirements document containing: Problem statement Primary functional requirements Three primary non-functional requirements Dictionary

What problems have you encountered?

35

System and programming concepts

36

Programming concepts
Events Real time Data types Polymorphism Concurrency Dataflow programming

37

Events
An event is related to a detected change of some measured value. An event happens at an instant of time and takes zero time. Logical signals: 01 or 10 (rising/falling edge) Examples:
Autonomous vehicle collides with an object Temperature value in an oven exceeds maximum value The ON button switches to on (or to off)
38

Real time
Deterministic behaviour: system must guaranty to respond to an event before a required deadline. This does not mean as fast as possible!
event event related deadline

Response 1

Response 2
Response 2 does not met timing constraint

39

Real time
Periodic events
Control loop: sample sensor data, calculate control action, trigger actuators

A-periodic events
Watch dog timers Collision detection autonomous vehicle

Hard real time systems

Timing constraints must be met (typically safety-critical systems). Military application: Goalkeeper for detecting anti-ship missiles.

Soft real time systems

Desirable that timing constraints are met (but not absolutely necessary). Soft real time tasks wait until hard real time tasks are completed.

Hard and soft real time requirements are related to the level of acceptable costs if timing constraints are not met.

40

Real time system

A real-time system responds in a (timely) predictable way to unpredictable external stimuli arrivals. Timeliness: meet deadlines, it is required that the application has to finish certain tasks within the time boundaries it has to respect. Simultaneity or simultaneous processing: more than one event may happen simultaneously, all deadlines should be met. Predictability: the real-time system has to react to all possible events in a predictable way. Dependability or trustworthiness: it is necessary that the real-time system environment can rely on it.
Source: http://www.dedicated-systems.com/encyc/techno/terms/defini/def.htm

41

Concurrency 1
Processing unit = CPU + memory + IO +software Program = data + functions Processing unit contains 1 CPU 1 CPU contains 1 or more cores System contains several communicating processing units
42

Concurrency 2
Real world is parallel Need for parallel execution of functions Multiple CPUs or 1 CPU containing multiple cores parallel execution is possible 1 CPU 1 core parallel execution possible? Scheduler: every function gets some CPU processing time quasi parallel execution

43

Concurrency 3
Limitations to parallelism Data dependencies Updating shared data Communication overhead between several concurrent executed functions caused by data exchange. LabVIEW is concurrent Dataflow
44

LabVIEW programming
Sources LabVIEW Core 1 Course Material, National Instruments Introduction to G Programming
http://zone.ni.com/devzone/cda/tut/p/id/7668

NI video instructions
http://www.ni.com/academic/students/learnlabview/

45