Scram for creating hardware. Project to create an ADAS testing system or a brief history of 8 months of our life

How it started, a brief description of the project and its know-how

Good afternoon, dear colleagues and friends! For more than a year now I have been working in Armenia in a company that is engaged in the creation of complex, integrated systems on a turn-key basis. They took me on as a project manager, which is what I have been doing for the last 5+ years. In this article I would like to describe a brief history of 8 months in the life of the development team of a project to create a system for testing ADAS at YEA Engineering. It was a difficult but interesting 8 months, full of impressions and new discoveries, both from the technical side and from the management of the process of creating complex integrated test benches. In the project, for the first time in the company, we began to use Scrum, I will try to describe below how we did it and what results we achieved.

The system developed by our engineers consists of 2 separate HIL communication racks (Figure 1). The first rack is the ADAS testing subsystem. Its block diagram is presented in Figure 2.

HIL ADAS Test Rack

This HIL rack provides real-time verification of ADAS electronic modules through a simulated environment to simulate and test the following situations:

• Testing adaptive cruise control;

• Collision warning system testing;

• Testing the emergency braking system;

• Testing the lane departure warning system;

• Testing the vehicle lane keeping system;

• Testing the blind spot monitoring system

• Automatic parking system testing;

• Testing the automatic lane change system;

• Testing the warning system when leaving a parking lot in reverse;

• Testing of the autonomous vehicle control system.

Panosim software was chosen to simulate the environment, vehicle and the listed scenarios. I can honestly say that this was not a typical and risky choice. The software was frankly crude, bugs that we found during the development process were eliminated by releasing additional scripts, documentation was translated into English on the fly, and communication with technical support was daily using all possible and impossible messengers. But in the end, the risk turned out to be justified, since no one could guarantee that such a large-scale system would work using more famous software. Technical support promptly processed all our requests, made the necessary changes and corrections, helped select missing components on the domestic Chinese market, and organized quick shipment to Yerevan. From a management point of view, I received a huge and positive experience from communicating with them.

The most difficult aspect to implement was to make everything work in real time and using a single control computer. Take another look at Fig. 2 and imagine the incredibly huge data set that our system simulated.

We encountered big problems when trying to implement simultaneous operation of 12 video streams. As it turned out, Panosim runs on the Unity engine, which has physical restrictions on the use of video streams – no more than 4 physically connected monitors. And we were supposed to use 12 of them! Even my colleagues from China did not know about this limitation (I did not mention earlier that Panosim is a Chinese company). The solution was found to be simple and original. Video splitters were connected to the outputs of the video cards, which split 1 video stream into 4, so we were able to use not 12 monitors, but 3 for testing and work (see Figure 3).

The second part of this rack performed the functionality shown in Figure 4.

The most complex and interesting technology that deserves special mention here is the video signal conversion subsystem from HDMI TO GiGeVision. To implement this subsystem, we initially chose a finished product that is produced in England. I don’t write the name of the company on purpose, since from its use and communication with them there were only negative emotions, if expressed without using obscene words. As a result, we lost a lot of time, nerves, effort and money. The equipment turned out to be defective and will soon fly to Foggy Albion back to its ancestors. We, in turn, together with our colleagues from Red Feather, produced our own converter based on NVidia technology, which completely satisfied both us and our customer.

HIL rack for testing mono and stereo cameras

This rack is a combination of two independent products (Figure 5), which our company can supply either separately or in combination. I would like to dwell in more detail on the description of the subsystem for testing stereo cameras, as the most interesting and complex.

The stereo camera testing subsystem is a compact box integrated into a telecommunications rack. The target chamber to be tested is placed inside the box. In front of the camera there is a mechanism (Figure 6) that includes mirrors and monitors. The subsystem ensures the projection of images from monitors onto the lenses of the camera under test using mirrors that implement a principle similar to the operating principle of a pentaprism.

Thanks to the central placement of the camera under test with two lenses and a specially designed mirror mechanism that allows fine-tuning in all planes, the system allows you to effectively test stereo cameras from various manufacturers.

In addition, the system's camera holder also features multi-dimensional fine-tuning functionality to provide precision and flexibility in testing. This feature allows the system to be adapted to various stereo camera models and provides a high degree of versatility in the testing process.

