The Future Is Service-Oriented Architecture

Coming to dSpace for Venessa Županović was first and foremost a challenge, which is why she ended up working as a software development engineer. She points out, it all started with a diploma back in 2014 at the Faculty of Electrical Engineering and Computing - Computer Science.

During my career, I initially worked on projects in the field of telecommunications, but in the end, I happened to be in the Automotive industry, where I eventually stayed because I was attracted by the challenges it offers, but the fact is that the line between the two sectors it is getting thinner, Županovic points out.

I got a job at DSpace two years ago on a product called Bus Manager, which is a tool for configuring communication on the bus: CAN, LIN, FlexRay, CAN FD, and of course Ethernet. We are currently adding support for service-oriented communication via Ethernet to the mentioned tool, he explains further.

Why is so important to think out of the box and why Ethernet?

The complexity of the networks of electronic components and the amount of data generated by them in modern cars is truly enormous. Growing demands for bandwidth, flexibility and cost-effectiveness bring the Automotive industry to the point where it is necessary to think beyond the framework of current network technologies such as CAN, LIN, MOST, and FlexRay. Infotainment, ADAS, autonomous driving, Over the Air update (OTA) - all these are examples of applications that require fast and secure data transfer, which is why Ethernet, as a mature technology that has been in use for more than 40 years, has proven to be the "best fit ". Of course, things are not so ideal in practice. Ethernet as the "best-effort" protocol is in principle at odds with strict real-time requirements where very precise deterministic behavior is expected from network components to protect passengers and goods, so the application and adaptation of existing security mechanisms is a huge challenge.

Why service-oriented communication?

If we look at technologies such as CAN and LIN there the data is sent constantly, i.e. the sender doesn't care if the data it sends is needed by some other node in the network which can result in a pile of data unnecessarily flooding the network. Furthermore, with the mentioned technologies HW and SW are strictly interdependent, ie, communication between ECUs (control units) is defined statically for the reason that it is assumed that SW will not be modified for its lifetime, which is of course not applicable today. Today we expect that changes in the network can occur at any time and that we can always add a new software component without fear that it will be compatible with existing ones. Precisely because of all the above, service-oriented architecture enters the story. In a service-oriented architecture, the server sends data only when there is a real need for it, and the compatibility problem is solved via middleware - SOME / IP (Service-Oriented Middleware over IP).

And what is SOME / IP (Service-Oriented Middleware over IP)?

SOME / IP - Scalable Service-Oriented Middleware over IP is a Middleware solution that enables service-oriented communication within a network of ECUs, more precisely, Automotive specific RPC "Remote Procedure Call" mechanism with a full range of functionalities such as serialization and the ability to find and monitor functional entities in a network called services.

What technologies and programming languages ​​do we use?

Of the programming languages, during development, we use C # (.Net 4.7.2) and C, and for testing Python 3. As an IDE we use Microsoft Visual Studio.

Open positions in dSpace:

Full Stack Developer

Application Engineer

C# Software Developer

Customer Success