Veritas D2.3.1

Accessible and Assistive ICT
VERITAS
Virtual and Augmented Environments and Realistic User
Interactions To achieve Embedded Accessibility DesignS
247765
Generation of Simulation Models

for Smart Living Spaces
Deliverable No. D2.3.1

Innovative VR models, tools
SubProject No. SP2 SubProject Title
and simulation environments
Workpackage W2.3 Workpackage Smart Living Spaces

No. Title
Activity No. A2.3.4 Activity Title Generation of simulation

models
Authors DOMOLOGIC, FhG/IAO, Bauunion, UoS, USTUTT
Status: F (Final)
Dissemination Level PU (Public)
File Name: VERITAS_D2.3.1_Generation of simulation

models.odt
Project start date and 01 January 2010, 48 Months

duration
VERITAS_D2.3.1 PU Grant Agreement # 247765
Version History table

Version Dates and comments
no.
0.1 01. October 2011; Initial draft, based on ID2.3.1 & ID2.3.2 (DML)
0.2 15 November 2011, Second draft
0.3 07 December 2011, Third draft
0.4 12 January 2012, References added
0.5 17 February 2012, Including demo scenario ideas evolved during

workshop
0.6 22 February 2012; Included executive summary and general

review
0.7 28 February 2012; Harmonized the style templates, corrected

spelling etc.
0.8 09 March 2012: Technical aspects moved to separate

documentation, task analysis included
1.0 15 March 2012: Accessibility issues
February 2012 3 DOMOLOGIC

Table of Contents
Version History table ....................................................................................... 3
Table of Contents ............................................................................................. 4
Abbreviations List ............................................................................................ 7
1 Executive Summary .................................................................................. 8
2 Planning and Design Process in the Smart Living Spaces domain ..... 9
2.1 A Generic Planning and Design Process ............................................. 9
2.2 The Architectural Design Process ...................................................... 10
2.2.1 Germany ................................................................................................................ 10
2.2.2 Austria .................................................................................................................... 12
2.2.3 Italy ........................................................................................................................ 16
2.2.4 Spain ...................................................................................................................... 18
2.2.5 Greece ................................................................................................................... 19
3 The VERITAS Smart Living Spaces Design Process ........................... 22
3.1 Stakeholders ...................................................................................... 23
3.2 Process Steps .................................................................................... 24
4 Simulation of Smart Living Spaces ....................................................... 26
4.1 General approach .............................................................................. 26
4.2 Definition of domotic situations .......................................................... 26
4.3 Extraction of devices .......................................................................... 28
4.4 Task analysis and extraction of primitive tasks .................................. 29
4.4.1 Definition of task .................................................................................................... 29
4.4.2 Definition of sub-task ............................................................................................. 30
4.4.3 Definition of primitive task ...................................................................................... 30
4.5 Extraction of properties ...................................................................... 32
4.6 Example ............................................................................................. 34
4.7 Interaction analysis ............................................................................ 35
4.8 Simulation models .............................................................................. 35
4.8.1 Definition of task model tasks ................................................................................ 35
4.8.2 Definition of task model relationships .................................................................... 36
4.8.3 Creation of simulation models ............................................................................... 36
5 Appendix .................................................................................................. 37
5.1 Task analysis ..................................................................................... 37
5.2 Generation of UsiXML files ................................................................ 59
5.2.1 Collision detector ................................................................................................... 59
5.2.2 Cooker ................................................................................................................... 60
5.2.3 Dishwasher ............................................................................................................ 65

5.2.4 Exhaust hood ......................................................................................................... 71

5.2.5 Fridge ..................................................................................................................... 73
5.2.6 Lamp ...................................................................................................................... 82
5.2.7 Light switch ............................................................................................................ 83
5.2.8 Motion detector ...................................................................................................... 86
5.2.9 Oven ...................................................................................................................... 88
5.2.10 Presence detector ............................................................................................. 94
5.2.11 Siren .................................................................................................................. 95
5.2.12 Sliding door ....................................................................................................... 96
5.2.13 Swing door ...................................................................................................... 101
5.2.14 Washing machine ............................................................................................ 107
6 References ............................................................................................. 114

List of Figures
Figure 1: The basic UCD process ...................................................................... 9
Figure 2: The VERITAS Smart Living Spaces design process ......................... 24
Figure 3: Definition of task ................................................................................ 30
Figure 4: Definition of sub-task ......................................................................... 30
Figure 5: Definition of primitive task ................................................................. 31
Figure 6: Detect Collision ................................................................................. 60
Figure 7: Cooking ............................................................................................. 65
Figure 8: Start & stop dishwasher .................................................................... 71
Figure 9: Using the exhaust hood..................................................................... 73
Figure 10: Loading the fridge............................................................................ 78
Figure 11: Taking a good ................................................................................. 82
Figure 12: Check if lamp is turned on ............................................................... 83
Figure 13: Toggle light switch ........................................................................... 86
Figure 14: Detect motion .................................................................................. 88
Figure 15: Start & stop oven ............................................................................. 94
Figure 16: Detect user's presence .................................................................... 95
Figure 17: Alarm ............................................................................................... 96
Figure 18: Open & close sliding door manually ................................................ 99
Figure 19: Pass the sliding door ..................................................................... 101
Figure 20: Open & close the swing door manually ......................................... 105
Figure 21: Pass the swing door ...................................................................... 106
Figure 22: Load & Unload washing machine .................................................. 111
Figure 23: Using the washing machine .......................................................... 113

Abbreviations List
Abbreviation Explanation
A Activity
AAL Ambient Assisted Living
AEC Architecure, Engineering, Construction
API Application Programming Interface
D Deliverable
DOF Degree of freedom
DoW Description of Work
HCI Human Computer Interaction
HMD Head-mounted Device
HVAC Heating, Ventilation, Air-conditioning
ICT Information and Communication Technology
ID Internal Deliverable
DoW Description of Work
SP Subproject
UCD User Centred Design
UI User Interface
UX User Experience
VR Virtual Reality
WP Work Package

Executive Summary
This deliverable describes the work performed under activities A2.3.1 to A2.3.3
for the generation of simulation models for the Smart Living Spaces domain.
Smart Living Spaces aim to enhance the users surrounding environment with
the use of Information Technology services and applications combined with
sensors, controllers, displays and computational elements (such as portable or
wearable computers), all connected through a network. Smart Living Spaces
belong to a more general concept known as Smart Environments, which in turn
are a by-product of pervasive (or ubiquitous) computing.
Domotics is a specific manifestation of smart living spaces, concentrated in
home automation, security and entertainment applications, which include
controlling the automatic regulation of the heating, ventilation, and air-
conditioning, management of house lighting, monitoring of the premises via a
network of cameras and various sensors, communication via intercoms and
home entertainment systems.
In VERITAS the focus is twofold considering Smart Living Spaces, especially
the domotic applications area, but will also take under consideration the whole
designing process by introducing the disability factor.
This document analyses the SoA for planning (in chapter ) in the for Smart
Living Spaces primarily for private homes but also for public and business
buildings with an emphasis on design for users with special needs. It turns
out, that a number of national regulations and technical rules covering users
with special needs exist in many European countries but that in practice no well
established design process for Smart Living Spaces exists, that systematically
integrates them. The planner/architect as an expert is responsible for taking
special user requirements into account in the various design phases and taking
design decisions accordingly. Validation of design decisions in-the-loop with
real end-user involvement is only done seldomly mainly due lack of resources.
Chapter describes the VERITAS Smart Living Spaces Design Process,
introducing systematic and iterative validation in the main design phases using
a special VERITAS Development Support System integrating requirements
definition, planning and design activities as well as virtual simulation of the
design result.
Chapter resumes results of task analysis and use cases description performed
in WP1.7 and the virtual user model files generated by the VERITAS model
platform (WP1.6), and defines the specific tasks to be performed in simulation
scenarios. The tasks are analysed to describe the interactions, objects, success
criteria and thresholds that fully describe the simulation modeling. Finally, the
simulation models are formulated into UsiXML form, in order to describe the
simulation models in a form that can be then adapted by the Veritas Tools in
order to match specific designs and users (chapter ).

1 Planning and Design Process in the Smart

Living Spaces domain
Wikipedia defines Planning as both the organizational process of creating
and maintaining a plan; and the psychological process of thinking about the
activities required to create a desired goal on some scale. The term
[planning] is also used for describing the formal procedures used in such an
endeavour, such as the creation of documents, diagrams, or meetings to
discuss the important issues to be addressed, the objectives to be met, and the
strategy to be followed. Making a plan for the construction of an object (e.g. an
architectural drawing) is referred to as Design.
Designing often necessitates considering the aesthetic, functional, economic
and socio-political dimensions of both the design object and design process. It
may involve considerable research, thought, modelling, interactive adjustment,
and re-design according to Wikipedia again.
1.1 A Generic Planning and Design Process

The procedure of design and development for new products/services according
to the user centred design (UCD) philosophy takes into account the needs,
wants, and limitations of end users giving extensive attention at each stage of
the design process. When the end users are older people and people with
disabilities, the design steps are more complicated and designers and
developers often dont have a suitable tool that allows designing accessible
product/services. The design process is lead by the personal experience and
the cleverness of the own designer, that is able to make common design tools
and software bend his/her will and need.
The user-centred design could be considered as a multi-stage problem solving
process that not only requires designers to analyze and foresee how users are
likely to use the artefact, but also to test the validity of their assumptions with
regards to user behaviour in real world.
Figure 1: The basic UCD process
The aim of the VERITAS development chain is to involve end users throughout
the development chain, from the early design phases on, by means of a virtual
reality environment that allows simulating real, end users requirements and
parameters while interacting with the designed application.
A survey conducted in VERITAS SP1 confirmed the basic design process
reported in

, with some clarifications provided directly by the interviewed designers and

developers:
Usability evaluation (heuristic or user-based) takes place between

Requirements and data collection and Design 1st phase steps.
Using Computer-Aided Engineering (CAE) techniques during the

requirements and data collection phase to evaluate components. If CAE
is not available, also testing by using prototypes pieces is applied to
proceed.
Using virtual analysis during Concept selection/validation step.
A real testing phase is mostly missing.
There is more than one iteration of the design-prototype-testing-redesign

cycle.
1.2 The Architectural Design Process

Architectural design is a complex process, considering a number of constraints,
such as location, environment, legislation, costs, and last but not least customer
requirements, to create an edifice or building. The outcome of the architectural
design process is a number of drawings (or blueprints), models, sketches, and
descriptions that specify the designed object to such an extent, that the
subsequent construction process leads to the conceived result in the real world.
In the VERITAS project the focus is on design for all (universal design)
meaning an enhanced design process taking people with and without
disabilities as well as older people into account. The universal design ideas
emerged from earlier barrier-free concepts, the accessibility movement as well
as developments in the field of assistive devices.
Internal deliverable ID4.5.1 Compendium of relevant standards and impact on
VERITAS work provides an overview of norms and standards relevant for the
general design process. The following sections complement ID4.5.1 and give an
overview on architectural design processes and relevant building
regulations with respect to universal design in various European countries.
1.2.1 Germany
Although there exists no crisp and normative definition of the architectural
design process in Germany, all architectural planning and design activities are
guided by a federal legal regulation called Honorarordnung fr Architekten und
Ingenieure (HOAI) (English Translation: Official Scale of Fees for Services by
Architects and Engineers).

HOAI prescribes pricing of planning and design services by defining nine typical
phases in the architectural design process. For each of those phases it is
clearly specified what kind of activities are usually carried out and can thus be
priced, and to what extent of the overall project budget.
1. Requirements definition (Grundlagenermittlung)
Requirements definition phase including client consultations, and
definition of project goals as well as inventory taking and surveys.
2. Preliminary planning and cost estimation (Vorplanung und
Kostenschtzung)
Initial project concept definition phase including cost estimates.
3. Draft planning and costing (Entwurfsplanung und
Kostenberechnung)
1st Design phase from sketches to architectural drawing taking
requirements defined in phase 1 into account. Includes also cost
calculations. Low-fidelity prototypes and architectural models are usually
part of this phase.
4. Legal clearance phase (Genehmigungsplanung)
Legal clearance phase including all documentation required from
authorities.
5. Implementation planning (Ausfhrungsplanung)
2nd Design phase including collaboration and coordination with
specialised civil engineers (e.g. structural, HVAC, lighting, domotics).
High-fidelity prototypes are usually implemented in this phase as well as
more detailed quality assessments, e.g. regarding accessibility.
6. Preparation of project procurement (Vorbereitung der Vergabe)
This phase includes exact quantity determinations as a preparation of the
following contractor selection process.
7. Participation in project procurement (Mitwirkung bei der Vergabe)
The contractor selection phase is usually not carried out directly by the
architects themselves, but with their support.
8. Project supervision (Objektberwachung)
Construction phase
9. Project management and documentation (Objektbetreuung und
Dokumentation)
Facility management and documentation phase

The phases do not however define a strict temporal order of activities within a
project, i.e. they do not prescribe a project plan or process model such as the
waterfall model in IT-related projects. For the scope of this document phases 1
to 6 are the most important.
In Germany a number of regulations and norms for barrier-free buildings and
housing exist. First and foremost the federal equal treatment of people with
disabilities act Law on equal opportunities for disabled people (Gesetz zur
Gleichstellung behinderter Menschen (BGG)) gives a definition of barrier-free
in its 4:
Physical structures, means of transportation, technical equipment, [] are
called barrier-free if they are designed to be accessible and usable for
unassisted people with disabilities [] without extra hindrance.
Building laws and regulations are established individually by the German federal
states (Bundeslnder). A degree of commonality is achieved by national
regulations and the council of Ministries of Building and Construction
(Bauministerkonferenz). Since those regulations are compulsory in nature
compliance with regulations is enforced through formal procedures, e.g. building
application process, walk-through building inspections, etc. by respective (local)
authorities.
Although the building law mostly covers public buildings, a template version
published by the above council states in 50 (1) that at least one floor of flats
must be barrier-free, i.e. have living rooms, bathrooms, and kitchen accessible
with a wheelchair, for buildings with more than two flats in total. This is,
however, only applicable to newly erected buildings not to existing ones.
Apart from public buildings a broad range of federal and state laws exist for
work environments, e.g. offices, workshops and factories.
Workplace regulations (Arbeitsstttenverordnung, ArbStttV)
Technical rules for workplaces (Technische Regeln fr Arbeitssttten,

ASR)
In contrast to formal regulations, norms are common definitions of correct
working and proper execution usually published by non-legislative bodies,
technical bodies. Hence they may or may not be adopted in the design process
but they are often referred to in legal contracts e.g. about planning and
construction of buildings and thus attain binding status for the contractual
parties.
DIN 18024-1: Streets, squares, paths, public transport and parks and
playgrounds
DIN 18024-2: Publicly accessible buildings and workplaces
DIN 18025-1: Flats for wheelchair users
DIN 18025-2: Barrier-free apartments

DIN 18040-1: Accessible buildings - Design Basics - Part 1: Publicly

accessible buildings
DIN 18040-2: Accessible buildings - Design Basics - Part 2: Dwellings
DIN 77800: Quality requirements for providers of residential form of

'sheltered housing for older people' ", Part (b) Dwellings
1.2.2 Austria
The architectural design process of smart living environments in Austria has not
really a pre-defined course of actions and differs depending on the particular
customer. More precisely, the phases and the people and institutions involved
in them are different whether the project is Business-To-Customer (B2C) or
Business-To-Business (B2B).
People from three different companies covering both target groups were
interviewed to gather insights into the state-of-the-art planning process and the
project handling in the smart home area. Digital communication and interactive
media (online as well as interactive installations) is the business domain of two
companies, while the third one is specialized in IT services generally with an
additional department which focuses on smart homes for elderly people only. All
of the interview partners are head of the smart home solutions department and
partially CEO of the company, too. All of them are both, technical planners as
well as conceptual leads including customer care throughout the whole duration
of projects.
The following steps summarize the general planning and design process of
smart home projects. They are derived from the conducted interviews, covering
both B2C and B2B customers:
1. Requirement analysis
After the customer acquisition the first step is to gather their
requirements. This is always done meeting the customer in person. As
Smart Home is a pretty new topic and customers are in most cases not
familiar with it, a main component of these talks (next to the identification
of requirements) is to make the customer aware of the (technical)
possibilities at all. Especially older people have no clue about what
functionalities and services could be provided.
2. Concept
In the next step a first design concept is realized which covers all
functionalities to cover the requirements from step one. The concept is
usually iterated (refined, changed or reduced) with the customer a few
times. For large projects with public customers, e.g. when building new
assisted accommodations for elderly people, the creation of the concept
usually involves several institutions being in contact with the target group
such as social or medical organisations, mobile services for food or
transportation, etc. but rarely the concerned people themselves. The
coordination and information exchange is highly demanding in projects

involving such services.

The results of this phase are a concept and a contract for starting with
the planning process if the customer is either an end-user or a company.
The latter is not valid for institutions from the public sector in the
residential area (city council, etc.). In this case, the final contract is
usually signed after presenting a first plan including cost estimation.
3. First plan
A first technical planning that is aligned with the concept is done. Plans
of the buildings are required for that (usually delivered as AutoCAD files).
The outcomes are a rough hardware list and software components that
need to be implemented as well as the estimated costs.
4. Detailed plan
If the first plan is approved by the customer, the planning of all details
follows. This includes all final devices, functions and plans needed for
later on installation. Together with architects, electrical planners and
partly the end-users the position and the design of every device and
operating interface (e.g. touch panels) is defined. Block diagrams
including the electrical planning, signal flows, required power supply and
every single cable are generated. The results are building plans that
contain all information necessary to enable installation by every skilled
labour. Standards such as AutoCAD and AutoCAD ecscad (for
electronics) are used to ensure transparency.
Companies doing the smart home planning do not consider regulations
regarding building accessibility, but instead hand over these issues to the
architect. However, they stick to regulations from the concerned crafts
such as electronics, communication electronics or laws for exhibitions if
smart home technology is installed in public areas. These regulations
mainly cover power issues (low/high voltage, fuses, etc.) and data
handling.
5. Construction phase/installation
Holding these plans in the hands installation is done by skilled workers
sometimes from the planning company, sometimes from external ones.
However, the supervision and coordination is done by the planning
company.
6. Documentation and Training
Finally, the end-users are instructed how to use the system und often
given a user manual and a technical document holding all information.
The goal of the projects is always to reduce the amount of introduction to
a minimum, especially for elderly people that are not familiar with
computer technology and how to use it. However, there are always
compromises between simplicity and flexibility that have to be made,
especially for B2C projects. A simple day/night mode might not be

sufficient, because a customer likes to have more separated control

possibilities. This can be adjusted individually within B2C projects, but is
a big problem for public customers that do not finance individual
solutions.
7. Customer care/maintenance
In most projects customer care and maintenance is included in the
contract. After a few weeks of familiarization with the system, end-users
have the possibility to give feedback, ask if something was not
understood or should be slightly changed. For the companies this is also
an important way to get feedback on their system from a conceptual as
well as a technical point of view.
8. Validation
Validation of the design can be done during and at the end of a project.
While validation during the design process is usually not done explicitly
(customer conversations, detailed planning eliminates errors in the first
planning, etc.), validation of the final installation is of great importance to
companies. The feedback of customers allows avoiding making the same
shortcomings/errors again. This includes technical issues (e.g. error-
prone hardware) as well as conceptual details (e.g. gathered verbally or
by using questionnaires).
The documentation of the feedback varies from company to company.
While some simply gather experience, others archive problems and their
solutions using online tools. One interesting approach is also to provide
an online feedback platform to the customers (similar to product rating in
online shops) were planners as wells as customers have access to.
As mentioned above there do not exist explicit regulations for smart home
environments in Austria, but instead regulations regarding the accessibility of
buildings that are mainly designed for public places and buildings, as they have
to be barrier-free by 100% (universal design) to be accessible for all people. In
contrast private buildings just have to be built in a way that future disabilities
(e.g. when getting older) do not require to move to another building or
expensive reconstruction activities (adaptive design).
The national regulations are manifold and try to meet the antidiscrimination
paragraph, which was included in the Austrian constitution in 1997. This action
followed a request by the European Union to include antidiscrimination clauses
in the national law, which is implemented in Article 7, Paragraph 1 of the
Federal Constitutional Law (Bundesverfassungsgesetz).
To realize the intention of this paragraph namely enabling the integration and
conductance of an independent life of disabled and old people barrier-free
planning and construction are a main requirement.
In general, all building laws are defined individually by the nine provinces of
Austria on their own. However, there are attempts to harmonize all different

