There has been a recent article on The Conversation about the world’s first ethical guidelines for driverless cars.

It is good to see that people are trying to influence how this new world is going to look and this is being seriously considered by legislative bodies. The description in the article triggers some important questions which I’m sure the autonomy community are thinking of, but I suspect it may take some crashes and some court cases before we really understand what is acceptable.

Based on the article there is an important issue around the transition period, before the technology is mature enough for full autonomy, and who is in control. The suggestion that the system could hand back control in morally ambiguous dilemma situations immediately begs the question of how long would be left between the hand-over of control to the human driver and expected incident. As autonomy takes over more of the function of driving we can expect the human occupant to become de-skilled. So we may effectively have a low skilled operator being asked to react in a short time period to a challenging situation. Scientific American has already published an article on this: What NASA could teach Tesla about autopilot’s limits.

The article also notes that the car will have a “Black Box” style recorder so that it is clear who was in control of the vehicle at the time of a collision. To the suspicious minded this suggests that manufacturers could try and pass the blame for accidents to the nominal human driver when their autonomy system can no longer arrive at an unambiguous and ‘safe’ answer. For courts to be able to rule on such cases I expect that the reasonable level of anticipated skill of the driver and the time required between handover of control to avoid any incident will need to established.

However, it is good to see that in the guidelines themselves it is clear that ‘abrupt handover of control to the driver (“emergency”) is virtually obviated” but this requires the software and technology to be appropriately designed. I expect there is much work still to do to characterise the capabilities of the technology in a sufficiently wide range of real world scenarios to reach this aspiration. It is also good to see that the onus is on developers to adapt their system to human capabilities rather than expecting humans to enhance their capabilities. From the discussion above it seems clear that this must take into account the potential de-skilled human driver rather than an assumption on skill levels being maintained at the level of today’s drivers. Finally it seems that guidelines are also anticipating that in such an emergency situation the system should adopt a “safe condition” but acknowledges that the definition of this has not been established.

We could look to the aviation sector and note that most commercial aircraft have utilised autopilot for some decades with an improving safety record. But we must also remember that pilots typically spend many hours in a simulator with the opportunity to be taken through a variety of incident scenarios to enhance their skills. For our driverless cars how are we going to maintain the human skill level such that they can react in a reasoned and safe way?

For those who enjoy grappling with such ethical dilemmas in this age of technology, and indeed those who will be responsible for implementing such systems, I can recommend going back to read the likes of Asimov’s robot series (“I, Robot” and “The Rest of the Robots”) to understand however hard we try to foresee and control this new world there is always ambiguity to catch us out.

I recently read an article on the Nesta blog “Fall in love with the solution, not the problem” which is a phrase to immediately get a system engineer’s interest.

I’ll immediately say that I’ve not worked in the development sector and so I’m not going to comment on the efficacy of the proposed approach in that context, but it did get me thinking (particularly the diagram ‘3 possible strategies for problem solving‘) about lifecycle models in general.

The first strategy, a problem focused approach, is what some might say Systems Engineering espouses. The traditional lifecycle model of choice in the SE world is the Vee model.  If you simply assume that the left hand side of the Vee is a linear process then it would indeed look like you spend a lot of time fully exploring the problem and then move on to creating a solution to solve the defined problem.

But the Vee model is just a model, and like all models it is an abstraction of reality. It is useful in providing some scaffolding around which systems engineers can communicate, but competent engineers will recognise that there are many subtle nuances that come to play in the real world. They will also recognise that this is not the only lifecycle model and will be able to blend lifecycle thinking and mix elements of different approaches as appropriate (e.g. based on development risk).

These models can also be useful education tools in that you have to get people on the first rung of the ladder of understanding before showing them the possible complexity in application. (If you want to read another author’s views on the Vee model then try The Design of Design by Frederick P. Brooks Jr. It should certainly get you thinking even if you don’t agree with all he says.)

If we consider the process of architecting within this stage of the lifecycle then authors such as Maier & Rechtin (The art of systems architecting.  CRC Press 2009) show a process model that includes parallel activities of problem structuring and solution structuring. And if we consider an approach such as the Seven Samurai of Systems Engineering (Proceedings of the International Council on Systems Engineering (INCOSE) International Symposium, 2004) then we recognise that not only do we have to consider the ‘solution’ (system of interest) but how that solution is created, how it is supported and maintained, and how the solution will change the context into which it is deployed (which might create new problems to be solved).

