In this edition, Hrachya Pogosov’s writes a story of an 8-months engineering project. It is an article that encompasses both the engineering, the processes, and the people. It describes the experiments that were implemented, it talks about achievements, challenges, and places for improvement. As such, it is both a story and a plan for action. This is really an article of sharing best practices and warning about possible pitfalls. It is a story of an engineering team that worked together for 8 months with all its dramas and breakthroughs. During this time, we even had a couple that fell in love and got married. If we had a good film scriptwriter (сценарист), then with some expansion and fantasy this story could be possibly turned into a movie, where the heroes are engineers. Anybody knows of any scriptwriter?

The second article is a story written by Zorik Markosyan and Suren Muradyan about their travel to customer site for the delivery, installalation, and training of the Strengths of Materials Labs.

If you would like to read this article in Russian, please click here.

How it started, short description of the project, now-how of the project

Hello, dear colleagues and friends! In this article, I would like to describe a brief history of the development team’s 8 months of life. We finished the project to create an intelligent testing system for ADAS (Advanced Driver Assistance Systems) at YEA Engineering. These were challenging but interesting 8 months, full of experiences and new discoveries, both technically and in terms of managing the process of creating complex test benches.

The system, which was developed by our engineers, represents 2 separated HIL (Hardware-in-the-Loop) racks (Figure 1). The first of them constitutes a subsystem for ADAS testing. Its structure you could see on Figure 2.

HIL rack for ADAS testing

This HIL rack provides the ability to test ADAS electronic modules in real-time by simulating the surrounding environment to replicate and test various situations:

● Testing adaptive cruise control; ● Testing collision warning systems; ● Testing emergency braking systems; ● Testing lane departure warning systems; ● Testing lane-keeping assist systems; ● Testing blind-spot monitoring systems; ● Testing automatic parking systems; ● Testing automatic lane change systems; ● Testing reverse parking exit warning systems; ● Testing autonomous vehicle control systems.

To simulate the environment, the vehicles, and the listed scenarios, we chose the Panosim software. Putting my hand on my heart, I'll say that it was not a typical and risky choice. The software was honestly raw, bugs we discovered during development were fixed by releasing additional scripts, documentation was translated into English on the fly, and communication with the technical support service was daily using all possible and impossible messengers.

But in the end, the risk turned out to be justified, as no one could guarantee that such a massive system would work using more renowned software. Technical support promptly handled all our requests, made the necessary changes and fixes, helped to find missing components on the internal Chinese market, and organized fast shipping to Yerevan. From a management perspective, I gained significant and positive experience from communicating with them.

The most challenging aspect to implement was to make everything work in real-time and using a single control computer. Take another look at Figure 2 and imagine an incredibly vast array of data that our system simulated.

We faced significant challenges when attempting to implement the simultaneous operation of 12 video streams.

