Departments

R&D- Software

Software development in the steel industry

What do you do with software?

R&D – software

"Good question! More and more exciting IT solutions are being used in the steel industry.

The main focus of the software products we develop is on the steel industry. Often, the solutions are not actually tied to the industry, but we employ them there. New ideas arise from our customers' daily routine. We see problems at customers for which there are no or no good solutions yet...."

"Good question! More and more exciting IT solutions are being used in the steel industry.

Do you have an example?

Calibration of many small plant parts is often a very time-consuming process at the customer site. We solved that with 3D laser scanners and an automated object measurement solution written in C++. At another customer, we freed employees from having to constantly watch the unspooling of wire. For that, we ended up using machine learning based on video data to detect fault conditions. While finding a solution for this problem, we also experimented with 2D laser scanners, as well as stereo and time-of-flight cameras, but ultimately traditional high-speed cameras were most convincing.

Do you do much with C++?

“Actually, no. We use C++ when we need the performance of a compiled language for certain pieces of code. Our language of choice is definitely Python.

The microservices of our Level2 framework Insight360 running in Docker were developed in Python. We can’t avoid a little SQL here and there, and we’ve also touched C# with pointed fingers. You can also try out other languages. For example, we used Go for an interface tool between an SQL database and a Rockwell controller. In the end, we just use whatever provides the best platform for the solution. For the UI, this is now almost always web with Javascript.”

So you also build web front-ends?

“Yes, especially because it makes deployments so much easier and the clients only need a browser. I think we are also at the forefront of introducing web technology in rolling mill automation. Classic client-server applications are still widespread there. And thanks to technologies such as Vue and transpiled JavaScript, web development now works very well.”

What is the distribution between front-end and back-end development?

“That varies greatly depending on the product and project. On average, it’s about 30% front-end, 70% back-end. Our front-ends tend to be for high-level functions and are only indirectly relevant for production. The HMIs that have a direct impact on production are done by our colleagues in the automation department.”

When would you say that you are good at what you do?

“There are several aspects to this. On the one hand, we develop the solutions for concrete customer projects. That means, of course, that our customer has to be happy with the solution. On the other hand, we also aim to create products that can be used by new customers with as little effort as possible. This always requires a balance between generics and specific customer requirements. Last but not least, we also want to be happy. In other words, our software must also feel good to us as developers.”

When does software feel good?

“Software primarily must not be written for computers, but for developers. Easy to read and understand. The TAO of Python describes this quite well:

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.

The next important point is maintainability. Our products grow with our customers’ projects. It is part of our daily business to add new features to our existing solutions. Software must be designed to allow this. It must be easy to refactor. Basically, all other best practices in software development naturally evolve from this demand. As the software grows, it happens you are no longer 100% satisfied with some areas. Then, of course, you have to address this, i.e. by actively planning refactoring.

A very important aspect is a well-founded feeling of confidence: Nobody wants to sleep badly after a customer deployment. So we use Continuous Integration (CI) with automated tests and customer-specific integration environments. This is important, for example, to also ensure that necessary data migrations with customer-specific data work cleanly. Deployments are always fully automated and reproducible.”

How do you organize your work?

“It varies greatly, depending on what the problem is. There are products where it is very clear to us in advance what the solution will look like. These can be estimated and planned very well. But we also have topics that really need research work first. For one of our products, it took us more than two years to find the right solution. There surely is no one-size-fits-all approach to a project. We coordinate our work items on a weekly basis, using Kanban. This way we can always tackle the urgent stuff without leaving the important stuff behind. For larger projects with fixed deadlines, we of course run the full show with effort estimates, burn-down charts, risk assessments and all this. As always, the solution must fit the task.

We also always staff the topics with several people as early as possible. This has proven to be successful and also has many advantages: No head monopolies, more homogeneous results and – very important – no calls during illness or vacation.”