|

5 forecasts for systems engineering in 2018

http://trish2.deviantart.com/art/Crystal-Ball-1-48409990

Predictions are difficult, especially when they concern the future. Even if it is unclear whether this quote comes from Karl Valentin, Mark Twain or Winston Churchill, it is undoubtedly true. But predictions are fun. Already Two years ago, I drew up a listand now it's time for a new one.

1. Agility includes hardware

Agility has long since proven itself in software development and requirements engineering. But what is relatively new is that the creation of finished products is also part of agile cycles. I already wrote about this topic in my Report on WikiSpeed a company that develops, builds and sells cars on a weekly basis.

The new thing here is that not only prototypes are developed, but also saleable products. After all, iterative development with prototypes has been around for some time. Of course, many organizations will stick with prototypes. But these will become more and more similar to the final product.

The efficient development of agile hardware requires technologies that have only stabilized in recent years. These include 3D printers and generic programmable control units, as well as cost-effective actuators and sensors.

2. Artificial intelligence in products and development

Artificial intelligence (AI) is one of the current buzzwords that is hard to escape at the moment. This is partly due to the fact that AI is increasingly being used in consumer products, but we will also see more AI in development.

Specifically, there are already approaches using AI to automatically create, maintain and analyze the traceability of development artefacts. AI can help to identify "hot spots", i.e. potential problem areas with a lot of change. I assume that we will see many exciting developments in this area over the next few years.

3. Modeling and MBSE continue to gain ground

Also about Modeling much has already been written here. It's not really a new topic, but there are two developments that will speed up enforcement here:

On the one hand, products are becoming increasingly complex, and modeling is one approach we can use to get a grip on modeling. The cost-benefit ratio of modeling is only positive once a certain level of complexity has been reached, whereas the cost of traditional development methods increases disproportionately with complexity. However, many products have now reached a level of complexity that makes MBSE attractive. Many large corporations, such as Airbus, Ericsson, Daimler and Audio, have now made public statements on MBSE.

Secondly, the modeling tools and methods have now become suitable for practical use. For a long time, serious (formal) modeling was only used in research and niches such as aerospace or railroad engineering. The vision of MBSE is in a video produced by Willert on the use of IBM tools to see. Of course, it's not as easy in practice as it looks in the video. But the clip shows impressively where the journey is heading. The Acquisition of NoMagic is a sign that the trend is moving towards modeling the aspects of SE across the board.

4. The shortage of skilled workers and inadequate training are worsening.

Training systems engineers is still a problem. There are some study programs on SE, as well as the INCOSE certificate. However, these do not help to incorporate awareness of SE into all areas of development. This problem has Paul Schreinemakers well to the point.

A lack of training opportunities combined with high demands on new products results in a shortage of skilled workers. Even if there are prophecies of doom in some areas regarding the so-called shortage of skilled workers, this is real in the SE.

5. Security is slowly becoming an integral part of the architecture.

Security, in the sense of security, will become even more stringent. Of course, this has something to do with the fact that more and more devices are being networked. A hacked coffee machine that sends spam or mines bitcoins is merely annoying. But a Car taken over by hackersrepresents a completely different risk.

In contrast to functional security, the risks, i.e. the security gaps, are not known in the case of security. And security is often only addressed as an afterthought during development, instead of seeing security as an integral part of the architecture. This will change - but certainly not in just one year. This process will take many years and be painful.

What do you think?

These are my predictions. What is your opinion? Join the discussion in the comments!

 

Similar Posts

9 Comments

  1. to point 1:
    For the production of prototypes or very small series, this is definitely a valid option, but one that is already being used. For mass production, other production techniques are currently simply much cheaper. And I assume that in 20 years' time, it will still be cheaper to mass-produce a drop-forged casting than using 3D printing.

    1. There is no question that specialized manufacturing processes are more cost-effective for large series. However, there will certainly be more and more applications where the greater flexibility justifies higher costs. One concrete example is pressed parts for vehicle bodies. The cost of a pressing template runs into the millions. Once this has been produced, changing the mold cannot be financially justified for years to come.

      Conventional manufacturing processes will certainly not disappear, but they will be partially displaced.

  2. to 4.
    I hope Prof. Matthias König and his colleagues will find ways to reverse this trend. At least Prof. Matthias König is open to practical experience.

  3. Re 5.
    For me, security has been an architectural issue for 20 years now (security by design). But the absolute majority hope to be able to test security into systems.

    So I have doubts about this point again, serious doubts.

    1. I agree with you: we will definitely not be able to bring the issue to a close in 2018. I think it's more likely that there will be a few juicy scandals that will raise awareness of the issue of security and bring it to the public's attention.

  4. Hi Michael,
    nice article, thank you very much!
    A question about: „Specifically, there are already approaches today to automatically create, maintain and analyze the traceability of development artifacts with AI.“ Do you have a link or reference to this statement?

    Thanks in advance

    1. Hello Yan,

      Yes, I have examples. The following are actually used:
      - INSTALL: https://www.eclipse.org/mylyn/ is an open source project in which the development environment is focused on tasks: For example, you can structure the features to be implemented with JIRA. During implementation, Mylyn remembers which source code files you have touched and attaches this information to the feature when you check it in.
      - CARE: https://www.jamasoftware.com/ Is a commercial platform for product development, with components for requirements and testing. The status of the test results (manually or automatically tested) is automatically tracked and thus enables an up-to-date overview of the test status, i.e. whether tested, untested, outdated test, etc.
      - ANALYZE: http://intercax.com/products/syndeia/ is a tool that can be used to analyze traces across all tools.

      Finally, I would like to comment that I often find the term AI more primitive in practice than „artificial intelligence“ suggests. The question is also where tool-supported work ends and artificial intelligence begins. At the end of the day, the user's intelligence is still required.

      And there are certainly even better examples than these: These are just the ones where I have personally gained experience. For example, there are also tools that perform a text analysis and create or update traces based on this. As far as I know, however, not much of this has reached the mainstream yet.

      Greetings,
      - Michael

    2. The company EMPOLIS INFORMATION MANAGEMENT GMBH (https://www.empolis.com/) from Kaiserslautern has corresponding products in its range under the Information Management label. These systems can handle both structured and unstructured data, including development artifacts.

      But as Michael already indicated, AI can also be interpreted as artificial stupidity.

      /Carsten

Leave a Reply