This implies fully immersing yourself in the context where the problem/solution exists, and engaging with the wide range of stakeholders that are, or will be, concerned with the solution once deployed. A design on the bench is not the same as a design in the environment where it is meant to operate. It also means understanding what already exists and the benefits and challenges of those existing solutions.

When I think about it in these terms, then what I understand as good systems engineering starts to look more like the co-evolution approach (at least in the pictorial form) from the Nesta article.

As always, these thoughts are my own and thoughts can change with time and additional input. So please feel free to comment and add your own perspective.

Following my PGCert in Teaching and Learning in Higher and Professional Education I’ve taken to thinking more about the profession that I have joined. I like finding metaphors and analogies to understand the world around me and that I occupy, and this time I thought about an analogy between curators and teachers.

This article is based on my incomplete knowledge of at least one of these roles, and I hope others will contribute their thoughts.

A curator is an expert in their subject field and also in the art of curating. They have a passion for the subject and wish to promote that through displaying the artefacts using their skills to make them engaging, interesting and relevant.

No one museum will have all of the artefacts related to their subject field, and within an exhibition they can only display a subset of what they do have.

If an attendee wishes to know more than is on display, or if the question exceeds the curator’s own knowledge, then they will know how to help the enquirer discover what they are looking for.

And I see parallels with teaching on an MSc level programme.

Within a lecture we have a limited window in which to display the ‘artefacts’ of the topic at hand. We are the curators of the knowledge of our field and we must use our teaching and learning skills to convey these to the students in an interesting and engaging way.

No one lecturer can hold all the knowledge but they should know the core structure of the knowledge and have the skills to research areas they don’t yet understand.

We were recently invited to participate in a bid to provide consultancy to an organisation. They are looking for the work of consultants hoping to gain a step change in their own capabilities when confronted with their very difficult business challenges.

This call for proposals made me think, what are the necessary conditions for external consultants to be effective in their contribution to the management of an organisation and how do we understand their input in terms of the systemicity of the organisation?

Sometimes consultants are brought into organisations when they are faced with very difficult problems and feel surpassed by the situation or somehow unable to resolve it. I wonder if the idea of solving some difficult problems through consultants can be seen, under certain circumstances, as a ‘disturbance’ that shakes the organisation into new areas that take them to find better answers. I would argue this is a problem that can be partly understood as an optimisation problem when you are searching for the most appropriate variables and their most appropriate combination to find the optimum of a function. Here the problem is the most appropriate way to deliver a complex project  (for example) and the variables are the exact number and identity of the resources (with their capability) involved. The function to be optimised is the business performance metrics. Of course, the situation arises not only when we get to the point of bringing in consultants, sometimes organisations face difficult problems and embark on solving them themselves. But the question is still relevant, if the organisation is a system, is the consultant (or the ‘hero’ within the organisation) anti-systemic? are they part of the system even if their participation is sporadic and is not in keeping with the internal dynamics? Or are they perhaps just bringing to light dynamics (or parts) of the system that had not been identified? Finally, is there anything we can learn from the field of optimisation in maths and search algorithms (in numerical computing) that we can transfer to the management and design of complex systems, including organisations?

It will be nigh on impossible to transfer directly an organisational problem to a numerical optimisation problem because many of the variables at play are non-quantifiable, being of a human nature. Nevertheless I reckon making the analogy with numerical optimisation gives you a very good chance of understanding the underlying and overarching dynamics of the organisation.

Just systems thinking…

The term ‘system’ crops up all over the place. But what does it mean?

I like to think of it as a way of looking at something – a lens you can choose to look through when you are thinking about an object or a process in a particular way.

A bicycle is the same collection of metal parts (usually with a few bits of plastic, and if you are really lucky, carbon fibre) whether you call it a bike or a personal transportation system. But when we choose to use the term system, it implies that it’s no longer just a homogeneous object that is the same throughout; it’s an object made up of multiple parts that are connected in a way that means that the whole thing has emergent properties or behaviour that are not exhibited by the parts in isolation. For the bicycle, the parts of wheels, frame, handlebars, brakes, pedals, etc. have little value in isolation. But when put together according to a particular design, my bicycle ‘system’ has the emergent property of enabling me to propel myself in an incredibly efficient way.

In making the choice of how we see the system, we also need to specify a system boundary, which defines the scope of the system. This may seem trivial, but it’s particularly important to make sure we are clear about which parts we will develop or optimise, and what we are assuming about external interfaces. An interface challenge for the Airbus A380 ‘superjumbo’ aircraft is that it is simply too big to be accommodated in most airports.

There is no rule to say whether something is a system or not – it depends on your point of view at the time. When I’m talking to my kids about how they are going to get to school – scooter or bike – I don’t think in terms of systems. But when I am thinking about how to repair the bike or make it work better, the system lens becomes useful.

At UCL Centre for Systems Engineering, we apply systems thinking to understand how to improve the design of spacecraft instrumentation, asking questions like ‘what are the difficult interfaces’, ‘how much can we compromise on detector resolution to save a bit of mass’ and ‘how might the system fail’? But it’s not just technology that benefits from systems thinking – we also apply the systems view to soft systems in which people and processes are the major focus of attention. For example, we have recently been undertaking a study with a local hospital to understand the tensions between keeping frail elderly patients in the hospital and seeking an early discharge with support in the community.

Next time you use the term ‘system’, challenge yourself: what is happening inside the system? What are the component parts (or subsystems)? Where are the tricky interfaces? How does it change over time? What higher level ‘systems’ does it work within? When you start to think in these terms, you really are ‘systems thinking’.

Our MSc in Systems Engineering Management has been running for nearly 15 years with great success.  Throughout this time the course has evolved to meet the requirements of our students for a course that incorporates up to date material and is relevant to their careers.

One piece of feedback from current students, which we have recently acted on, was that if the course were accredited by the IET (Institution of Engineering and Technology) then it would help them achieve CEng registration.  In addition, some potential students have told us that they would be more likely to enrol if the course were accredited.

So over a year ago we embarked on a project to seek accreditation for the course.  It has been hard work, especially through the summer when we had to prepare all the evidence required and submit it to the IET.  Also, during this process we identified ways we could improve the course, which we have now implemented.

In November 2013, after reviewing our submission, a panel from the IET visited us to meet our staff and students and ask us lots of questions.  The panel “found it to be an excellent programme highly valued by the students, some of whom had senior positions in industry and found the material very relevant and useful” and “the programme is also highly valued by industry”.

We had a small number of requirements that needed to be addressed, which we responded to in an action plan, before we were told that our application had been successful.

As a course team, we are delighted to have achieved IET accreditation, as we hope will be the many past, present and future students who will benefit.

The Somerset levels are experiencing the worst flooding that residents can remember, and this event is gathering a lot of press coverage.

Clearly we are dealing with a ‘water system’ here with the input of the prolonged and heavy rainfall, the elements of the fields, drainage system and rivers and the outcome of the water level. It is good to see that the news coverage recognises that there is no simple solution to this and have elicited views from a range of stakeholders.

This has highlighted that calling for the obvious fix of dredging the rivers actually would not solve the system problem of preventing the flooding. Put simply the capacity of the rivers is not sufficient, even if dredged to increase capacity by 50%, to carry away the volume of water on the land fast enough to prevent flooding if the recent rainfall is repeated.

The RSPB, for example, are promoting the need to look at a range of measures which suggests a level of systems thinking to the problem. These include holding water in upstream catchment areas and releasing it slowly, allowing flood plains to do what they say, i.e. flood, and designing town rainwater drainage systems to delay rainfall being released.

This situation also highlights the human issue when confronted by a crisis. Human nature demonstrated in these circumstances seems to demand instant answers, someone to blame, and a quick fix. In the face of this pressure it is hard to maintain an unbiased and long term view of what needs to be done. But this is the challenge that systems thinkers must stand up to.

It is only by taking this systems view, and recognising that our man-made systems such as towns, farms and transport systems have to work within the bigger natural system, that we will reach sustainable solutions to these issues.

This blog is owned by the UCL Centre for Systems Engineering (www.ucl.ac.uk/syseng). UCLse is a centre of excellence for Systems Engineering and the Management of Technology Projects. We balance the practical application of systems engineering in research and development projects with investigations into how to advance the practice.

This blog will contain posts from our staff on matters of interest to the world of systems engineering and technology management. We’re likely to cover thought pieces, basic principles and understanding, commentary on events in the world around us and matters related to education.

We are also active on twitter , LinkedIn and Facebook