regulations for total Austria. The following areas have to be considered:
National law (antidiscrimination law, )
Federal state law (TBO, )
Compulsory and advisory critical levels
Standards (NORM, DIN, )
Other directives
One of the most important standards in order to enable people with disabilities
easy access to/in buildings is the NORM B 1600-2005. It follows the principle
Design for All. The target groups involve people with physical or perceptual
limitations as well as women with children, buggies, pregnant women, older
people and children. The components of this NORM that are valid for
residential buildings are:
3.1.5 Ramps
3.1.6.2 3.1.6.7 Parking-lots for passenger cars of disabled people
3.2.2.1 3.2.2.9 Entries and doors
3.2.3 Horizontal connection paths
3.2.4 Vertical connection paths apart from a link in NORM en 81-70

point 3.2.4.3
3.2.5.2 3.2.5.3.1 Sanitary rooms
3.2.5.4 Sanitary rooms
3.2.6 Usage rooms that are generally accessible
3.2.9 Free areas
4.3 Barrier-free sanitary rooms
5 Labeling, Guidance
For adaptable residential buildings the following divergent regulation for sanitary
rooms is valid:
3.2.7 (Adaptable residential building) of NORM B 1600-2005

However, the design of barrier-free buildings does not only consider free areas,
the height of switches or the width of doors, etc. It is about the interplay of
architecture, assistive technology, furniture and other supporting utilities
such as handholds, stair lifts, etc. The basic regulations and guidelines
presented have to be considered throughout all of these areas.

1.2.3 Italy
A generic domotics design process:
1. Building type analysis
This phase foresee the classification of architectural context (i.e. villa vs.
apartment; number and type of rooms, volume and spaces, plan).
2. Identification of user type
This phase foresee the identification of user type, according to household
(single vs. small/big family), to age (young vs. elderly people), to their
impairments (disable or not), to coexistence of disabled people with not
disabled people. At least a domotic house designed for disabled and
elderly people, should satisfy the needs of Motor, Visual, Hearing, and
Cognitive impairments.
3. Identification of existing systems and supporting technologies
a. Minimum set up (emergency calls for illnesses; gas alarm,
flooding alarm, fire alarm, doors and windows automatic control by
transponder, lights sensors and remote controls, entry phone in
bedroom)
b. Comfort equipment (telephone, air conditioning, centralized
audio/video/antenna/parabola, broadband internet access, anti-
theft device)
c. Equipments for targeted users (i.e. disabled / elderly people):
(video-telephone, telemedicine, speaker phone in every room,
automatic doors and windows opening, remote control devices
and systems, personalized acoustic and visual feedbacks, track-
based transportation systems for disabled people, from bed-to
other rooms)
4. Analysis of needs and lifestyle of the beneficiaries of the domotic
systems in order to design proper services devices and human machine
interfaces.
5. Rooms design
In this step for every room will be defined the systems/services to be
implements
6. Function allocation between domotics system and traditional one
In this step the designer will define which functions will be performed by
the domotic systems and which ones by the traditional system.
7. Domotics scenario definition
i.e. night scenario vs. daylight scenario.

8. Systems specifications:
In this step the list of materials and equipments will be established.
The Italian framework about accessibility in living spaces is regulated by law
13/89 that deals with terms and manner in which accessibility has to be ensured
in living spaces and environments. Particular attention is addressed to public
spaces. Following the law 13/89, the Implemental Decree D.M. 236/89 deals
with technical aspects of accessibility in living spaces and it specifies also
parameters (e.g. minimum measures, stair features, etc.). It focuses on three
high-level requirements for accessibility living spaces:
Accessibility for motor impaired in order to guarantee usage and safety

of spaces and equipments;
Visibility for visual impaired in order to guarantee the access to every

living space and equipment;
Adaptability of living spaces and structures forward in time in order to

make it accessible for future needs.
Every new building have to observe DM 236/89 prescriptions and old buildings
have to be adjusted according to the decree in case of renovation.
1.2.4 Spain
The article 9 of the Spanish Constitution demands to the politic powers to grant
the maxim lifes wellbeing to all citizens, turning easier their participation in the
political, economic, cultural and social life. For this reason the Spanish
Constitution in the article 49, aware that there is a considerable group of
spanish citizens which have physical disabilities, mental or sensory impairment,
creates the policy of planning and integration of such group.
On the other hand, the article 148.1.3 and 20 of the constitutional text gives to
the Autonomic Communities the responsibility in the matter of territories
ordering, housing and social assistance. As a consequence of this
responsibility almost each Autonomic Communities have created their own
accessibility regulations too.
Regarding the state general laws these are the most important ones:
Royal Decree law 505/2007, 20th of April defines the basic conditions of
accessibility and no discrimination of people with disabilities to access
and use of public spaces and buildings.
Law 51/2003, 2nd of December, Equal opportunities, non discrimination

and universal accessibility for people with disabilities.
Law 15/1995, 30th of May, domain boundaries on properties to remove

architectural barriers to persons with disabilities.
Royal Decree law 556/1989, 19th of May, definition of the buildings

accessibility minimum measures.
Order of the 3th of May of 1980, relating the entrances, lifts and indoor
conditions of houses projected for people with disabilities.
In Spain doesnt exist any typical design process but it exists the Technical
Building Code (CTE) which is followed by the architects when they want to
create and plan their infrastructures. The CTE is the normative frameworks with
the intention of establish the safety and habitability requirements of buildings set
out in the building act (LOE).
The basic requirements of safety and habitability are established by Law 38/1999 of
November 5, Buildings ordination.
The CTE also regulates the matters related with the Accessibility based in the
law 51/2003 of 2th of December, of Equal opportunities, non discrimination and
universal accessibility for people with disabilities referred before.
The Spanish Acts (LOE) "express aim is to regulate basic aspects of the
construction process, setting out the obligations and responsibilities of the all
those involved in the process, as well as the necessary guarantees for it proper
implementation, in order to safeguard the quality of buildings via compliance
with these basic requirements and to ensure the adequate protection of users
interests.
It has the objective to establish the followed essential requirements which must
be fulfilled to reassure the welfare of society, the protection of the environment
and the safety of people:
Related to functionality (use, accessibility and access to
telecommunication, audio-visual and information services).
Related to safety (structural, in case of fire, and of use).
Related to habitability (hygiene, health and protection of the environment,
protection from noise, energy conservation, heat insulation and other
functional aspects).
1.2.5 Greece
In Greece, all architectural planning and design activities are guided by a
federal legal regulation called General Building Regulation. The General
Building Regulation
(GBR) provides all engineers that interfere to the construction of a building with
guidelines on how to do so. The general steps that are followed for the design
of a building are the following:
1. Identify the building usability and needs
Home
o Block of flats
Number of flats, flats per floor

Number of rooms
Sqm per flat
o House
Number of rooms
o Student flats
o Etc.
Office
Public building
Etc.
2. Restrictions of the area
In terms of
o Usage
o Height
o Square metres
o Roof
3. Design
a. Topographic
b. Building location within the plot, considering
i. The restrictions (step 2)
ii. The orientation
iii. The bioclimatic design
iv. The correlation of the coterminous buildings
v. The ground topology
c. Architectural Design (i.e. in case of block of flats)
i. Staircase
ii. Room location
iii. Room design
iv. Secondary areas (parking, warehouses, boiler room,
engine room, etc.)

v. Surrounding space (entrance, garden, parking, etc.)

vi. Floor height
vii. Material selection
viii. Accessibility
d. Static design
e. Mechanical design
i. Water instalments
ii. Drainage instalments
iii. Electrical instalments
o Accessibility
iv. Gas
v. Fire instalments
o Accessibility
vi. Heating/cooling
o Accessibility
vii. Elevators
o Accessibility
f. Energy efficiency design
Within the GBR there are also accessibility guidelines, rules and constraints.
According accessibility constraints, the Office of Research on People with
Special Needs (SEN) of the Ministry of environment, energy and climate change
as part of the effort undertaken to promote the possibility of autonomous
movement and welfare of all citizens, recommended by technical working
groups - representatives of various ministries and agencies, which coordinated
by the Head of Office in the period 1986 - 1990, produced the "Design Guide for
the Independent Living Movement and disabilities" that can be used for
designing for spaces intended for the use of SEN and includes:
Anthropometric data
Open places design for pedestrians
Ramps for people and wheelchairs
Electrical and mechanical installations
Toilets
Marking
Stairs
Door frames

Floor
Living, dining, kitchens, bedrooms
Sports and recreation facilities
Tourist facilities
Performing arts - theater, cinema facilities
Office buildings and public services
Sidewalks
Signing plates

2 The VERITAS Smart Living Spaces Design

Process
The previous chapter gave a detailed overview on the state-of-the-art of
architectural planning and design processes for Smart Living Spaces. It became
obvious that in current industrial practice, planning Smart Living Spaces,
especially those for elderly people or people with disabilities, is a complex
process with many requirements and constraints to be considered by all
stakeholders involved. Although a wealth of best-practices, regulations, and
normative technical rules exist there is no systematic approach to validate
design solutions especially involving the end-users themselves in the sense of
UCD.
This is mostly due to resource limitations within the process, e.g. limited time
and money, but also due to the lack of validations means. Planning and
constructing Smart Homes or buildings in general, public and private alike is
a highly individual, creative and organisational process. Each customer (and
end-user) has different individual needs, each project has its own individual
context and thus each building is a unique product, manufactured only once.
Compared to mass production, e.g. in automotive or electronics industry, where
it is crucial to plan, test, and validate any aspect of a newly designed product
beforehand, since errors reproduce and are hard to eliminate after start of
production, producing elaborate prototypes of a building is not feasible
economically as well as technically.
This is where virtual prototypes come in: Although it is not possible to build a
fully functional, physical (i.e. real) prototype of a building to be erected, it is
definitely feasible and reasonable to have a IT-based virtual simulation of the
building in the same way as the automotive industry uses digital mock-ups
(DMUs) to simulate and evaluate their design concepts.
In the VERITAS project, this simulation aspect is twofold. First, the building itself
with all its technical components, especially the domotics devices, can be
simulated in a Virtual Reality environment. This gives the designer (and also the
customer/end-user) the chance to experience the design before it is being built.
This virtual experience serves a number of valuable purposes in parallel:
communication within the design team as well as with the customer, quality
control is the sense of a virtual building assessment, and decision support while
comparing different design alternatives. Secondly, in VERITAS the simulation
also covers virtual humans, especially those with special needs. Through
simulating the end-user living and working, i.e. using the virtual building usability
and accessibility of building become feasible. Moreover, since no real users
have to be involved, this assessment can take place at any time, and in as
many iterations necessary to make sure to meet the end-user requirements
while at the same time reducing the resources required to do so.
A novel Virtual Reality tool based on architectural and domotics simulation, the
VERITAS Development Support System for Smart Living Spaces, is the key

component facilitating this new kind of design and development process. The
tool itself will be presented in more detail in Internal Deliverable ID2.3.1
Development Support System Concept and Architecture for Smart Living
Spaces.
In the following sections, the context of use for this tool will be presented: its
users and the process it will be embedded into. Hence, we will first give an
overview on the stakeholders involved in the VERITAS Smart Living Spaces
Design Process. Then we will describe the process and its phases in more
detail.
2.1 Stakeholders
Typically a large number of people with varying backgrounds and areas of
expertise are involved in the Smart Living Spaces Design Process. For the sake
of simplicity we group them in the following categories:
Customers
Since Smart Living Spaces may be public buildings as well as private
homes, this group encompasses all the people defining the requirements
of the final outcome. Hence, this may be the end-users themselves (with
or without special needs) when commissioning a private house or home.
But this may also be intermediaries like public bodies or investors
planning a building to be later used by other people themselves (with or
without special needs), e.g. a home for elderly.
As stated above, the common denominator of this group of people is that
they are defining the project requirements. On the one hand, the
requirements are generally functional, e.g. what type of building, how
many rooms, which technical equipment, but on the other hand also
special usability requirements, e.g. wheelchair accessibility, design for
vision-impaired people, etc.
Technically speaking, the customers provide the input to the virtual
human simulation, i.e. the User and Task models.
Designers
This group encompasses any design experts directly concerned with
finding the first hand architectural solution to the customer requirements:
architects, interior designers, project management and marketing.
The designers define the building layout and its general appearance.
They communicate and negotiate directly with the customers. They are
also responsible for managing the engineers (see below) and integrating
the engineering solutions together into a working overall design. Thus the
designers have particular interest in design evaluation and assessment
using the Development Support System.
From a technical perspective, the designers provide the basic 3D model
of the building with all its structural features such as doors, windows,
staircases, rooms, etc. This data is provided to the engineering team as

the foundation for their technical design and serves as Scene models for
the virtual simulation.
Engineers
This group comprises all experts concerned directly or indirectly with the
buildings technical design and equipment: structural, mechanical,
heating, ventilation, air-conditioning, lighting, safety, ICT, AV, domotics
etc.
The engineers work is based on the architectural design provided by the
designers (see above). The engineers provide detailed technical
solutions in their respective fields, augmenting the designers building
framework with functional components. Engineering solutions are heavy
inter-dependant and have to be properly integrated into the overall
design concept. Hence, the engineers, too, make use of the
Development Support System to evaluate their technical design either
individually or in conjunction with the other subsystems of the building.
In the context of VERITAS the outcome of engineering activities are
functional virtual simulations of the technical equipment mainly the
domotics network and the list of smart domotics devices to be integrated
into the overall virtual building prototype for evaluation.
2.2 Process Steps

The VERITAS Smart Living Spaces Design Process is based on the UCD
process presented in
. However, due to the correlations and interdependencies inherent in the work

of designers and engineers (see section Stakeholders), the linear, sequential
structure is transformed into an iterative version in Figure 2.
Figure 2: The VERITAS Smart Living Spaces design process
The process steps include the following activities:

1. Requirements Collection
o Collection of end-user requirements
Constraints and context

Functional and technical

Usability and accessibility
o Configuration of decision support system for later design
evaluation
Regulations, normative rules
Checklists
o VERITAS: Definition of User and Task models
2. Design (Refinement)
o Architectural design of building using 3D Design tool (CAS,
Modeller, CAD, AEC)
o Engineering design of domotics solution using Smart Devices
library, Device Network editor
o Outcomes: (Refined) Technical specifications of building and its
technical infrastructure
3. Virtual Prototyping
o Export of 3D models to simulation using A2.1.4 data conversion
plans/tools
Fidelity increasing from low to high over iterations
Static, non-functional base of prototype
o Functional virtual prototype by integration of domotics simulation
Placement of Devices in architectural 3D model
Definition of Device behaviour
o Integration of virtual User and Task models
4. Design Evaluation
o Application of VERITAS Development Support System for Smart
Living Spaces with Designers and Engineers
Immersive building simulation
Smart Devices simulation
o User requirements evaluation
o If refinement is needed, go back to step 2, else proceed to step 5.
5. Design Approval

o Application of VERITAS Development Support System for Smart

Living Spaces with Customer
o User requirements approval
o Preparation of implementation, i.e. construction of building

3 Simulation of Smart Living Spaces

The following chapter will resume the results of task analysis and use cases
description performed in WP1.7 and the virtual user model files generated by
the VERITAS model platform (WP1.6). We will take our focus on domotic
applications, a specific manifestation of smart living spaces, to simulate the user
in his private environment.
3.1 General approach

To generate simulation models for the simulation of domotic applications, the
following steps have to be performed:
Definition of domotic situations: in the first step we need to remember,
what domotic situations should be considered by this document.
Extraction of devices: the next step is to extract devices, that are used
for the described domotic situations. This also defines our use cases.
Task analysis: tasks and sub-tasks are extracted from use cases
definition of previous step.
Primitive tasks extraction: each sub-task is deeply analyzed and
divided into atomic tasks called also primitive tasks.
Specification of disabilities related with the primitive tasks: keeping
in mind the disabilities and/ or psychological states suffered by a user
considered in VERITAS, a set of impairment, disabilities and P&B states
should be selected according to specific sub-tasks and/or primitives.
Specification of alternative primitive tasks: for each disability an
alternative primitive task has to be defined to bypass or try to bypass the
gap by objective.
Extraction of properties: in this step we need to extract properties from
primitive tasks and task objects, that are relevant to perform that tasks.
Interaction analysis: Each task to be conducted requires interactions.
The interactions are defined in terms of modality, object and means.
Simulation models: Since the task and interaction analysis are in
place, the process can be completed with the generation of simulation
models. This activity will apply the UsiXML [5].
3.2 Definition of domotic situations

To simulate domotic applications we need to define first, what domotic
applications means. A simple definition are all the things we (can) do at home.
For VERITAS we want to analyze, what this means for impaired people. To
make this simple, we want to pick some domotic situations and we list them on
Table 1:

Table 1: Domotic situations
Domotic situation What does this mean
The user needs to open and close doors. He/she

Opening, closing and passing
needs to know, if the door is open and also needs
doors
to pass the door.
The user needs to turn on and off lamps. He/she

Switching on and off lamps
also needs to know the enabled state of a lamp.
The user wants to load his/her fridge and wants to

Use of a fridge pick up some goods from there. He/she also needs
to open and close the fridge door.
The user wants to load and unload his washing

machine. He/she needs also to turn on and off the
Use of a washing machine
washing machine. He/she needs to know its
enabled state.
The user wants to cook. For this he/she needs to

put/take a cooking pot on/from the cooker and turn
Use of a cooker
it on and off. He/she needs to know its enabled
state.
The user wants to turn on and off the exhaust hood.

Use of an exhaust hood
He/she also needs to know its enabled state.
The user wants to turn on and off the oven. He/she

also wants to put food inside and take it out. He/she
Use of an oven
needs to open and close the oven door. He/she
also needs to know the enabled state of the oven.
The user wants to wash his/her dishes. He/she

wants to turn on and off the dishwasher and wants
to know its enabled state. The user needs to open
Use of a dishwasher and close the dishwasher door. He/she also needs
to find an empty tray inside the dishwasher and
wants to put dishes on it, or take dishes out of the
dishwasher.
For comfort in domotic environments a motion

detector is a must have. Such devices are used
Detecting motion massively in our todays live. Most of the are used
to enable lights. The user needs only to move or
wink with his hands.

Domotic situation What does this mean
For extended comfort in domotic environments the

system (which is a house, a flat or even a single
Detecting presence chair) want to know, who is there. To simplify this, a
presence detector needs to know only, if a user is
there or not.
For extended comfort and security purposes in

domotic environments a collision detector is a must
have. It can detect, if the system and the user
Detecting collisions collide. For example the automatically closing doors
need to respond to an obstacle and stop to close
immediately. Or if the (old) user has toppled the
system can call a nurse of its own.
For security purposes every domotic environment

need an alarm signal, like a siren and/or a flashing
Alarm state
light. Today smoke detectors or intruder alarms are
installed in plenty of homes.
3.3 Extraction of devices

Table 1 summarizes the devices, which are needed for the described domotic
situations. Table 2 shows such devices and defines the use cases for each
device. Also a simulation kind is defined, which defines, how the device is going
to be simulated (what and how device states will be shown to the simulator
user):
Table 2: Use cases for simulated devices
Device Use case(s) Simulation kind
Pass the door, Open and close

Sliding Door Open and close
door manually
Pass the door, Open and close

Swing Door Open and close
door manually
Motion Detector Detect motion Passive, detects motions
Passive, detects presence of

Presence Detector Detect user
user
Collision Detector Detect collision Passive, detects collisions
Light Switch Toggle switch On and off state of the rocker

Device Use case(s) Simulation kind
Lamp Check, if lamp is on Alter brightness
Open and close door, show 2

Fridge Load, take good
trays with (optional) goods
Open and close door, on and

Load/Unload, use of washing
Washing Machine off, 30 second washing
machine
program, control lamp
Exhaust Hood Use of exhaust hood On and off, makes noise
Open and close door,

Oven Load/Unload, turn on/off oven optionally food inside, on and
off
Cooking pot (optionally) on the

Cooker Cooking
cooker, on and off
Load/Unload, turn on/off Open and close door, show 2

Dishwasher
dishwasher trays with (optional) dishes
Siren Alarm Makes noise
Flashing Lamp Alarm Flashing light
Passive simulation kind means, there is no visual feedback in the simulation to

the user. These devices produce signals only for the simulator, which handles
them to trigger functions on other devices. Also the simulator will be able to join
multiple signals and device states to form up a high level of domotic logic.
3.4 Task analysis and extraction of primitive tasks

Knowing the devices the user can interact with and the goals (use cases), we
can now perform the task analysis. For that we need some definition here:
3.4.1 Definition of task

A task is an high level concept representing a sequence of actions which must
be completed by the user in order to achieve a complex goal. There is not
necessarily a constraint on the order of the actions that must be performed. A
task usually involves a number of interactions between the end user and the
system.

Figure 3: Definition of task
3.4.2 Definition of sub-task

A sub-task is a complex action that represents an intermediate goal that must
be completed (along with other goals) by the user in order to accomplish a task.
The granularity of sub-tasks is variable, depending on the nature of the task to
be accomplished and also on how the task decomposition can be done with
respect to its components.
Figure 4: Definition of sub-task
3.4.3 Definition of primitive task

A primitive task is an atomic action that can be performed by the user. It can't
be divided into smaller sub-tasks. A primitive task is typically associated with a
set of attributes which are defined in a UsiXML file called a Multimodal
Interaction Model and describes the following parameters of a primitive task:
means (of interaction): the part of the human body that is usually used
to perform the interaction between the user and the system.
modality: the functional capability of the human body that is involved in
the performance of the action.
object: the part of the system involved with the interaction with the user.

Figure 5: Definition of primitive task

In addition a sub-task can specify an alternative primitive task (or tasks), if the
first one can't be performed by the user because of impairments.
Table 6 extracts the tasks from the use cases listed in Table 2 and categorizes
them into sub-tasks and primitive tasks. Also disabilities for selected primitive
tasks are listed and alternatives are suggested. However, we do not list all kinds
of disabilities, because that list would never end. The relevant disabilities are:
reduced vision
wheelchair user
reduced hearing
Most of domotic tasks need the user to use his hands. Disadvantages in that
would result in an attendant, who helps the user to perform the tasks. Today
some simple tasks like switching a light can be performed using voice
recognition or even to whistle. But this is not going to be simulated in VERITAS
and will be ignored here.
For simulation only primitive tasks are relevant. Table 3 extracts them from the
task analysis for domotic applications from Table 6:
Table 3: Primitive Tasks in Simulation
Primitive Part of the Description

Task body
Check Eyes, hands, Used to get a state of a device. For eyes the
ears devices needs to provide a visual state. For hands
the devices needs to provide a touchable state. For
ears the devices needs to produce noise.

Primitive Part of the Description

Task body
Walk Feet Used to move the user from one to another position.
Drive Hands Used to move the user from one to another position.
Locate Eyes, Hands Used to locate something. For eyes it needs to be

visible. For hands it needs to be touchable (and of
course reachable).
Reach Hands For interaction, the user needs to reach devices or

parts of it with his hands.
Grasp Hands The user needs to grasp something. Sometimes this

include to lift the object, which consumes extra
energy.
Release Hands The user releases something. This requires the user
to open his hand(s).
Push Hands Used to push something. This consumes user

energy.
Pull Hands Used to pull something. This consumes user energy

as well as extra energy to hold the thing in hands
while pulling.
3.5 Extraction of properties

For each primitive task and body part combination sets of properties can be
defined. For example for the primitive task Push and the body part Hands the
set Pushable defines the force in Newton, which is needed to accomplish the
task. Table 4 defines such sets of properties:
Table 4: Property sets for primitive tasks
Property- Task - body part Properties (Units)

set combination
Visible Check, locate Eyes Brightness (lux)
Touchable Check, locate Hands Temperature (C), width (m), height (m)
Hearable Check Ears Volume (dB)

Property- Task - body part Properties (Units)

set combination
Traversable Walk Feet Length of the pass (m), width of the pass
(m)
Reachable Reach Hands Horizontal distance (m), vertical distance

(m)
Graspable Grasp, release Hands Mass (kg), width (m), height (m), length
(m)
Moveable Push, pull, drive Hands Force (N)
Knowing the property sets for primitive tasks we can now select properties on
task objects from Table 6, which are relevant for tasks. If the user performs a
task, he needs to do the necessary primitive tasks with property values, that
matches the properties of the task objects. Only this assure that the primitive
tasks can be performed. This means, that the user can finish the task
successfully. Table 5 shows properties selected for task objects, the
environment and the user itself:
Table 5: Properties on task objects
User / Environment / Task Properties (Units)

object(s)
User Reduced vision? (%), Reduced hearing? (%),

Wheelchair user? (bool), position (x, y, z),
maximal horizontal reachability (m), maximal
vertical reachability (m), push force (N), pull force
(N), lifting & carrying capacity (kg)
Environment Brightness (lux), area position (x, y, z), area

radius (m)
Sliding Door Force to open (N), force to close (N), width of the
pass (m), position (x, y, z)
Swing Door, Fridge Door, Force to open (N), force to close (N), width (m),
Washing Machine Door, Oven max open angle (), position (x, y, z)
Door, Dishwasher Door
Door handle Force to push (N), position (x, y, z)

User / Environment / Task Properties (Units)

object(s)
Motion Detector Area position (x, y, z), area radius (m)
Presence Detector Area position (x, y, z), area radius (m)
Collision Detector Triggering acceleration (m/s), position (x, y, z)
Light Switch, Power Button, Force to toggle/change state (N), position (x, y, z)
Oven controller, Cooker
controller
Lamp, Control Lamp, Flashing Brightness (lux), position (x, y, z)

Light
Fridge, Oven, Cooker, Tray Position (x, y, z)
Good, Food, Cooking pot, Temperature (C), mass (kg), width (m), height
Dishes (m), length (m), position (x, y, z)
Exhaust hood, Siren Volume (dB), position (x, y, z)
To make it simple the area-related environment and task objects are modeled
as circles / spheres.
3.6 Example
The following example describe the domotic situation Switching on a lamp. We
assume here the user knows the lamp is off:
1. locate the switch: the first thing the user needs to do is to locate the
corresponding switch. He can do this by eyes or by hands. If the user
has a reduced vision, he needs to do this by hands. To check this, we
can look onto the user property for reduced vision. If there is a reduced
vision, the user needs to use his hands to locate the switch. Also if the
current environment the user is in has a low brightness (which is an
individual constant we need to specify in tests), the user maybe can't see
the switch and will need his hands.
a) The user can see the switch. This can be checked by using the
property-set Visible. If the brightness of the current environment the
user is in is high enough making the switch visible to the user, then
the he can locate the switch using his eyes.
b) The user can't see the switch. He needs his hands to locate it. This
can be checked by the property-set Touchable. Of course the switch
needs to be big enough to be tangible. For simulation we can move

the mouse over the switch (which is not visible) and print a small tool-
tip, if the mouse is over the switch. That way we can simulate the
hunting for the switch.
2. reach the switch: assuming that the user has found the switch by eyes,
he needs to reach it as the next step. If the user has found the switch by
hands, he already reached it. To check this, the Reachable property-set
can be used. It determines the horizontal and vertical distance from the
user to the switch. If this distance is equal or smaller as the specified
user maximum horizontal and vertical reachability, then the user has
reached the switch. Both positions of the switch and the user can be
used to calculate the distances.
3. push the switch: assuming that the user is in distance of the switch, the
next step is to push the switch. He can do this only using his hands. Of
course, for such simple thing as a switch, for example, the user can use
a cane to reach and push the switch. But this complex action will be not
modeled here. To check, if the user can push the switch, the property-set
Moveable can be used. It describes the necessary force for the switch
needed to push it. If the user can push with that force, then the switch will
be pressed/toggled.
3.7 Interaction analysis

Each primitive task and their alternatives defines the mean of interaction, for
example feet, eyes or hands. Also it defines the task object, the mean of
interaction interacts with. To complete this picture a modality is specified, which
defines the type of the primitive task.
This step is performed in Table 6.
3.8 Simulation models

To finalize the process and create the simulation models we want to use the
task models in UsiXML [5]. This language describes some models, which one of
them is the task model. A task model consist of task and relationships between
tasks.
3.8.1 Definition of task model tasks

The needed tasks for our purposes are:
abstract task: task used to abstract a situation, usually used as a super
task for other sub-tasks
application task: this task describes a work performed by the system
user task: this task describes a work performed by the user
interaction task: this task describes an interaction of the user with the
system

3.8.2 Definition of task model relationships

Tasks are related to each other with so-called temporal operators. The following
temporal operators are defined:
>> enabling: performing and finishing the source task will enable the
target task, which will be then performed as next task
[]>> enabling with info exchange: performing and finishing the source
task will enable the target task, which will be then performed as next
task. Collected information of the source task will be passed to the target
task.
[] choice: this is an exclusive or between the source and the target task,
only one of them will be performed
|=| order independency: the source and the target tasks can be
performed consecutively in an voluntary order
||| concurent: the source and the target tasks can be performed in
parallel
|[ ]| concurent with info exchange: the source and the target tasks can
be performed in parallel while exchanging information at the same time
[> disabling: execution of the target task cancels the execution of the
source task, which usually is an iterative task
|> suspend/resume: execution of the target task cancels the execution
of the source task, which usually is an iterative task. After the target task
has finished his work, the source task resumes his execution.
[T] optional task: T is the name of the Task. The parenthesis makes the
corresponding task optional. An optional sub-task is not necessary to
finish its super task.
T* iterative task: T is the name of the Task. The asterisk makes the
corresponding task iterative. An iterative task repeats its work until a
disabling or suspending task is executed.
3.8.3 Creation of simulation models

To create the simulation models, we use the UsiXML to describe the tasks and
sub-tasks from Table 6. Primitive tasks are modeled as interaction tasks using
the interaction analysis to define their names. For example the interaction task
generated by the primitive task Push (hands) of the task Turn on a light
switch will be renamed to Push(object:light
switch)(means:hands)(modality:motor).
All created simulation models in UsiXML for all defined devices an use cases
can be found in the appendix on the end of this document.

4 Appendix
4.1 Task analysis
Table 6 lists the task analysis for domotic applications.
Table 6: Task analysis for domotic applications
Primitive
Subtask Alternative
tasks
(numbers Alternative Alternative task object /
Device Task (numbers Modality Task object Disability
indicate task(s) modality assistive
indicate
alternatives) device
alternatives)
Get aware Check Reduced Check

Vision Sliding Door Motor =
of open door (eyes) vision (hands)
Pass the
sliding door
Wheelchair Drive
Pass Walk (feet) Motor Sliding Door Motor =
user (hands)

Sliding Door Vision Sliding Door Motor =
Open and
close sliding Locate Reduced Locate
Vision Door handle Motor =
door (eyes) vision (hands)
manually Open
Reach
Motor Door handle = = = =
(hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Grasp
(hands)
Push
Motor Sliding Door = = = =
(hands)
Release
(hands)
Locate Reduced Locate

(eyes) vision (hands)
Reach
(hands)
Close
Grasp
(hands)
Pull (hands) Motor Sliding Door = = = =
Release Motor Door handle = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)

Vision Swing Door Motor =
Pass the
swing door
Wheelchair Drive
Pass Walk (feet) Motor Swing Door Motor =
user (hands)

Vision Swing Door Motor =
Swing Door Locate Reduced Locate

Open and
close swing
Reach
door Motor Door handle = = = =
(hands)
manually Open
Grasp
(hands)
Push Motor Door handle = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Push
Motor Swing Door = = = =
(hands)
Release
(hands)

Reach
(hands)
Close Grasp
(hands)
Push
(hands)
Pull (hands) Motor Swing Door = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Release
(hands)
Locate Motion Reduced Locate

Vision Motor =
Be in front (eyes) Detector vision (hands)
of motion
detector Motion Wheelchair Drive
Walk (feet) Motor Motor =
Detector user (hands)
Motion Detect
Detector motion
Motion Wheelchair Drive
Detector user (hands)
Produce
motion
Wink Motion
Motor = = = =
(hands) Detector
Presence Presence
Detect user Be there Passive = = = = =
Detector Detector
Collision Detect Produce Collision Wheelchair Drive

Detector collision collision Detector user (hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Detect
Check Reduced Check
enabled Vision Light switch Motor =
state

Vision Light Switch Motor =
Reach
Turn on Motor Light Switch = = = =
(hands)
Toggle
Light Switch Push
switch Motor Light Switch = = = =
(hands)

Vision Light Switch Motor =
Reach
Turn off Motor Light Switch = = = =
(hands)
Push
Motor Light Switch = = = =
(hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Check, if Detect Check Reduced

Lamp Vision Lamp = = =
lamp is on Illumination (eyes) vision

Reach
(hands)
Open door Grasp

(hands)
Fridge Load
Pull (hands) Motor Fridge Door = = = =
Release
(hands)
Locate Locate Reduced Locate

Vision Empty tray Motor =
empty tray (eyes) vision (hands)
Put goods Locate Vision Good Reduced Locate Motor =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
onto empty (eyes) vision (hands)

tray
Reach
Motor Good = = = =
(hands)
Grasp
Motor Good
(hands)
Reach
Motor Empty tray = = = =
(hands)
Release
Motor Good = = = =
(hands)

Close door Reach

(hands)
Grasp Motor Door handle = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Push
Motor Fridge Door = = = =
(hands)
Release
(hands)

Reach
(hands)
Take good Open door Grasp

(hands)
Pull (hands) Motor Fridge Door = = = =
Release
(hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)

Vision Good Motor =
Reach
Take Motor Good = = = =
(hands)
Grasp
Motor Good = = = =
(hands)

Reach
(hands)
Close door
Grasp
(hands)
Push
Motor Fridge Door = = = =
(hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Release
(hands)

Reach
(hands)
Grasp
(hands)
Washing Load/Unloa
Open door
Machine d Push
(hands)
Washing
Pull (hands) Motor Machine = = = =
Door
Release
(hands)

Primitive
Subtask Alternative
tasks
indicate
alternatives)

Vision Clothes Motor =
Reach
Motor Clothes = = = =
(hands)
Put/Take Grasp
clothes (hands)
into/from
washing Locate Reduced Locate
Vision Barrel Motor =
machine (eyes) vision (hands)
Reach
Motor Barrel = = = =
(hands)
Release
(hands)

Close door Vision Door handle Motor =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
Reach
(hands)
Grasp
(hands)
Push
(hands)
Washing
Push
Motor Machine = = = =
(hands)
Door
Release
(hands)
Detect
Check Control Reduced
Use of washing Vision = = =
(eyes) lamp vision
washing state
machine
Turn on/off Locate Vision Power Reduced Locate Motor =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(eyes) button vision (hands)
Reach Power
Motor = = = =
(hands) button
Push Power
Motor = = = =
(hands) button
Detect
Check Exhaust Reduced Check Control
enabled Hearing Vision
(ears) hood hearing (eyes) lamp
state
Locate Power Reduced Locate

Use of Vision Motor =
Exhaust (eyes) button vision (hands)
exhaust
Hood
hood
Reach Power
Turn on/off Motor = = = =
(hands) button
Push Power
Motor = = = =
(hands) button

Primitive
Subtask Alternative
tasks
indicate
alternatives)

Reach
(hands)
Open door Grasp

(hands)
Pull (hands) Motor Oven Door = = = =

Load/Unloa
Oven
d
Release
(hands)

Vision Food Motor =
Insert/Take
Reach
Food Motor Food = = = =
(hands)
Grasp Motor Food = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Locate Reduced Locate Insulating

Vision Oven Motor
(eyes) vision (hands) gloves
Reach
Motor Oven = = = =
(hands)
Release
Motor Food = = = =
(hands)

Reach
(hands)
Close door
Grasp
(hands)
Push Motor Oven Door = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Release
(hands)
Detect oven Check Oven Reduced Check

Vision Motor =
state (eyes) controller vision (hands)
Locate Oven Reduced Locate

Vision Motor =
(eyes) controller vision (hands)
Turn on/off
oven
Reach Oven
(hands) controller
Push Oven
Motor = = = =
(hands) controller

Vision Cooking pot Motor =
Put cooking (eyes) vision (hands)
Cooker Cooking pot on
cooker
Reach Motor Cooking pot = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Grasp
Motor Cooking pot = = = =
(hands)

Vision Cooker Motor
Reach
Motor Cooker = = = =
(hands)
Release
(hands)
Detect Check Cooker Reduced Check

Vision Motor =
cooker state (eyes) controller vision (hands)
Locate Cooker Reduced Locate

Vision Motor =
(eyes) controller vision (hands)
Turn on/off
Reach Motor Cooker = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands) controller
Push Cooker
Motor = = = =
(hands) controller

Vision Cooking pot Motor
Reach
Take (hands)
cooking pot
from cooker Grasp Insulating
Motor Cooking pot = = =
(hands) gloves
Release Insulating
Motor Cooking pot = = =
(hands) gloves

Load/Unloa (eyes) vision (hands)
Dishwasher Open door
d
Reach Motor Door handle = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)
Grasp
(hands)
Dishwasher
Pull (hands) Motor = = = =
Door
Release
(hands)
Locate Locate Reduced Locate

empty tray (eyes) vision (hands)

Vision Dishes Motor =
Insert/Take
Reach
Dishes Motor Dishes = = = =
(hands)
Grasp Motor Dishes = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands)

Reach
Motor Empty tray = = = =
(hands)
Release
Motor Dishes = = = =
(hands)

Reach
(hands)
Close door
Grasp
(hands)
Push Motor Dishwasher = = = =

Primitive
Subtask Alternative
tasks
indicate
alternatives)
(hands) Door
Release
(hands)
Detect
Check Control Reduced Check
dishwasher Vision Hearing Dishwasher
(eyes) lamp vision (ears)
state
Locate Power Reduced Locate

Vision Motor =
Turn on/off (eyes) button vision (hands)
dishwasher
Reach Power
(hands) button
Push Power
Motor = = = =
(hands) button
Detect Check Reduced Check Flashing

Siren Alarm Hearing Siren Vision
alarm (ears) hearing (eyes) Light

4.2 Generation of UsiXML files

UsiXML V1.8 is the user interface description language used by Veritas. It aims at expressing user interfaces built with various modalities
of interaction and independently of them. UsiXML is XML-compliant to enable flexible exchange of information and powerful
communication between models and tools used in user interface engineering. The UsiXML files for the simulation model, task model and
multimodal interaction model file are created from the overall simulation task table.
Overall, the Simulation Models included in this deliverable cover all use case scenarios for both Workplace Design and Collaborative
tools sub-domains. In the Simulation Models task sequences are represented up to sub-task level, while complex tasks in turn are further
analysed into primitive tasks in the respective Task Models.
The UsiXML code for the simulation models is included in the Annex of this deliverable while the UsiXML files themselves are available
from the website and the FTP repository of the project.
4.2.1 Collision detector

<?xml version="1.0" encoding="UTF-8"?>
<taskmodel>
<task id="st0task0" name="Detect_collision" type="abstraction">
<task id="st0task1" name="produce_collision" type="abstraction">
<task id="st0task2" name="Walk(object:motion detector)(means:feet)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Drive(object:motion detector)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<deterministicChoice>
<source sourceId="st0task2"/>
<target targetId="st0task3"/>
</deterministicChoice>
</taskmodel>
Listing 1: UsiXML code for Detect collision

Figure 6: Detect Collision
4.2.2 Cooker

<taskmodel>
<task id="st0task0" name="Cooking" type="abstraction">
<task id="st0task1" name="put_cooking_pot_on_cooker" type="abstraction">
<task id="st0task2" name="locate" type="abstraction">
<task id="st0task3" name="Locate(object:cooking pot)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task4" name="Locate(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task5" name="Reach(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task6" name="Grasp(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task8" name="Locate(object:cooker)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task9" name="Locate(object:cooker)(means:hands)(modality:motor)" type="interaction"/>

</task>
<task id="st0task10" name="Reach(object:cooker)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task11" name="Release(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task12" name="detect_cooker_state" type="abstraction">
<task id="st0task13" name="Check(object:cooker controller)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task14" name="Check(object:cooker controller)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task15" name="turn_on_off" type="abstraction">
<task id="st0task17" name="Locate(object:cooker controller)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task18" name="Locate(object:cooker controller)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task19" name="Reach(object:cooker controller)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task20" name="Push(object:cooker controller)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task21" name="take_cooking_pot_from_cooker" type="abstraction">
<task id="st0task23" name="Locate(object:cooking pot)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task24" name="Locate(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task25" name="Reach(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task26" name="Grasp(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task27" name="Release(object:cooking pot)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>

Listing 2: UsiXML code for Cooking

Figure 7: Cooking
4.2.3 Dishwasher


<taskmodel>
<task id="st0task0" name="Load_unload" type="abstraction">
<task id="st0task1" name="open_door" type="abstraction">
<task id="st0task3" name="Locate(object:door handle)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task4" name="Locate(object:door handle)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task5" name="Reach(object:door handle)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task6" name="Grasp(object:door handle)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task7" name="Pull(object:dishwasher door)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task8" name="Release(object:door handle)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task9" name="locate_empty_tray" type="abstraction">
<task id="st0task10" name="Locate(object:empty tray)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task11" name="Locate(object:empty tray)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task12" name="insert_take_dishes" type="abstraction">
<task id="st0task14" name="Locate(object:dishes)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task15" name="Locate(object:dishes)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task16" name="Reach(object:dishes)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task17" name="Grasp(object:dishes)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task21" name="Reach(object:emptry tray)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task22" name="Release(object:dishes)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task23" name="close_door" type="abstraction">


</task>
<task id="st0task29" name="Push(object:door handle)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task30" name="Push(object:dishwasher door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>

Listing 3: UsiXML code for Load & Unload a dishwasher

<taskmodel>
<task id="st0task0" name="Turn_on_off_dishwasher" type="abstraction">
<task id="st0task1" name="detect_dishwasher_state" type="abstraction">
<task id="st0task2" name="Check(object:control lamp)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:dishwasher)(means:ears)(modality:hearing)" type="interaction"/>
</task>
<task id="st0task6" name="Locate(object:power button)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task7" name="Locate(object:power button)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task8" name="Reach(object:power button)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task9" name="Push(object:power button)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 4: UsiXML code for Start & Stop a dishwasher
Figure 8: Start & stop dishwasher
4.2.4 Exhaust hood


<taskmodel>
<task id="st0task0" name="Use_of_exhaust_hood" type="abstraction">
<task id="st0task1" name="detect_enabled_state" type="abstraction">
<task id="st0task2" name="Check(object:exhaust hood)(means:ears)(modality:hearing)" type="interaction"/>
</task>
</task>
</task>
</task>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
</taskmodel>
Listing 5: UsiXML Code for using the exhaust hood
Figure 9: Using the exhaust hood
4.2.5 Fridge

<taskmodel>

<task id="st0task0" name="Load" type="abstraction">

</task>
<task id="st0task7" name="Pull(object:fridge door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task9" name="locate_empty_tray" type="abstraction">
</task>
<task id="st0task12" name="put_goods_onto_empty_tray" type="abstraction">
<task id="st0task14" name="Locate(object:good)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task15" name="Locate(object:good)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task16" name="Reach(object:good)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task17" name="Grasp(object:good)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task18" name="Reach(object:empty tray)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task19" name="Release(object:good)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<task id="st0task26" name="Push(object:fridge door)(means:hands)(modality:motor)" type="interaction"/>


</task>
</task>
<enablingWithInformationPassing>
</enablingWithInformationPassing>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 6: UsiXML code for Loading the fridge

Figure 10: Loading the fridge

<taskmodel>
<task id="st0task0" name="Take_good" type="abstraction">
</task>
<task id="st0task7" name="Pull(object:fridge door)(means:hands)(modality:motor)" type="interaction"/>


</task>
<task id="st0task9" name="take" type="abstraction">
<task id="st0task11" name="Locate(object:good)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task12" name="Locate(object:good)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task13" name="Reach(object:good)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task14" name="Grasp(object:good)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<task id="st0task21" name="Push(object:fridge door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 7: UsiXML code for taking a good

Figure 11: Taking a good
4.2.6 Lamp
<taskmodel>
<task id="st0task0" name="Check_if_lamp_is_on" type="abstraction">
<task id="st0task1" name="detect_illumination" type="abstraction">
<task id="st0task2" name="Check(object:lamp)(means:eyes)(modality:vision)" type="interaction"/>
</task>
</task>
</taskmodel>
Listing 8: UsiXML code for Check if lamp is turned on

Figure 12: Check if lamp is turned on
4.2.7 Light switch

<taskmodel>
<task id="st0task0" name="Toggle_switch" type="abstraction">
<task id="st0task1" name="detect_enabled_state" type="abstraction">
<task id="st0task2" name="Check(object:light switch)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task4" name="turn_on_or_off" type="abstraction">
<task id="st0task5" name="turn_on" type="abstraction">
<task id="st0task7" name="Locate(object:light switch)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task8" name="Locate(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
</task>

<task id="st0task9" name="Reach(object:light switch)(means:hands)(modality:motor)" type="interaction"/>

<task id="st0task10" name="Push(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task11" name="turn_off" type="abstraction">
<task id="st0task13" name="Locate(object:light switch)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task14" name="Locate(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task15" name="Reach(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task16" name="Push(object:light switch)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
</task>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 9: UsiXML code for Toggle light switch

Figure 13: Toggle light switch
4.2.8 Motion detector

<taskmodel>
<task id="st0task0" name="Detect_motion" type="abstraction">

<task id="st0task1" name="be_in_front_of_motion_detector" type="abstraction">

<task id="st0task3" name="Locate(object:motion detector)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task4" name="Locate(object:motion detector)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task5" name="move" type="abstraction">
</task>
</task>
<task id="st0task8" name="produce_motion" type="abstraction">
<task id="st0task11" name="Wink(object:motion detector)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<enabling>

</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 10: UsiXML code for detect motion
Figure 14: Detect motion
4.2.9 Oven


<taskmodel>
</task>
<task id="st0task7" name="Pull(object:oven door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task9" name="insert_take_food" type="abstraction">
<task id="st0task11" name="Locate(object:food)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task12" name="Locate(object:food)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task13" name="Reach(object:food)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task14" name="Grasp(object:food)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task16" name="Locate(object:oven)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task17" name="Locate(object:oven)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task18" name="Reach(object:oven)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task19" name="Release(object:food)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>


<task id="st0task26" name="Push(object:oven door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 11: UsiXML code for load & unload oven

<taskmodel>
<task id="st0task0" name="Turn_on_off_oven" type="abstraction">
<task id="st0task1" name="detect_oven_state" type="abstraction">
<task id="st0task2" name="Check(object:oven controller)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:oven controller)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task6" name="Locate(object:oven controller)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task7" name="Locate(object:oven controller)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task8" name="Reach(object:oven controller)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task9" name="Push(object:oven controller)(means:hands)(modality:motor)" type="interaction"/>
</task>

</task>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 12: UsiXML code for start & stop oven

Figure 15: Start & stop oven
4.2.10 Presence detector

<taskmodel>
<task id="st0task0" name="Detect_user" type="abstraction">
<task id="st0task1" name="be_there" type="abstraction">
<task id="st0task3" name="Passive(object:presence detector)(means:)(modality:)" type="interaction"/>
</task>
</task>
</taskmodel>
Listing 13: UsiXML code for detect user's presence

Figure 16: Detect user's presence
4.2.11 Siren
<taskmodel>
<task id="st0task0" name="Alarm" type="abstraction">
<task id="st0task1" name="detect_alarm" type="abstraction">
<task id="st0task2" name="Check(object:siren)(means:ears)(modality:hearing)" type="interaction"/>
<task id="st0task3" name="Check(object:flashing_light)(means:eyes)(modality:vision)" type="interaction"/>
</task>
</task>
</taskmodel>
Listing 14: UsiXML code for Alarm

Figure 17: Alarm
4.2.12 Sliding door

<taskmodel>
<task id="st0task0" name="Open_and_close_sliding_door_manually" type="abstraction">
<task id="st0task1" name="get_aware_of_open_door" type="abstraction">
<task id="st0task2" name="Check(object:sliding door)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:sliding door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task4" name="open_or_close" type="abstraction">
<task id="st0task5" name="open" type="abstraction">
</task>
<task id="st0task11" name="Push(object:sliding door)(means:hands)(modality:motor)" type="interaction"/>

</task>
<task id="st0task13" name="close" type="abstraction">
</task>
<task id="st0task19" name="Pull(object:sliding door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
</task>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>

Listing 15: UsiXML code for Open & close sliding door manually
Figure 18: Open & close sliding door manually

<taskmodel>
<task id="st0task0" name="Pass_the_sliding_door" type="abstraction">
<task id="st0task2" name="Check(object:sliding door)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:sliding door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task4" name="pass" type="abstraction">
<task id="st0task5" name="Walk(object:sliding door)(means:feet)(modality:motor)" type="interaction"/>
<task id="st0task6" name="Drive(object:sliding door)(means:hands)(modality:motor)" type="interaction"/>
</task>

</task>
</taskmodel>
Listing 16: UsiXML code for pass the sliding door

Figure 19: Pass the sliding door
4.2.13 Swing door

<taskmodel>
<task id="st0task0" name="Open_and_close_swing_door_manually" type="abstraction">
<task id="st0task2" name="Check(object:swing door)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:swing door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task4" name="open_or_close" type="abstraction">
<task id="st0task5" name="open" type="abstraction">


</task>
<task id="st0task12" name="Push(object:swing door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task14" name="close" type="abstraction">
</task>
<task id="st0task21" name="Pull(object:swing door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
</task>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 17: UsiXML code for open & close the swing door manually

Figure 20: Open & close the swing door manually

<taskmodel>
<task id="st0task0" name="Pass_the_swing_door" type="abstraction">
<task id="st0task2" name="Check(object:swing door)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task3" name="Check(object:swing door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task4" name="pass" type="abstraction">
<task id="st0task5" name="Walk(object:swing door)(means:feet)(modality:motor)" type="interaction"/>

<task id="st0task6" name="Drive(object:swing door)(means:hands)(modality:motor)" type="interaction"/>

</task>
</task>
</taskmodel>
Figure 21: Pass the swing door
Listing 18: UsiXML code for pass the swing door

4.2.14 Washing machine

<taskmodel>
</task>
<task id="st0task8" name="Pull(object:washing machine door)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task10" name="put_take_clothes_into_from_washing_machine" type="abstraction">
<task id="st0task12" name="Locate(object:clothes)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task13" name="Locate(object:clothes)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task14" name="Reach(object:clothes)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task15" name="Grasp(object:clothes)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task17" name="Locate(object:barrel)(means:eyes)(modality:vision)" type="interaction"/>
<task id="st0task18" name="Locate(object:barrel)(means:hands)(modality:motor)" type="interaction"/>
</task>
<task id="st0task19" name="Reach(object:barrel)(means:hands)(modality:motor)" type="interaction"/>
<task id="st0task20" name="Release(object:clothes)(means:hands)(modality:motor)" type="interaction"/>
</task>


</task>
<task id="st0task28" name="Push(object:washing machine door)(means:hands)(modality:motor)" type="interaction"/>
</task>
</task>
<enabling>
</enabling>
<enabling>
</enabling>

<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>

</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 19: UsiXML code for Load & Unload washing machine

Figure 22: Load & Unload washing machine

<taskmodel>
<task id="st0task0" name="Use_of_washing_machine" type="abstraction">
<task id="st0task1" name="detect_washing_state" type="abstraction">
</task>
</task>


</task>
</task>
<enabling>
</enabling>
<enabling>
</enabling>
<enabling>
</enabling>
</taskmodel>
Listing 20: UsiXML code for using the washing machine

Figure 23: Using the washing machine

5 References
[1] List of some simulation tools with a small abstract description (in English)
http://www.idsia.ch/~andrea/sim/simvis.html
[2] List of some simulation tools with a small abstract description in german:
http://www.softguide.de/software/simulation.htm
[3] Miele CAVE (Computer Aided Virtual Environment) internal simulation
tool used by Miele:
http://www.miele.de/de/en/press/article/artikel_106_2008.aspx
[4] Scilab Xcos hybrid dynamic systems modeler and simulator:
http://www.scilab.org/products/xcos
[5] UsiXML USer Interface eXtensible Markup Language
http://www.usixml.org/
[6] IdealXML Interface Development Environment for AppLications
specified in usiXML: http://www.usixml.org/index.php?mod=pages&id=15
[7] CTTE ConcurTaskTrees Environment
http://giove.isti.cnr.it/ctte.html
[8] Regulations on Accessibility in Germany
[8.1] BGG
http://bundesrecht.juris.de/bgg/BJNR146800002.html
[8.2] MBO (Template Building Law):
http://nullbarriere.de/files/pdf/gesetze/musterbauordnung.pdf
[8.3] ArbStttV:
http://bundesrecht.juris.de/bundesrecht/arbst_ttv_2004/gesamt.pdf
[8.4] ASR:
http://www.baua.de/cln_104/de/Themen-von-A-Z/Arbeitsstaetten/ASR/ASR.html
[8.5] DIN Norms:
http://www.beuth.de/
[8.6] Other resources:
http://nullbarriere.de/
http://barrierefrei.de/
http://www.barrierefrei-bauen.de/
[9] Regulations on Accessibility in Austria
[9.1] Barriere:Frei! Handbuch fr barrierefreies Wohnen. Bundesministerium

fr Arbeit, Soziales und Konsumentenschutz, Stubenring 1, 1010 Wien,

https://broschuerenservice.bmask.gv.at/PubAttachments/Handbuchbarrie
refreiwohnen.pdf
[9.2] Barrierefrei Bauen Wohnen, Arbeiten, Einkaufen, Unterwegs. Land

Salzburg, Abteilung Soziales, 5010 Salzburg, Mai 2008,
http://nullbarriere.de/download.php?datei=pdf/wissenswert/barrierefrei_bauen_s
alzburg.pdf
[9.3] Barrierefreies Bauen fr ALLE Menschen Planungsgrundlagen,

Stadtbaudirektion Graz, Referat Barrierefreies Bauen, Europaplatz 20, 8011
Graz, 2006, www.barrierefrei.graz.at
[9.4] Wohnen im Alter, IfS-Menschengerechtes Bauen, Institut fr

Sozialdienste, Vorarlberger Wirtschaftspark, 6840 Gtzis, 2009,
http://www.ifs.at
[9.5] Behindertengerechtes Bauen TILAK Standard, Tiroler

Landeskrankenanstalten GmbH, Anichstrae 35, A-6020
Innsbruck,http://www.tilak.at/media/data0777/tilak_standard___behindertengere
chtes_bauen.pdf
[9.6] Barrierefreies Bauen: Ausbildung und Beratung in sterreich. Design for

all and Bundesministerium fr Arbeit, Soziales und Konsumentenschutz
(BMASK), 2009/2010,
http://www.designforall.at/Downloads/BarrierefreiesBauen-Projektbericht.pdf
[9.7] Barrierefreies Bauen. TU Wien, Online (31.3.2011):

http://info.tuwien.ac.at/uniability/bauen.htm
[9.8] Anpassbarer Wohnbau - Informationsblatt, Magistrat Graz

Stadtbaudirektion, 2006,
http://www.graz.at/cms/dokumente/10027270_421952/77cbb790/Infoblatt_02_A
WB.pdf
[9.9] OiB Richtlinie 4 Nutzungssicherheit und Barrierefreiheit (OIB-300.4-

012/07), Sec. 8, sterreichisches Institut fr Bautechnik, 2007,
http://www.oib.or.at/RL4_250407.pdf
[9.10] NORM B 1600 Barrierefreies Bauen Planungsgrundlagen (Barrier-

free construction Design principles), Austrian Standards
Institute/sterreichisches Normungsinstitut (ON), Heinestrae 38, 1020 Wien,
1. April 2011, Preview Content:
https://www.astandis.at/shopV5/Preview.action?preview=&dokkey=387652
[10] Regulations on Accessibility in Italy
[10.1] Italian law 13/89

http://www.operepubbliche.regione.umbria.it/resources/BARRIERE_ARCHITET
TONICHE/Testo%20aggiornato%20della%20legge%209%20gennaio%201989
%20e%20circolare%20esplicativa.pdf

[10.2] Italian Implemental decree D.M.236/89

http://www.comune.oderzo.tv.it/ilcomune/uffici/gestione-del-territorio-e-
urbanistica/sportello-unico-edilizia-privata-e-attivita-produttive/contributo-
barriere-architettoniche/contributo-regionale-barriere-architettoniche-l-r-13-
89/DM%20236-89.pdf
[10.3] Italian law 104/92

http://www.alihandicap.org/download/L521992n104.pdf
[10.4] DPR 503/1996

http://www.logessystem.com/Normativapdf/D.P.R.%205031996.pdf
[10.5] DPR 380/2001 (Art. 77-81)

http://www.unisi.it/did/dip-direcon/DPR%20380-2001.pdf
[11] Regulations on Accessibility in Spain
[11.1] Arquitectura y poltica de vivienda (Accesibilidad), Ministerio de

Fomento, Gobiernode Espaa.
http://www.fomento.es/mfom/lang_castellano/direcciones_generales/arq_vivien
da/edificacion/accesibilidad/default.htm
[11.2] Ley 51/2003 de 2 de diciembre, de igualdad de oportunidades, no

discriminacin y accesibilidad universal de las personas con discapacidad.
Ministerio de Fomento, Gobierno de Espaa.
http://www.fomento.es/NR/rdonlyres/B35CD14C-D9DB-49E9-9F52-
D1BD36F080AA/95509/LIONDAU.pdf
[11.3] Gua tcnica de accesibilidad en la edificacin 2001. Ministerio de

Fomento, Gobierno de Espaa.
http://www.fomento.es/NR/rdonlyres/69241D0B-9D53-4CF4-9FAD-
107C7D755975/95510/Guiaaccesi.zip
[11.4] I Plan Nacional de Accesibilidad 2004-2012.

http://www.sidar.org/recur/direc/legis/ipna2004_2012.pdf
[11.5] Ley 51/2003 de Igualdad de oportunidades, no discriminacin y

accesibilidad universal de las personas con discapacidad.
http://www.boe.es/boe/dias/2003/12/03/pdfs/A43187-43195.pdf
[11.6] El Real Decreto 556/1989, de 19 de mayo, por el que se arbitran

medidas mnimas sobre accesibilidad en los edificios (BOE de 23 de mayo de
1.989),
http://www.discapnet.es/Castellano/areastematicas/derechos/legislacionsobredi
scapacidad/Buscador/Paginas/xlegis.asp?ci=010010
[11.7] La Ley 15/1995, de 30 de mayo, por la que se establecen lmites al

dominio sobre inmuebles para eliminar barreras arquitectnicas a las personas
con discapacidad.
http://www.discapnet.es/Castellano/areastematicas/derechos/legislacionsobredi
scapacidad/Buscador/Paginas/xlegis.asp?ci=000569

[12] Regulations on Accessibility in Greece
[12.1] General Building Regulation:

http://portal.tee.gr/portal/page/portal/teelar/NOMOTHESIA
[12.2] Law for Special arrangements to accommodate people with disabilities in

existing buildings:
http://www.elinyae.gr/el/lib_file_upload/b18_02.1129800988436.pdf
[12.3] Greek Health Regulation:

a. Law for health checks on licenses for the establishment and
operation of sanitary facilities operations, and general and special
conditions for establishing and running the workshops and stores
of food and / or drinks. (1/8577/1983).
b. Government Gazette (FEK) 528//8.9.1983.
[12.4] Ministry of environment, energy and climate change. Design Guidelines

for the Independent Living Movement and Disabled:
http://www.minenv.gr/1/16/162/16203/g1620300.html

Veritas D2.3.1

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Veritas D2.3.1

Uploaded by

Copyright:

Available Formats

Accessible and Assistive ICT

Generation of Simulation Models

Deliverable No. D2.3.1

Workpackage W2.3 Workpackage Smart Living Spaces

Activity No. A2.3.4 Activity Title Generation of simulation

Authors DOMOLOGIC, FhG/IAO, Bauunion, UoS, USTUTT

Dissemination Level PU (Public)

File Name: VERITAS_D2.3.1_Generation of simulation

Project start date and 01 January 2010, 48 Months

Version History table

0.2 15 November 2011, Second draft

0.3 07 December 2011, Third draft

0.4 12 January 2012, References added

0.5 17 February 2012, Including demo scenario ideas evolved during

0.6 22 February 2012; Included executive summary and general

0.7 28 February 2012; Harmonized the style templates, corrected

0.8 09 March 2012: Technical aspects moved to separate

1.0 15 March 2012: Accessibility issues

February 2012 3 DOMOLOGIC

February 2012 4 DOMOLOGIC

5.2.4 Exhaust hood ......................................................................................................... 71

February 2012 5 DOMOLOGIC

February 2012 6 DOMOLOGIC

February 2012 7 DOMOLOGIC

February 2012 8 DOMOLOGIC

1 Planning and Design Process in the Smart

1.1 A Generic Planning and Design Process

Figure 1: The basic UCD process

February 2012 9 DOMOLOGIC

, with some clarifications provided directly by the interviewed designers and

Usability evaluation (heuristic or user-based) takes place between

Using Computer-Aided Engineering (CAE) techniques during the

Using virtual analysis during Concept selection/validation step.

A real testing phase is mostly missing.

There is more than one iteration of the design-prototype-testing-redesign

1.2 The Architectural Design Process

February 2012 10 DOMOLOGIC

February 2012 11 DOMOLOGIC

Workplace regulations (Arbeitsstttenverordnung, ArbStttV)

Technical rules for workplaces (Technische Regeln fr Arbeitssttten,

DIN 18024-2: Publicly accessible buildings and workplaces

DIN 18025-1: Flats for wheelchair users

DIN 18025-2: Barrier-free apartments

February 2012 12 DOMOLOGIC

DIN 18040-1: Accessible buildings - Design Basics - Part 1: Publicly

DIN 18040-2: Accessible buildings - Design Basics - Part 2: Dwellings

DIN 77800: Quality requirements for providers of residential form of

February 2012 13 DOMOLOGIC

involving such services.

February 2012 14 DOMOLOGIC

sufficient, because a customer likes to have more separated control

February 2012 15 DOMOLOGIC

regulations for total Austria. The following areas have to be considered:

National law (antidiscrimination law, )

Federal state law (TBO, )

Compulsory and advisory critical levels

Standards (NORM, DIN, )

3.1.6.2 3.1.6.7 Parking-lots for passenger cars of disabled people

3.2.2.1 3.2.2.9 Entries and doors

3.2.3 Horizontal connection paths

3.2.4 Vertical connection paths apart from a link in NORM en 81-70

3.2.5.2 3.2.5.3.1 Sanitary rooms

3.2.5.4 Sanitary rooms