Opinions on key issues
We have recorded some of our opinions on the key issues that we encounter whether they are latest technology developments, technical or business processes and methods, organisational practices, skills development or particular technical challenges specific to an industry.
With this material we hope to assure you that these challenges are not unique and there are potential alternatives that might offer you, and your business, improvements.
Reflections, Insights and Opinions
In various moments, during various tasks, certain ideas come together. With a view to trying to capture those ideas we have written a number of informal papers, which we are happy to share with you. You can find some of them appearing below. You probably need to keep your sense of humour handy!
The 'Internet of Things' (IoT)
Is it just a fashion statement, a useful 'label' to get awareness of the underlying technologies, or just hype?
Although the term (and I can't say I feel comfortable with it, GE's 'Industrial Internet' seems slightly more appropriate) seems to be misused for practically everything to make it 'newsworthy' ... including things which have always been problems, and not specific to IoT... it does at least bring some focus (and with it hopefully some funding) to help us engineers to start to think about the potentially stultifying complexity that this hugely interconnected world could imply.
I prefer to think about the potential complexity from a series of angles, that includes the embedded components (for whom power, connectivity and communication, security and autonomous behaviour are but the start) as well as the potential service offerings that might come from being able to consume the vast quantity of (diverse, asynchronous, difficult to validate) data that comes from all this sensing.. and then analyse that to extract some meaningful value (i.e. that I would be willing to pay for!).. and further potentially ask me to risk some aspect of 'control' of my life to.... (and I don't mean the banal examples of my refrigerator re-ordering its contents!)
W' would like to see if we can help connect all the like-minded players in this (electronic , sensing, mechatronic) industry to collaborate. Why?
The UK has a highly innovative history... we deserve a revival of fortunes... and if that is to be as both 'design and manufacture' it is not going to be in traditional mechanical (metal bending) industries.. so why shouldn't it be around electronic systems? The market is huge, our appetite (as both engineers and public consumers) is huge and there doesn't appear to be a technology that is going to displace it anytime soon! IoT offers a useful 'brand' under which to do this.
This needs joining up from an education (of next generation engineers, and of the public) perspective as well as technology and potential business opportunities... so expect to see some output from me as I try to 'extract' and 'abstract' various themes, technically and politically.
So, as a starter for ten (and I encourage my readers to let me know what else I am missing), I have put together a simple mind-map as a personal brain-storm of some of the topics. IoT Issues brainstorm Mind-map.
Should you Collaborate?
What are the keys that identify when you should look for collaborative assistance? Who should you go to and why? What are the benefits? Non-competitors, Competitors and Academia all have intersts in collaborating. Know where you are and what you want - Industrial Collaboration
Skills on target for your system design, development and delivery? - Bulls-Eye
Where to spend those precious Engineering Resources?
Use a commercial off the shelf (COTS) product? Rework an existing legacy product? Contract a 3rd party to develop a bespoke component for you?... How do you know what the in-house team should be expending its efforts on? Where should you spend effort contractually securing Intellectual Property? This paper talks about a technique of enumerating and visualising these issues so that you can make informed decisions (or let the boss make them!) - Make or Buy
New to Acquiring Software?
Whether bought-in, subcontracted development, or some other mechanism of acquisition, these questions should help your thinking - Software Acquisition
Software Capability aligned with Business Needs?
How do you know? What should you measure? If you have diverse markets or industries, should it always be the same answer? Are skilled people more important than the process? How does the geographic dispersion of a development affect costs? What do my businesses think their market needs from software? What do the business think the cost model of software is in the product e.g. Fire and forget? Where should you develop - Your own development team, or in the supply chain?
All this, and more, can be readily measured, benchmarked and cost modelled. We have a comprehensive paper, but If you want to know more then you'll have to drop us a line. See the Contact Us details.
Software for Dummies!
Well almost... We make an attempt at describing some of the facets of a software engineering world by analog to some other worlds, mostly to the types of skills that fill your business seniors positions. We try to speak these foreign languages. If you can think of others you want an example from, let us know.
Does Software wear out?
I must admit, I wrote this after a senior mechanical engineer explained to a customer that his embedded controller and software would have to be returned for repair on a periodic basis and thereafter MTTF would be restored... My reality was that 'bad repairs' could actually cause the product architecture to be compromised (worsening the perceived MTTF)... and that patches were like "rust" that accumulated until the point the integrity was compromised - Software Wearout
Software Architecture Standardisation?
"Software" as a label has many different scopes associated, dependent on industry and who you are talking to! From "programming" to a ubiquitous description of the entire functionality provided across many separate control system nodes. Ignoring the scope problem, Software Standardisation initiatives fail to address the systems engineering issues - SW Architecture
Setting up a new Software Team? Trying to get some ideas on what your objectives need to be to match to your business needs? This list may not be ideal.. but it might give you a starting point - SW Objectives
Predictable Software Systems
As the technology we host our software on gets less deterministic in pursuit of execution throughput, how do we analyse, verify and evidence that we can make better use of modern processing infrastructure for predictable real-time? - Sufficiently Predictable?
P.S. If you have the answers I'd really like to hear them!
Safety Critical Software Intensive Systems
I once had to explain what the ramifications of Safety Critical Systems from a software-based system context meant, to a group of senior engineers who had been involved with diverse mechanical systems that were safety-critical products or systems. This was the set of topics I used to drive the discussion. - Software Safety Critical Systems
Supporting Predictive and Condition-based Maintenance
Electronic and Software systems make really good platforms for sensing (and then processing and identifying) what's going/gone wrong in the attached (mechanical/electrical) parts. What could you and should you do in support of Predictive and Condition-based Maintenance - The Art of the Possible: Extracting Business value by Predictive and Condition-based Maintenance
P.S. It's not a silver bullet!
What are the keys that your Defence industry wants from you. Obviously they have a different outlook to the civilian customer, but have you stopped to consider what that means. A simple alphabetical list of some of the key attributes that might get traction - Defence Software Systems
Concerned that your business is different?
Worried that our experiences don't apply?
Convinced that your experts have to be domain experts (in your customer's domain) as well as skilled in Systems Engineering, Software Engineering or even Electronics disciplines?
These are the most frequent stories we hear!... and although there is some truth in needing to have individuals who can bridge the customer's domain to your system design, does it really need to be deep-seated in your entire workforce?
We have a "Bulls-eye" diagram that might help you understand what skills you need.
See it in our Insights link to your left.
An attempt at helping non-software systems personnel get a glimpse of some of the issues... hopefully in terms with which they are more familiar!
Within the scope of Electronic systems - usually for systems of control (including embedded real-time, or process control) and with that we include the typical sensing systems or electronic drives to electromechanical actuation - we can help you.
Practical experience of transforming a customer's vision, into a realisable control system, from functional analysis to electronic and software partitioning.