Interfaces For Human-Robot Interaction - Project Guidelines: 1. Formulating The Problem
Interfaces For Human-Robot Interaction - Project Guidelines: 1. Formulating The Problem
Interfaces For Human-Robot Interaction - Project Guidelines: 1. Formulating The Problem
Contents
1. Formulating the problem................................................................................................................................1
2. Structuring requirements............................................................................................................................... 2
3. Exploring variants........................................................................................................................................... 5
4. Planning technical performance.....................................................................................................................7
5. Planning functions and hardware components.............................................................................................12
6. Supervisory and control functions.................................................................................................................15
7. Usecases....................................................................................................................................................... 17
8. Wireframing................................................................................................................................................. 20
2. Structuring requirements
Before starting the robotised line design process, the analysis team has to make several judgements and to
take specific decisions regarding the key requirements related to the given application. Who’s interested in
the system we’re developing (i.e. which are our stakeholders)? Note that it’s not just the users of the future
system (operators or maintenance engineers), but all those at the business or enterprise operations level:
users, integrators, customers, and any other (type of) persons or organizations that relate to the problem.
Each of these stakeholders may have his or her own requirements, which should be captured by the
analysis team.
Some requirements or needs may be directly expressed, but some not. A stakeholder may not formalise
(or even understand) his complete needs – for instance, the customer may not consider quick installation as
a requirement, but – at some time – he might move to a new facility and want to quickly reinstall all his
systems. The analysis team should, however, “guess” this requirement and document it accordingly.
To extract requirements (and – later – define performance characteristics), the analysis team can also
check against specific design guidelines to be found under the label Design for X (Design for Excellence) [1]
[2]. Each design guideline addresses a given issue that is caused by, or affects the traits of, a product. These
design guidelines cover all the product life cycle phases (development phase, production phase, use phase,
and disposal phase). Examples of such design guidelines: design for short time to market, design for
reliability, design for test, design for safety, design for quality, design against damage, design for minimum
risk, design to cost, design to standards, design for assembly, design for manufacturability, design for
logistics, design for low-quantity production, design for user-friendliness, design for aesthetics, design for
serviceability, design for maintainability, design for recycling.
Example list of requirements (students can use these as a starting point for their own requirement list):
• reliable
• small footprint
• easy access to hardware components
• reduced energy consumption
• low cost per produced unit
• friendly user interface
• easy to be transported and installed
• increased productivity
• increased safety level
• low scrap rate
• easy supply process (with extender parts)
• high percent of reusable hardware components
• reduced maintenance time
• reduced maintenance costs
• easy to be monitored
Once requirements are identified, the next important step is to rank them, to determine their importance
level so that the design process can be oriented towards producing a robotised cell to fulfil these
requirements. A systematic method like AHP – Analytic Hierarchy Process – should be used for
requirement ranking.
Within this document, the AHP is exemplified by using the Qualica QFD software tool. The screenshots are
made with Qualica2005. The instructions are adapted to the same software tool. One can use any other
software tool, as the steps to follow should be similar.
After starting Qualica, create a new project and choose the template “Tree Diagram with AHP” (see Figure
1).
buttons to add new requirements or to reorder the already introduced ones. Then
click “Toplevel comparison matrix”. If the displayed matrix is “empty”, right-click in the “Input ...” area,
choose “Replace tree” (see Figure 3), and select ITEMS.
3. Exploring variants
Usually, at the beginning of the design process, several possible solutions may seem appealing. One can
explore various layouts for the cell, do assembly with one or two robots, do a pre-sorting of parts before
assembly or sort them afterwards, implement quality inspection in several ways, etc. A good practice is to
sketch three possible technical solutions (variants) for the problem we’re considering (i.e. designing a
robotised cell to assembly, pack and palletize a product) so that the requirements above are fulfilled as
good as possible. Variants should not be too detailed in this step, but rather serve as a base to be further
developed. Advantages and disadvantages should be provided for each variant.
The variants will then be checked against the requirements. The one that best fulfils them will be further
considered in the design process, i.e. the solution will be built upon the variant that best fulfils the
requirements.
A way to assess (rank) the variants is the Pugh method, also implemented in the Qualica QFD software.
Select some item in the workbook tree (the upper left part of the Qualica window) and choose New – Pugh
New Concept Selection. For New Concepts choose Leave Unchanged, while for Criteria choose Link to
existing tree and select ITEMS (i.e. the requirements you have just ranked with the AHP method) – Figure 7,
a. Specify a name for the new workbook, for instance “variant selection”. The new workbook will be
displayed in the workbook tree – Figure 7, b.
Figure 7. Qualica QFD: (a) Linking the ITEMS tree; (b) the updated project tree.
To enter the three variants, choose New Concepts in the workbook tree. Type the solutions in the
corresponding table. Select then New Concept Selection and complete each matrix cell by identifying the
relation between the selected variant and the selected requirement (i.e. how much does the selected
variant fulfil the selected requirement) – see Figure 8.
Metric (performance characteristics) set example for a robotized system to assemble, check, pack and
palletize electric extenders (students can use these as a starting point for their own performance
characteristics list):
[reliability] unintended downtime (due to undetected errors) within 1 month hours ↓
[reliability] no. of process parameters for which historic data is stored - ↑
[testability] no. of built-in self-tests (for remote diagnosing) - ↑
[reliability] mean time between failures days ↑
[reliability] time to signal a self-detected error min ↓
[reliability] percent of correct resumes after a failure % ↑
[safety] unauthorized access incidents within 1 month (how many times unauthorized - ↓
personnel entered the production line area)
[safety] security incidents within 1 month in the production line area - ↓
[safety] security incidents within 1 month in the proximity of the production line area - ↓
(1m along the fences)
[quality] goods count / hour - ↑
[quality] percentage of defective goods count out of the actual production count % ↓
(rejection ratio)
[quality] overall equipment effectiveness (multiplies availability by performance and - ↑
quality to determine resource utilization) - shows the overall performance of the
factory
[quality] capacity utilization % ↑
[flexibility] time to make changeovers min ↓
[flexibility] number of products that can be produced on the line - ↑
[low cost] total manufacturing cost per unit excluding materials EUR ↓
[low cost] energy consumption per unit kWh ↓
[low cost] footprint m2 ↓
[assembly] line installation time (at a customer's facilities) hour ↓
[assembly] number of hardware components - ↓
[assembly] number of electrical and pneumatic connections to be made - ↓
[usability] training hours for a newbie operator hours ↓
[maintainability] planned maintenance foreseen time within 1 month hours ↓
...
Step 6 implies identification of the improvement direction for each metric – what means improving it’s
value?
Step 7 requires the completion of the relationship matrix. The analysts team determines the relationship
between customer needs and the company's ability to meet those needs (via the metrics or technical
descriptors). Each matrix cell should reflect the answer to this question: What is the strength of the
relationship between the technical descriptors and the customers needs? Relationships can either be none,
weak, moderate, or strong and carry, for example, a numeric value of 1, 3 or 9. Different scales may be
used as well. Not all requirements are related to a metric and not all metrics are related to a requirement
(several “none” values will exist in the relationship matrix). In other words, the relationship matrix will not
be “fully completed”. An example is shown in Figure 13.
Figure 13. The (draft) flowchart diagram for the entire process.
Figure 14. A detail of the flowchart diagram - the assembly sub-process.
In Figure 14, [w] is a shortcut to a connecting point to the supervision and monitoring functions. It's used
for outputs of type data which are inputs for software functions which handle process parameters. The [d]
shortcut means decisions (usually 0 or 1) automatically taken by the system (e.g. call a specific function).
Hardware components (and software modules and interfaces) should then be selected and integrated in
the robotized line. We should then check that all functions can be adequately performed with the
hardware components we selected. We can use the graphical support of the QFD method for this – by
placing functions on the lines (the inputs) and hardware modules on the columns (the outputs). When
building the relationship matrix, we should have at least one strong relation on each row and each column.
The flowchart diagram (modeled with IDEF0 blocks) can be extremely helpful - each IDEF0 block has to
document also the mechanism for implementing the function (e.g. for the "assembly the electric extender"
function the mechanism may consist of a robot + gripper and an indexing table). By centralizing all the
mechanisms of the IDEF0 blocks we should get a fair hardware list (and software blocks) for our robotized
line.
For our automated line we'll consider the following HMI hardware: mobile phone (for the operators and
maintainers), operator panel (also for the operators), standard computer (for the supervisors), and ANDON
system (for the general line status visibility).
Use the following function list as a starting point and identify all the functions that should be developed
in your case. Consider also the target values for the performance characteristics that you established
in section 4 (check the notes below).
On mobile devices (e.g. smartphones):
• authentication [login/out],
• line start / stop [stop / stop after finishing current pallet / restart / emergency stop]
• display statistics [functioning state display, logged user, start time + uptime, number of extenders
assembled, number or percent of scrap, productivity figures like extenders / hour, boxes / hour,
pallets / shift, number of incidents, part stock (for each part), energy consumed, etc.]
• warnings [if an error occurred, if the cardboard stack is near to empty, if parts run out soon, if a
pallet is loaded, if pallets should be supplied etc.]
On the operator panel:
• authentication [login/out],
• line start / stop [stop / stop after finishing current pallet / restart / emergency stop]
• display statistics [functioning state display, logged user, start time + uptime, number of extenders
assembled, number or percent of scrap, productivity figures like extenders / hour, boxes / hour,
pallets / shift, number of incidents, part stock (for each part), energy consumed, etc.]
• settings [type-of-product if you opted for a flexible solution]
• self-tests [using a "maintenance mode"]
• logs [assembly, quality check, packing, palletizing]
On the ANDON system:
• stats [functioning state display - these will be actually the three lamps: green, yellow, and red]
On the supervisory center computer:
• planned maintenance operations (and due date)
• provide help on maintenance operations
• warnings on due maintenance operations
• maintenance log (what was done / by whom)
On the manual quality area interface:
• show reference extender specifications and images
• take picture of non-compliant product(s)
• enter compliant/non-compliant flag and additional text
• line start / stop [stop / stop after finishing current pallet / emergency stop]
7. Usecases
As discussed in the course on interfaces, from the user perspective, a product is it's interface. The interface
is the space where interactions between the user and system occurs, therefore each function in the
process flow diagram that implies user interaction will need an interface. The application we're now
designing will aggregate the interface from all these functions.
A usecase is a list of actions or event steps typically defining the interactions between a role and a system
to achieve a goal (i.e. perform a function). The actor playing the role can be a human or other external
system. A usecase captures some user visible function. Functions may be a large or small; it depends on
the level of detail in your modeling effort. A usecase achieves a discrete goal for the user, like format a
document or request an elevator. Actors are external entities that interact with the system. It can be a
person (a person category), another system or an organization. The actor list, in our case, consists of
operator, maintainer, technical supervisor, and quality inspector, as already discussed in Section 6 above.
A person using the system (a user) may have one or more roles. For instance, user Cristiano can be both
operator and quality inspector. User Sergio could be both maintainer and technical supervisor, while user
Roberto may be only maintainer.
Build the usecase diagram corresponding to our project. Follow the example in Figure X below.
Figure 15. An example usecase diagram.
For each usecase a description table should be produced. Choose 5 usecases (any you like) and develop
their corresponding description table. See the course on usecases for details. An example of how you
should structure the description table can be found below. See also an example in Figure 16.
Usecase name show robotized line status (and production indicators)
Scenario stay informed on how the line operates
What triggers this usecase user authentication
Brief description list here the production indicators to be displayed, any of them that should
be highlighted etc.
Actor (who is performing operator, maintainer, supervisor
this?)
Related usecases login, logout, view logs, view warnings, etc.
Stakeholders customer, business owners, technical department
Pre-conditions user should be authenticated
Post-conditions -
Flow of activities Actor System
Exception conditions • if on mobile device and network not available, warn that displayed
information may be outdated
• (identify also other possible exceptions)
Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.
Alternative Proxies: