Systems engineering and systems design might sound fascinating to someone interested in the area of technology and building, making, developing, and organising things.
But even to understand what the terms mean, from a beginner’s or outsider’s point of view, can be difficult.
And to summarise them probably wouldn’t explain things adequately because they really sound like a big jobs, involving a large number of tasks across many different disciplines and departments.
Needless to say, a systems engineer’s job, or a systems designer’s job, is fundamental and critical to an entire project, although, all we’ve learned so far is that a system engineer’s job is different from that of a system designer.
You could perhaps think of a systems engineer as an architect, and a systems designer as the builder. But rather than us try and dumb it down for ourselves, we talked to an actual system engineer and asked him what the difference is, and what they do.
In the exclusive interview, Gary Ewer, electromechanical system engineer and group leader at Cambridge Consultants, explains some of the basic concepts of the whole area, as well as some of the advanced aspects of his own job.
R&AN: Can you describe or define systems design in a sentence or two, as it relates to your job role or the work you do? Is there a difference between systems design and systems engineering?
Gary Ewer: The design of multiple modules in a system that, due to the size and complexity of the overall project, need to be developed by separate teams and integrated together.
This system design approach has additional benefits from the point of view of design modularity for the future (modules can be upgraded in the future without impacting other modules) and minimising the project risk.
System design considers the project requirements and how it will be broken into modules, interfaces and delivered to satisfy the requirements.
Systems engineering is about considering the complete system lifecycle – not just how it will be designed, but how it will be manufactured, tested, maintained, and upgraded.
R&AN: What are the jobs or types of work you are engaged in at the moment?
Gary Ewer: Personally I have worked on and lead on a number of large projects that have required state of the art systems design and engineering.
From a medical diagnostics machine to an industrial automation robot.
I am currently working on a medical drug delivery device which although physically is very small, still has five modules, all of which need to work together during integration.
The skills and approach for system engineering are similar, whatever the industry – medical, consumer, industrial and so on.
R&AN: What are you required to do? What are the applications you use to engineer, design or diagram a system?
Gary Ewer: For system design the first challenge is aligning the project with the business objectives and capturing the essential system requirements.
At a top level, the client might say, “We’re going to sell it in the US, then Japan, then Europe”, and we then have to translate this simple mission into a product roadmap and plan that can deliver.
At an engineering level, this means identifying the relevant standards and test regimes.
Above this though, we need an approach to modularisation that supports the need for operation in different geographies and these modules need to be a benefit and not a burden to the delivery of the project.
The tools used to do this are irrelevant.
You can use Microsoft Visio or Enterprise Architect for diagrams, Microsoft Word or Doors [Dynamic Object-Oriented Requirements System] for requirements – the outcome is the same and you just need to ensure the tools are the most suitable for the job in hand.
R&AN: Do you have a template of some sort to start with? What templates or resources are useful as a starting point for you?
Gary Ewer: We have many tools and templates at our disposal and have to choose the best ones for the project, whether it is for requirements capture, risk management, technical review, Fracas [failure reporting, analysis, and corrective action system], FMECA [failure mode, effects and criticality analysis], and so on.
Many of our tools are custom spreadsheets.
However, we also use Doors, Enterprise Architect and other industry standard packages, as long as they are appropriate for the project.
R&AN: What are the challenges for systems engineers now as things – or machines – become more complex?
Gary Ewer: Getting all stakeholders to understand the importance of interfaces between complex modules and getting their engagement in developing and adhering to them.
On one project we simply could not convince the client of the value of interfaces between modules until about two years later when the guy operating an injection moulding machine changed and suddenly their system was not working reliably.
If they had a robust interface in place, they would have been in a much better position to say what variation was acceptable from the supplier and when they were reaching the limits of reliable system operation.
R&AN: What are the future challenges and what is Cambridge Consultants doing to face them?
Gary Ewer: We are always innovating on our projects and developing our processes.
A couple of years ago, we launched our Product Development Process which captures best practice from the Cambridge Consultants centres of excellence and makes the knowledge and experience available for everyone in the company to make use of.
We are continually updating and improving this by reflecting and learning from what went well and what went not so well on projects.
It is also essential to bring skills and experience developed in one market area to another.
For example, we developed some clever motor control techniques during the development of an industrial robot which we have been able to apply to a medical drug delivery device.
The motors were at complete opposite ends of the power spectrum. However, the same basic principles still apply.
R&AN: How does internet of things and industrial internet of things affect systems engineering?
Gary Ewer: As systems become more distributed, security becomes a bigger concern. You can no longer rely on physical security to protect systems.
It is not just about using secure protocols and strong passwords – it is about having a big-picture view and considering the entire system – who will attack it, why will they attack it and how could they attack it.
Security is one of the big reasons why remote software upgrade has become a lot more important so issues can be identified and resolved before they can be used by attackers.
It is no longer acceptable to send someone to every site with a laptop and a cable, as that will take far too long and the damage could long since have been done.
