Computers say no.
Many of you will
have heard that.
And my bet is that if you
ever use the computer,
it will have said no
to you at some point.
It'll have presented
with a problem.
There is the dread blue screen.
There is the situation
when you're typing
and nothing is happening.
The screen is frozen.
And that's what I mean
by the computer says no.
It behaves in an unexpected
and an unhelpful way.
What about robots?
Can we trust that robots will
always behave as expected?
Can we trust that robots
will always say yes to us?
There is a lot of interest
in robotics in the media.
If you remember that the
autonomous vehicles are robots?
I think that's clear.
The UK government has identified
eight great technologies
that will have profound impact
on our economy in the future.
And robotics is one of them.
There are several
predictions for the size
of the robotics
market in the future.
And they are all of the order
of billions and billions
of pounds.
So what's going on?
Basically, at the moment,
robots are working normally
in factories, inside
cages, away from humans.
But there have been
extraordinary advances
in electronics, in mechanics,
and artificial intelligence.
And we are now
developing applications
where the robots are coming
to work near us, sometimes
in collaboration with
us-- with humans.
And robots can be very useful
in environments where humans
cannot be--
nuclear reactors, the
deep sea, the space.
But they can also be
very useful near us.
For example, a medical
robot can operate
with a precision that's not
possible for the human hand.
Robots have the possibility
of improving our environment
in offices, in
hospitals, in airports.
Robots have the possibility
of providing assistive care
for the elderly.
Robots have the
possibility of providing
education and entertainment
for our children.
But in all the situations where
the robots are working next
to us, there is a
concern about trust.
There is a concern about
safety, for example.
If a robot is strong enough to
help an elderly person to get
up from a chair, the
robot is strong enough
to hurt that person.
And we cannot have that.
So what can we do about this?
What is the position
that we are?
There are several issues
related to establish
the trustworthiness of a robot.
And what I'm going to
talk to you about today,
this is related to the software
that controls those robots.
A piece of software is
a engineering artefact,
just like a car or a
building or a laptop.
But as a society, we have a
very lax view of software.
If a bridge collapses, there is
a public outcry, most likely,
even legal action.
If I buy a laptop and--
I don't know-- the screens
cracked, I want my money back
or I want a new laptop.
But if the software
that's running that laptop
doesn't work, I'm
very happy to say,
ah, perhaps I need to
reset it, or perhaps there
will be an update.
And updates come
over and over again.
My whole career as a
researcher has been
about changing this situation.
Why cannot software engineers
provide the same sort
of guarantees that a civil
engineer can give, for example.
What's the problem?
Blame the tools
not the engineers.
Our software
engineering community
is extremely successful.
Our society depends on our
software infrastructure
very fundamentally these days.
I'm guessing that most of
you have a smartphone on you.
You are carrying a lot
of software on you.
If you'll go and
buy a pint of milk,
you are relying on a lot
of software infrastructure.
All the way from
the farm, farmers
are using automated machines
controlled by software
to milk the cows.
To the shop, when software
allows you to pay for milk,
allows the shopkeeper to
control their stock, interact
with the delivery system
that uses lots of lorries,
where a lot of
software is running.
If the software
infrastructure in our society
overnight stopped
working, society
would go to a
standstill very quickly.
And this reflects the brilliance
of our software engineers.
So what's the problem?
The problem is that
they need models.
They need to work with models--
mathematical models that
underpin that practice,
just like any engineer.
You cannot imagine-- it's
inconceivable to think that
a civil engineer is going to
start the project of a new
building by laying some bricks.
And laying bricks is
to civil engineering
like writing lines of code,
writing programs, developing,
actually, creating the software
is to software engineering.
That's not where we start.
So a civil engineer,
we know how they work.
They write some plans.
They build some markets.
And they use those to
discuss their design with
their stakeholders but
also to analyse and predict
the properties of their designs
to make sure that the building
is not going to collapse.
That it's going to provide
adequate services, water,
electricity, and so on.
And software engineers
can work like that.
The mathematical principles that
underlie software engineering
are already known.
In many areas of
application, they are used.
The techniques based on
these mathematical principles
are tackled.
Formal methods are
used very successfully.
And the trick is
specialisation, specialisation
for the domains of application.
And roboticists do not have that
specialised the techniques yet.
How the roboticists work?
Roboticists use extremely
advanced techniques
when it comes to the
development of the electronics
and mechanical aspects
of their artefacts.
When it comes to the
software engineering,
the practice is very outdated.
They basically start by writing
code, laying some bricks.
Many start writing simulation.
And you could say a
simulation is a model.
But it's not a
mathematical model
that allows you to reason
about your artefact.
It is code, right?
And so that's how they
start, not using models.
And in that situation,
they may face problems,
as you can expect if
civil engineers started
laying some bricks.
That's not how you do it.
And what do they then have?
The goal is the only
thing they have in hand.
They write it.
And they try it.
They try it in the robot--
lab conditions or in the
real world if possible,
it's not always possible.
They observe the behaviour.
If there is a problem, they
go back to the code change
and try again and
again and again.
In the end, what can they say?
What can they assert?
All they can say is that I
didn't find a situation where
a problem occurs.
They cannot say there is no
situation where the robot is
going to misbehave.
They cannot even say these are
all the situations in which
the robot will not misbehave.
And therefore, these are the
situations in which I can
guarantee the
behaviour of the robot.
They don't have that.
For that, they need models.
And what does a model for a
software engineer looks like?
It looks like a recipe.
A step by step
description of what
the software of what the
robot should be doing.
And now, with
discretion of recipes,
I'll run a parallel
with my mother's recipe.
I have to be very
careful about what I
say about my mother on record.
She has lovely recipes that
she kindly shares with me.
They are not precise.
They say things like cook
until it's a little brown
or put a pinch of salt.
And often, I have to call her
and ask, what do you mean?
Even worse, sometimes, I don't
realise that I have to call
her.
And here's what I get
instead of that lovely cake
that I wanted to do.
And roboticists have
the same problem.
Many try to write the
recipe for their robot.
Here's an example.
I don't need you to understand
the details of that diagram.
But that diagram is an
attempt of colleagues.
This is taken from a paper
in the area of robotics.
It is an attempt to
describe the recipe,
the step by step behaviour of
the software for the robot.
But it's not a model.
It's not precise.
It's not backed
up by mathematics.
We try to use that.
And we couldn't understand what
that diagram is presenting.
If a civil engineer
picks up a piece of paper
and sketch some plan of a
building, that's not a model.
That cannot be used by the civil
engineer to show or provide
evidence that their
building will be good.
It is just the drawing.
So my work and the work
of my research group
called Robostar is to
develop notations, tools,
and techniques that allow
a roboticist to write
their models in a precise way
and with strong mathematical
underpinnings.
So that's an example.
Again, I don't need you to
understand the details of that.
But it's an example
of a model that you
can write for a robotic
software using our annotations.
Because it's precise, it
can be backed up by a tool.
Because it has
mathematical underpinnings,
you can be sure
of the properties
that we can deduce from
the use of those models.
So we are developing
tools for these notations
that we are defining.
We are embarking on a
10 year program funded
by the UK Research
Council, the PSSC, and that
by the Royal Academy
of Engineering
to a value of more than 5
million pounds at the moment.
And our remit is to specialise
techniques, specialise
the mathematical
principles to allow
us to use software
engineering techniques
in the area of robotics.
So I have their video with a
demonstration of [INAUDIBLE]
as it exists now.
There are very challenging
and very exciting
issues that we need to
address in this robotic area.
A robotics software does not
run on a desktop or on a laptop.
It runs on a robotic platform
that influences and is
influenced by the environment.
And the environment is no longer
the environment of a factory,
is no longer the
environment that
is static and well organised.
There is a lot of uncertainty in
the environment of our streets,
of our hospitals, of our home.
And that uncertainty
makes the mathematics
that we need to reason
about this software using
this context extremely
challenging but extremely
exciting.
So we are, now, a
group at the moment,
moving to work and cater for
the mathematical foundations
to deal with the
robotic platform,
to deal with the environment.
And the two that's been
demonstrated there,
it can already cater
for the software.
So it can already,
in an automatic way,
directly form the models that
the roboticists write, develop,
provide automatically
reports like that
that's shown there for you.
Those reports, they are
showing that for properties
that have been
identified as important
for that particular
software, it is
showing that those
properties are valid.
And that's before
we even started
writing any line of code.
We know that those
properties will hold.
Sometimes, the report comes back
and says, no, they don't hold.
So again, before I
wrote any line of code,
I say, OK, there is a
problem in my design.
I need to revise
my design, which
is much cheaper than trying
to rewrite code, right?
And I get that
feedback automatically.
These techniques
can also provide you
with all the important artefacts
for software engineers.
It can automatically
give me the simulations.
It can automatically
give me the tests.
It can automatically give me
even a sketch for the code
that we would eventually use.
So this is the
future that we see.
As we evolve and we can cater
for more and more aspects
of the robotic system,
our expectation
is that roboticists
will be able to provide
consistent good outcomes.
They will get the recipes
right and get for us
good systems, good robotic
applications that we can trust.
They will never go back to
be writing lines of code
as the very first step.
And in that situation where
we can provide evidence
that we can trust the
systems that I've introduced,
we will then be comfortable to
have these robots around us,
helping our elderly
with day to day tasks,
perhaps, interacting
with our children,
helping others in the offices,
around the university,
in our homes, everywhere.
And in that context, the
robots will always say yes.
Thank you.
[APPLAUSE]