As it turned out, Panosim operates on the Unity engine, which has physical limitations on the use of video streams - no more than 4 physically connected monitors. And we intended to use 12 of them! Even our colleagues from China were not informed about this limitation (earlier I didn't mention that Panosim is a Chinese company). The solution was found simple and original. To the video card outputs was connected video wall (4K video splitters), which separate 1 video stream on 4. This decision allows us to use 3 monitors instead of 12 (Look at Figure 3).

The second part of this Rack realized functionality, which you can see on Figure 4.

The most hard and interesting technology which deserves special mention is subsystem for converting video signal from HDMI to GiGeVision.

To implement this subsystem, we initially chose a ready-made product produced in England. I intentionally don’t mention the company's name, as the experience of dealing with them left only negative emotions, to put it mildly. As a result, we lost a lot of time, nerves, energy, and money. The hardware turned out to be defective and will soon fly back to foggy Albion to its forefathers.

In turn, together with colleagues from Red Feather, we manufactured our converter based on NVidia technology, which completely satisfied both us and our client.

HIL Rack for mono and stereo cameras testing

This Rack represents a combination of 2 independent products (Figure 5), which our company can supply both separately and together. I would like to delve into the description of the subsystem for testing stereo cameras in more detail, as it is the most interesting and complex.

A subsystem for stereo cameras testing represents a compact rackmount box. Inside the box is situated a target camera to be tested. In front of the camera spaced mechanism (Figure 6) includes mirrors and monitors. The system provides the projection of images from monitors onto the lenses of the tested camera using mirrors, implementing a principle similar to the operation of a pentaprism.

Thanks to the centrally located tested camera with two lenses and a specially designed mirror mechanism that allows fine-tuning in all planes, the system enables effective testing of stereo cameras from various manufacturers.

In addition, the camera holder in the system also features the functionality of fine-tuning in multiple planes, ensuring accuracy and flexibility during testing. This feature allows adapting the system to various models of stereo cameras and provides a high degree of versatility in the testing process.

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

Now-how of the project processes

I think I described the results of the 8 months of work of an 8-person team quite comprehensively from a technical point of view. Now I'd like to show you the methods of our working, which allow us to achieve such high results in such tight deadlines. And what is more important, we did it without surprises during the project handling to the customer.

I would like to note in advance that the methodology we used and the system we built were implemented by our company for the first time. We will talk about how we adopted Scrum for complex intellectual systems development, how we built many processes in the company from the start point, how we communicated with each other and with the customer and what the results we have achieved.

How did we separate project on features and why

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

Initially, we designed the basic system, the so-called project skeleton, onto which we gradually added the substance during development. The system step by step became more comprehensive, acquiring additional functionality and value for the customer. The ready features after testing were integrated into the base system, which with each sprint became more and more like the final product.

We demonstrated values to the customer at the end of almost every sprint. During video calls if it was necessary at first we show to the customer our setup. After that both separately and simultaneously we demonstrated developed features. The demonstration of simultaneous work of all virtual sensors was a very important component, because in the technical specification there were strict requirements for processing speed.

This approach, based on active collaboration with the client and his involvement in the work, allowed us to be confident that we were moving in the right direction and delivering exactly what the client expected from us.

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 took a different approach. We didn't spend a lot of time on a detailed design of the entire system, followed by its planning, development, integration, and only then testing, creating Gantt charts, which, according to Murphy's Law, never come true, and many, many other things. We simplified things and didn't go wrong. After a preliminary surface design – talking about the development of the system's structural scheme and breaking it down into values – we immediately started the programming process. Each of our features went through all the necessary stages independently, and we checked the system's functionality with each integration to avoid surprises at the end.

Because of high uncertainty we choose one-month sprints, which could contain both software and hardware development. Tasks for mechanical developers were decomposed in such a way that developers cloud finished them into 1 sprint with due skills. Of course, it didn't always work out – secretly, more often it didn't. But I hope that skill will come to our team over time. Demonstrating the hardware part to the customer was also much less frequent. However, we still showed the most interesting systems in 3D models to assess them in terms of usability. Frequent internal reviews allowed mechanical engineers to implement their ideas in the best way possible. In the future, there are ideas to conduct similar reviews more often, for example, once a week, which will reduce the chances of messing up at the end of the project or designing something that goes against the product owner's vision. Another interesting idea for reviewing mechanical systems is to invite colleagues from production, assembly specialists, and even programmers. Because everyone can express interesting ideas from the perspective of operational properties, it's essential not to overlook this aspect.

What did we get after closing the project?

● We formed a cohesive team that supports and helps each other; ● Achieved transparency in interactions with the client; ● Ensured that the client became a part of our team; ● Regularly demonstrated the results of our work and received feedback; ● Started conducting reviews within the team more actively, but, in my opinion, not frequently enough; ● Made a collective effort to complete projects on time, though unfortunately, it happened only in the last month; ● Achieved significant budget savings, both in terms of procurement and human resources; ● Implemented a certain number of useful templates, IT solutions, and identified next steps for improving internal and external processes.

How could we help the Engineering Community?

Despite YEA Engineering being at the beginning of its self development path, as self 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 of organizing the workflow.

We can not only solve engineering tasks for you, participate as a co-executor in your projects, but also try to jointly solve problems of a completely different nature, beyond the scope of physics, mathematics, electrical engineering, in a word, the engineering industry. Additionally, we can implement a project management system for your business, provide training, create a set of templates, and customize the system to meet your needs.

We are always open to communication. If you wish, you can contact us through the website or LinkedIn: ● YEAE.am ● https://www.linkedin.com/company/yeae/

by Suren Muradyan, Integrator LLC

We travelled to customer site for commissioning of Integrator’s product “Strength of Materials”. The first stage of the work was opening the boxes and installing the “Strength of Materials” parts.

We then installed our software on the laptops and configured the samples. On the last day we explained to the client how it works. During implementation, all aspects of hardware and software were considered. They really liked the product and said that they would be happy to cooperate with us in the future.

Summary:

All work was done very well! We saw our products at the site of their final operation, outside the factory, and knew what problems could arise during transportation, how the design could be improved, and made more durable. We also have some suggestions on evaluation methods.

The YEAE is taking part in this exhibition in Bangalore, India.

The YEAE is taking part in this exhibition in Shanghai, China.

ISB is taking part in this Sheet Metal Working Technology Exhibition that will take place in Hanover, Germany.