The overall system architecture ensures high accuracy and stability when testing stereo cameras, making it an effective tool for assessing the performance and quality of various models on the market.

Know-how when implementing new project management processes

It seems to me that I described in some detail from a technical point of view the result of 8 months of work by a team of 8 people. Next, I would like to describe the methods of our work, which allowed us to achieve such results in a short time and, most importantly, without any surprises during delivery of the work to the customer.

Let me make a reservation in advance that our company implemented the methodology we used and the system we built for the first time. We will talk about how we adapted Scrum to develop complex intelligent systems, how we built many processes in the company from scratch, how we interacted with each other and with the customer, and what results we achieved.

How did we break the project into features and why?

Unlike the classic project approach, we broke the project down into values. Features or ready-made blocks that, after development, can be immediately demonstrated to the customer.

Initially, we designed a basic system, the so-called skeleton of the project, onto which we added meat as development progressed. The system gradually became more and more capacious, acquiring additional functionality and value for the customer. After testing, the finished features were integrated into the base system, which with each sprint became more and more similar to the final product.

We demonstrated value to the customer at the end of almost every sprint. During video calls, if necessary, we first showed the working setup. After that, the new developed functions were shown both separately and simultaneously. Demonstration of the simultaneous operation of all virtual sensors was an important component, since the technical specifications had strict requirements for operating speed.

It is this approach, based on active interaction with the customer and his involvement in the work, that allowed us to be confident that we are moving in the right direction and that the customer expects from us exactly what we intended.

Scrum for hardware development

In contrast to the waterfall model, where there is a strict sequence of stages in the development of complex systems, we did things differently. We didn’t spend a lot of time on the detailed design of the entire system, then its design, development, integration and only then testing, drawing up Gantt charts, which, according to Murphy’s law, never come true, and much, much more. We made it simpler and we didn’t make a mistake. After the preliminary surface design, which is about developing a structural diagram of the system and breaking it down into values, we immediately began the programming process. Each of our features went through all the necessary stages independently, and we checked the performance of the system with each integration in order to avoid surprises at the end.

Due to the high uncertainty, we chose one-month sprints that could accommodate both software development and design development. The tasks for the designers were decomposed in such a way that they could be completed in a month with the proper skill. Of course, this was not always possible, I’ll tell you a secret, more often than not it was not possible, but I hope that the skill will come to our team over time. Demonstrations to the customer regarding hardware were also much less frequent, but we still showed the most interesting systems in 3D models in order to evaluate them from the point of view of ease of use. Frequent internal reviews allowed designers to implement their ideas in the best way. In the future, there are ideas to do similar reviews more often, for example, once a week, which will give less chance of screwing up at the end of the project or designing something that goes against the vision of the product owner. There is also an interesting idea to invite colleagues from production, assembly specialists and even programmers to review mechanical systems. After all, everyone can express interesting ideas in terms of operational properties and this should not be neglected.

What did we get as a result of closing the project?

• We have formed a close-knit team that supports and helps each other;

• Achieved transparency in interaction with the client;

• We achieved that the customer became part of the team for us;

• We regularly demonstrated the results of our work and received feedback;

• We began to conduct more active reviews within the team, but, in my opinion, not often enough;

• We pulled together every effort to complete the projects on time, although, unfortunately, this only happened in the last month;

• We achieved significant budget savings, both in terms of procurement and human resources;

• We introduced a certain number of useful templates and IT solutions and identified the next steps to improve internal and external processes;

• We saved a significant part of the budget both in terms of procurement and in terms of human resources involved (more than 30% in both).

How can we help the engineering community?

Despite the fact that YEA Engineering is at the beginning of its development path, since development is a lifelong journey, we want to share our experience with the community and have a great desire to help you implement the best methods for organizing your workflow.

We can not only solve engineering problems for you, participate as a co-executor in your projects, but also try to work with you to solve problems of a completely different nature that lie outside the area of ​​physics, mathematics, electrical engineering, in a word, the engineering industry. We can also implement a project management system for your business, provide training, create a number of templates, and customize the system to suit your needs.

We are always open for communication. If you wish, you can contact us through the website or LinkedIn: