Optimizing power and performance in automotive systems

Creating hardware and software in the automotive world is getting more complicated by the year. More features and application require ever increasing performance. It’s tough to keep up, especially when trying to design systems to be efficient and with low power consumption in mind.

How should one go about getting the best of both worlds? CPUs are powerful, but are hungry for energy. Parallelism is helping a lot, but not necessarily always the best option. As an example, let’s think about listening to music. Decoding an mp3-file is a breeze with modern processors. There are even dedicated low power blocks inside chips for this purpose. When leaving it to the CPU, it’s possible to do it with the lowest clock possible or burst it at full speed and sleep longer. Depending on the hardware, either one could be better. With multimedia it is quite important to take benefit of the in-built accelerators, pure CPU processing can be very inefficient, especially with more complex video codecs. So, plan your hardware according to your needs in this respect. We do!

To create the optimum system, the design must take energy into account for the whole R&D cycle

For the whole hardware architecture (even CPU blocks) it makes sense to design system so that they are as independent of each other as possible. Separating clock and power domains is preferred, so one can turn off or set dormant unneeded hardware and conserve power this way. Running multiple systems from the same power rail will create unwanted leakages, but can not always be avoided. System wake-ups created from multiple inputs need quiescent power (timers, CAN, external inputs). On the other hand, complexity and BOM will increase by too much separation. Energy saving is more critical when the vehicle is turned off, but will have an impact in active vehicles also. Thermals can play a key role, when tuning the performance of electronics that are buried deep inside the vehicle.

To create the optimum system, the design must take energy into account for the whole R&D cycle. In the beginning, chip and component selection should be done with power in mind and still maintaining automotive grade quality. Once the hardware design is complete, software must be validated on every software release, so regression is detected as early as possible. Targets should be estimated, before the system is even up-and-running. Software release cycles then strive to meet these targets once the software matures.

Make it future-proof!

If the design cycle is long, it makes sense to make your design flexible and with headroom for growth in both SW and HW sense. Adding displays would be the most likely expansion in the future since the amount of infotainment is growing fast. Therefore, it is important to pick a processor that can handle additional graphics load or even make the design modular in a way that is easy to connect to external graphics processing. Cameras and sensors are becoming more prevalent, with quite a lot of processing required for imaging or even autonomous driving. This naturally translates into more power and heat. Cables need to be ready for more current and the thermal design must be able to dissipate the extra heat. Passive or even active cooling might be needed. Location inside the vehicle is very important, since the ambient temperature makes a big impact. It is critical to get the heat away from the active components inside the design and the only way to do that is to push into the immediate environment. Therefore, the surface of the device needs to be carefully designed bearing this in mind. With a passive design, airflow is preferred, but most often only a conducted option is available. The unit should mechanically fit the vehicle optimally, so the thermal conductivity is at its best.

Inside the system, throttling is used to keep processors at decent temperatures. Multicore systems can rotate the active core, park them completely or adjust the operating voltage and frequency. At some point, however, performance starts to degrade and this needs to be avoided to keep the UI experience enjoyable.

 

Link Motion’s secure connected carputer could have protected BMW Cars from cyber-attacks

Major automakers continue to face cyber security vulnerabilities with connected cars, and it seems to be only a matter of time before the next incident will hit the headlines. Recently, Keen Security Lab conducted a security assessment of BMW Cars where they discovered several vulnerability findings with local and remote access vectors in BMW connected cars. The vulnerabilities mainly existed in the Head Unit, Telematics Control Unit (TCB), and Central Gateway Module, affecting various BMW models. Keen Security Lab was able to influence the vehicles via different kinds of attack chains by sending arbitrary diagnostic messages to electronic control units (ECUs).

Antti Korventausta

Antti Korventausta, Link Motion’s Lead System Architect, points out that the attack vectors described in the research are exactly what Link Motion has kept in mind when building the Motion T carputer’s security model. Below, he answers to the security-related questions about the Motion T.

What is Motion T? How has security been taken into account in Motion T design?

Motion T is the Link Motion Carputer, combining Instrument Cluster, Infotainment and connected features into one product. A key part to understand about Motion T is that the hardware and software have been developed hand-in-hand at Link Motion to take into account both security and vehicle safety.

The Motion T system architecture has also been reviewed by our friends at Irdeto, who’ve done a comprehensive attack tree analysis of the attack paths against a connected carputer. We’ve then used the results of that attack tree analysis to further improve the security measures in place.

How could the Motion T have protected BMW Cars from cyber-attacks?

A key part of the Link Motion system architecture is splitting functionalities into separated security levels using both hardware and software isolation mechanisms.

In this way, even when infotainment or connectivity solutions are compromised, that’s only a breaching of the outermost barrier of the system security. SW isolation measures are in place between the key carputer functionalities and all of the domains with connectivity. Further, the only part of the Link Motion carputer that actually has access to the CAN is hardware isolated into a separate MCU and that part does not communicate directly with any of the domains with connectivity.

Of course, since the carputer needs to function as one seamless system, communication channels are needed between the domains. Since those selfsame communication channels then form attack vectors from lower security levels to higher ones, they have been security hardened and special care has been taken to ensure their security. A good analogy would be to think about forming chokepoints into the system, then fortifying them heavily.

Motion T

Is it true that the Motion T is the most secure carputer in the world? Is it completely secure?

The brutal and honest truth is that nothing is ever completely secure. With the likes of the spectre and row hammer vulnerabilites surfacing in recent years, I think nobody has the luxury of believing themselves completely secure.

The real fight with being as secure as possible is to make an attacker’s work as difficult as possible – isolation of functionalities into separate domains, hardening interfaces and constantly staying up-to-date with fixes to vulnerabilities. And it’s not just about getting the large lines right, it’s also about being pedant with implementation of any security-intensive SW. After all, a system is only as secure as its weakest point.

Contrasting Motion T with existing products on the market, we’ve definitely tried to tackle a lot of the security issues that arise from interfacing with both vehicle systems and external networks. And in that regard, I’d say we’re more secure than almost any of the products out now. Of course, other companies have been slowly waking up to how important security has become – a development that can only be positive for the end-user.

So, what can I promise you? Unlike most other products, the Motion T has been built for security from the ground up, hand-in-hand in both HW and SW. And when it comes to defending the security of your car, Link Motion will fight attackers every step of the way.

To learn more about Link Motion’s cyber security solutions for connected cars (and other trending topics in the automotive industry), please follow our blog at link-motion.com/blog For example, you may find it interesting to read Part 1 (Through-Stack Development in Automotive Systems) and Part 2 (Bisecting Security and Safety in the Automotive Sphere) of Antti Korventausta’s blog series.

Bisecting Security and Safety in the Automotive Sphere

Through-Stack Development (Part 2)

Part of what makes connected carputers such a challenging area, is the need to meet stringent requirements on two fronts – vehicle safety (to ensure safe operation in traffic) and cyber-security (to protect the car from malicious attacks). The interesting part is that when correctly applied, solutions for one tend to lend themselves to the other.

An example of this can be found in the isolation of functionalities into different software or hardware domains. For safety, this is done to reach different Automotive Safety Integrity Levels (ASILs) for the domains, and thus minimize the amount of functionality needed at a higher ASIL level. Mandatory then, is to be able to conclusively prove that the domains are in fact sufficiently independent.

Isolation of functionalities into different SW or HW domains increments both vehicle safety and cyber-security.

Curiously, the same split into multiple domains creates well-defined minimal attack surfaces between the domains. Strategy-wise, we can think of them as chokepoints. If we can then design our Architecture to situate the targets of cyber-security attacks behind those chokepoints, like the spartans of old, we can deploy our phalanxes to make life difficult for anybody attempting to march through. If we’ve got a succession of different domains at different security levels, and we defend each chokepoint carefully, we greatly lengthen the available attack paths. Due to resembling a city defense with multiple concentric walls, this has also been called the “Minas Tirith” approach.

Brutal honesty about software security is that nothing is ever completely secure. No single magic trick will protect you from all attacks, no defense is truly impregnable. Instead, security is all about making an attackers life difficult on all fronts – lengthen all attack paths, make exploit development and deployment painful, make sure that any developed exploits don’t directly scale to the whole fleet of vehicles. In short? Instead of letting them waltz in, force them into a protracted siege. Don’t leave any mountain paths that can circumvent your phalanxes. Fight them every step of the way.

Security is all about making an attackers life difficult on all fronts.

An important lesson to understand is that in software security, you never get applauded for the things you did well, but rather slammed for the mistakes that slipped through. Interestingly, this same again holds for safety-oriented software, and there a lot has been done to define work methods, embodied in the software ASIL levels, to minimize those mistakes from ever slipping through. Essentially, the methods for development of safety-oriented systems also fit quite naturally to developing secure systems.

Of course that isn’t to say that the security happens “automatically”. Far from it. Since safety-oriented devices have long had limited connectivity, it is rare to find people with a solid foundation on both sides. Rather, what this means is that if you take an active approach of promoting both safety and security throughout your system design & development, both can be done within one development process with little extra overhead.

However, if different parts of your organization handle security and safety, instead of leveraging the natural overlap of the areas, you will end up wasting resources with sub-optimal end results on both sides. Security and safety need to be taken into account hand-in-hand, from the highest level system design, right down to each line of code.

Impeccable Engineering

In the current age of bureaucracy, busywork and unfulfilling jobs, you may occasionally find yourself seeking for a deeper meaning in your work. Why am I doing this again? Some resort to job jumping in the hopes of greener pastures, some may even contemplate changing their profession altogether. While these may well be the right choices in some circumstances, there is another option that is often not recognized: focusing on the impeccability of your own work may be the path towards contentment. As we are an engineering company, let’s call this the Impeccable Engineering method.

Okay, so what is Impeccable Engineering all about? It is essentially a universally applicable way of thinking in which the quality of your own work is at focus. After all, you are most intimately in control over your own actions. Impeccability is not about showing off, but to feel better about oneself by knowing one did the best one could. Imagine you were the only person left in the world. With no boss and no audience, you should still be doing impeccable work so that you may be content with your actions. Praise, reverence and a higher paycheck may come as a side-effect, but they should never be the main goal.

Impeccability is not about showing off, but to feel better about oneself by knowing one did the best one could. Take time to learn the subject matter deeply and mind the little details. 

Impeccable Engineering is about taking the time to learn the subject matter deeply – whatever you may be working on. It is about minding the little details, because a whole is always a sum of it’s parts. If some of the parts are lousy, it does not instill great confidence in the whole either. It is about ensuring the puzzle pieces in the big picture fit together seamlessly, as everything is connected and any work product is useless in isolation. It is about choosing elegance over kludges. It is about keeping things simple, and the ability to say no when need be. It is about caring about your own handiwork.

Impeccable Engineering is a good way to practice the art of concentration, as well as to engage in deep learning and self-discipline. These are all inherently satisfying in and of themselves once you get the hang of them. They are skills that enable you to develop yourself and to better navigate through daily work. In the process, you may inspire your colleagues and if you are lucky, perhaps even end up improving the work practices of the entire company.

While Impeccable Engineering always starts from within, it must be stated that it is not about isolating oneself from others. On the contrary, you should be open and share your work, so that others can learn from you and you can in turn learn from others. True impeccability can rarely be achieved alone – team work is needed for a polished end result.

In addition to improving your own job satisfaction, Impeccable Engineering has a positive effect on the whole organization. In a corporate setting quality is often approached as an objective science: how many bugs were fixed in the previous release? Are static analysis tools used to enforce coding guidelines? Is our system testing coverage high enough? All of these points and many more are undeniably important, and having strong quality assurance processes will improve the quality of your products in the long run. However, in the end, these are mere safety nets and alone not enough. If half-assmanship on individual level is the norm, no safety net is tight enough to turn a bad product into a great one.

By doing impeccable work you simply cannot go wrong.

The Gap Between Mobile & Automotive UX Design

In my previous blog post I talked about the learnings from the Phone Industry and how we can inspire ourselves to rethink the automotive usability. Now it’s time to dig a bit deeper into that.

In general, your smartphone knows everything about you – your daily routines, habits, places you visit, people you are in contact with and even a thing or two about your health, spendings and even your desires. The more you interact with your phone, the more the system knows about you. In a perfect world, this all enables a better experience for the user, as the phone can predict, suggest and help its user to achieve the tasks seamlessly and effortlessly.

“For decades, cars have been smart as buckets, just carrying people and goods from A to B.”

But what about your car? For decades, these vehicles have been smart as buckets, just carrying people and goods from A to B. Sure there have been small steps towards increasing the individual usability (Save your favorite radio channels! Power Seats memory!), but to be honest, you are basically “resetting your car” every time you get out of it and walk away – the experience cuts off at that moment.

ULTIMATE MOBILE DEVICE

What if your car DOES understand you? What if your car is the “Ultimate Mobile Device”? A car that learns how you like to drive, changing the driving settings according to the mood, weather and the road ahead? Or knows where you are heading and why, choosing just the right songs for you? Wouldn’t that be cool, if the car just knows how you like your environment to be set up in the specific time of the day – energizing you in the morning and calming you down in the evening? And the music you listen to in the car depends on with whom you are. All of the data points available around the car, with the power of internet combined with your smartphone knowledge, why not make more out of the driving experience? The car that suits you. By the way, this all would be possible with the secure connected Carputers made by Link Motion.

“All of the data around the car, the internet combined with your smartphone, why not make more out of the driving experience?”

DIFFERENCES FROM SMARTPHONES

As mentioned in the previous blog post, it is not as easy as to slap a smartphone or a tablet to a car dashboard. Even though there are many similarities, there still remain several major differences when comparing these two worlds:

1. User profiles – from one to many

A smartphone is designed to be used by one person, a car is used by a group of people. To be able to offer the best experience and collect additional data for the right profile, the car should recognize the driver. At the same time, all occupants inside the car should be recognized, so they can adjust their portion of the ride how they want. Smartphones are great companions for this.

2. Rule of thumb – from a hand to a dashboard

The User Interface of a phone is designed to be used when held in a hand. This creates a physical relation between your hand, thumb and the screen: You quickly learn how much you have to move your thumb to reach different locations over the touch screen – and those locations are always the same as long as you hold the phone the same way. To touch the menus, icons, the back button… these will become part of your muscle memory and in the best-case scenario, some of the actions can be done even without looking at the screen. The touch screen on car’s dashboard is different, as you have to reach your whole hand to be able to use it. There is no relation with you hand, so you need to double check constantly where your finger is pointing. On top of that, the touch is inaccurate and shaky as most of the times the hand is in the air in a moving vehicle.

3. Mind the gap – distance from the eyes

A dashboard is further away from the eyes than a tablet. Combining this with the previous point, this means you need bigger text and larger touch areas on the interface. Sure, the screen on the dash could be significantly larger than one on the phone, but because of the distance, the menu designs should be done closer to a sizing and clearance of a Smart TV menu.

4. The car does not fit in your pocket – and that’s a good thing!

While the phone is with you all the time, the car is not. It’s waiting you somewhere. There is a distance in-between. But the car knows where you are, thanks to your phone. This is probably the most overlooked aspect of an intelligent car and connectivity. By understanding the opportunity of two devices, one carried by you and one approached by you, there are several daily routines you can automate. When you are approaching the car, it knows to preheat or cool itself to an optimum temperature. The car can preload all the software and content it thinks you need for the next leg of driving. All is ready for you to just get in and start driving. Like you turn your phone sideways, when you want to see a landscape picture. That’s how natural it could be.

More insights and thoughts of the car user experience in the next post on my blog. Stay tuned!

TOP 5 reasons to work at Link Motion

1. You are revolutionizing the auto industry with the most secure connected carputer in the world 

Would you like to build the tools that make future cars smarter? Link Motion offers a unique advantage point to directly influence the unseen revolution where cars will be increasingly connected to Internet, powered by electricity and ultimately, be driven by themselves.

Link Motion is an automotive start-up which has a lot to offer, especially regarding challenging and interesting projects. Our employees come from various backgrounds, but a common factor for all of them is their world-class expertise which they have gained from their hobbies, previous work and education.

2. Flexible working hours and an opportunity for remote work

We trust our employees, and you are free to tailor the day according to your preferences. At the same time, this requires that you need to take the ownership of your work and how you manage your working time.

Employee feedback is important for our company, and we organize both face-to-face discussions and online surveys for this purpose. For example, just recently we conducted an annual Pulse Survey to measure employee satisfaction. The results lead to the majority of answers “strongly agreeing” that employees were satisfied with the workplace flexibility offered by Link Motion.

3. Working for an international organization – but without a complex hierarchy

We are based in Finland and China, and if you work remotely for us, you can basically work from anywhere in the world. Our customers and partners, automakers and Tier 1 suppliers, locate mostly in Asia, Europe and the U.S. Depending on your role, you might travel between our different office locations, visit our customers and attend major trade fairs. In any case, you will work closely with your colleagues from abroad on a daily basis.

Our company culture is relaxed and appreciative – here everyone can be themselves, both extroverts and introverts. The expertise and attitude are more important for us than degrees and titles.

We also offer versatile opportunities to develop our organization – the sky is the limit!

4. High-rated job satisfaction

The Pulse Survey also revealed a high job satisfaction of employees at Link Motion. To the question, “how satisfying and motivating it is to work at Link Motion?” the majority answered “very motivating”. A more detailed feedback outlined “freedom of choice of work place and time, innovation and great colleagues”.

5. Comprehensive occupational health and dental care

We collaborate with Mehiläinen in order to offer high quality occupational health care to our employees. Mehiläinen also offers online services which simplify the process of booking appointments.

Yet another advantage of working at Link Motion is that we provide dental care to all our employees, for the worth of 500€ per year per employee.

For Link Motion, the most important value that we can offer our employees is increasing their satisfaction and well-being.

Got interested? Join us!

We at Link Motion are constantly recruiting skilled and enthusiastic people. Check the details on our recruitment page:

Join us

Easily capture your vehicle data through an on-board diagnostic port

On-board diagnostics (OBD) interfaces have been in cars for a long time, since 1996 in the United States. Typically, they are only used by service shops and car inspectors but there are also other uses for it. Since OBD-II is basically a serial port, the hardware needed to use it is simple and readily available. There are Bluetooth, Wi-Fi and USB adapters available for purchase from many manufactures.

For example, when we wanted to quickly demo our instrument cluster displays in the Martti automated driving development car by VTT Technical Research Centre of Finland, we used a Bluetooth OBD-II adapter instead of connecting to the car’s CAN bus. This way we saved a lot of time and wiring. In addition, we did not have to test so much the actual car, since OBD-II communication is somewhat standard, and were interested in speed and RPM at this point.

Keeping automotive security on top of mind, Link Motion’s carputer ensures the development of various application opportunities with OBD-II, such as collecting driving data

OBD-II communication is simple, in short sending “0100” to the car makes it to respond to what mode 01 parameters it supports, and sending for example “010D” is replied with the vehicle speed. An article in Wikipedia lists the generic modes and parameters. Since OBD-II is mandatory in passenger cars, this method works almost worldwide for every brand and model.

There are Android and iOS OBD-II applications that provide instrumentation and even some basic fault code reading and clearing, though some of the functionality is brand- and model-specific. Naturally, car manufactures have not published their own additions to the standard communication in fear of unwanted use, as there is no security in the OBD-II standard. Android Auto and Apple CarPlay are also providing car interface and applications, but they are more focused on the entertainment, navigation and telecommunication areas.

All these ways of interfacing with the car also provide an attack point, and with the arrival of autonomous driving, even more risks. Here at Link Motion we are using sandboxing to prevent unauthorized access to the vehicles’ systems. So even if unauthorized messages or even access is reaching one level, it cannot reach the more critical areas. Even though car manufactures are not publishing their own additions, there is still a lot potential for all kind of applications. Even just collecting the driving data and providing some statistics would be beneficial to the owner, maybe also cloud support and data analytics – there are several possibilities.

 

Why does automotive quality management still lack attention to software?

How many lines of software are there in a modern car? Ford F150, like the name suggests, runs on approximately 150 million lines1. And how many lines are there in a modern passenger jet? Should be more, right? The Boeing 787 Dreamliner carries, in fact, only seven million lines2. In an F150, a single subsystem would on average contain more code than the whole Dreamliner.  So why then, isn’t the F150 able to land on Mars?

“Software size is one subtle clue that hints at the existence of latent quality problems.

Like many other trades, software engineering has its subtle clues. Software size is one that hints at the existence of latent quality problems. Eventually, large software tends to escape their creator’s understanding, introduce new forms of failure and suffer from unforeseen multiple point failures3. In today’s connected world, software size also translates to the size of the target vector for cybersecurity attacks, which are a rising concern for consumers4. Is the industry spending enough attention on software quality?

IATF 16949 is the bible for automotive quality management systems. From its thousand requirements, a dozen address software development processes specifically. In addition, the 16949 hints at two relatively common standards: ASPICE for software process improvement and capability determination, and ISO 26262 for functional safety. Part six of the latter is the only standard that has, in itself quite reasonable, requirements on the software, not just the development process.

“The automotive industry lacks quality requirements for software.

The automotive industry does not lack quality requirements, nor quality requirements for software development processes – it lacks quality requirements for software. Looking forward, this omission is detrimental for both the business and the quality. Academia has spent decades trying to define metrics to measure software quality. Practitioners know that while metrics serve as subtle clues, they cannot be applied out of context – like I did above. How would the practitioner’s view fit into the metrics and standards driven automotive industry?

The solution is simple: expert evaluation by a third party, backed up by an informative list of subtle clues based on lessons learned and publications released in the software industry. Hear the screams already? How expensive it must be to have the 150 million lines evaluated by an expert? Well, maybe the requirement for expert evaluation would drive the size of the software down and be cost-effective in middle to long term. Maybe software would be more re-usable. And maybe, our cars would spend less time standing at workshops. What do you think?

 

Footnotes:

1 eit Digital. 2016-01-13. Guess what requires 150 million lines of code…

2 USA Today. 2016-06-28. Your average car is a lot more code-driven than you think.

3 As explained by Richard I. Cook in his article “How Complex Systems Fail”.

4 As explained by my colleague Mikko in his blog post “Cybersecurity in connected cars – how do consumers see the rising cybersecurity threats”.

Test Automation in a Modern Automotive Product Development

Part 1 of the blog series on Test Automation
 
Note: Test Automation covers several distinct areas of testing a product, and can entail anything where a test is completely or partially automated. The reasons for automating testing include e.g. increasing testing performance, minimizing human error and performing complex or cumbersome tests or measurements not feasible in manual testing. This article focuses on functional and regression testing, where the main target is to respond to the needs of modern software driven product development by increasing testing performance. The target here is not to completely replace manual testing, only the parts with most to gain.


Introduction

Two disruptions that are ongoing in the modern automotive world are the ever-increasing role of software and the need to get product features out faster and closer to the final integration. Software is understood as the enabler for rapid feature development and updates, without the need to change the actual car hardware or even bring the car in for service. This separates the software development and release timeline from the rest of the car’s development and integration timelines. So, software is more complex, it is expected to be able to provide new features quickly from planning to delivery, and work on an already designed hardware platform (“the car”). Still, as the end-product sold and its customer experience are a result of both car hardware and software working together, the expected rapid software development cycle cannot cut corners in testing compared to the more HW-oriented working modes.

Software Driven Product Development 

Software development in other product development areas has used Agile methods successfully – sometimes more, sometimes less – in shortening the long lead time development models. The main driver has been the inevitable changes identified during development, and the cost of setting things in stone early in the project. The later the plans need to be fixed, the better information the planners have about the final product they want to produce. In order to replicate the success seen in other software development areas with regards to speeding up the feature development cycle, the automotive industry is looking into ways of integrating Agile methods as part of automotive development.

There is much to like in software driven product development. The promises of a faster product cycle with low effort variants, faster feature development, later “feature freeze” deadlines, easy after sales updates and maintenance without servicing the car. However, unlike, e.g. consumer electronics, the automotive field has a much larger body of legal and quality related standards. Integrating the same methods will require considerable adaptation both in the methods and the mindset of the people working with the product development. Traditional testing models are based purely on the existing legal and quality standard framework of the automotive industry. As the new development models are adapted to fit the framework, but not all the traditions, new testing models must follow.

The primary conflict with traditional thinking in testing and new development models is having the testable product defined early in the project. If only we had the product requirements defined early, both product development and test automation development could proceed their own ways. Both would have their targets set, and both would target implementing the full requirements coverage of code and tests according (roughly) in the same schedule. Unfortunately, that is no longer possible. Both product development and test development must instead follow a short-term plan with a high-level overall picture of the final target, to allow all the benefits of e.g. Agile-style development. In such a project, changes are the new norm.

 
Lesson learned: Automated test development for agile-style projects requires close co-operation and communication between product development teams and test development. Going as far as having functional automated tests implemented by the product development teams themselves. Having separate teams handle product software and test development resulted in agile changes to product development only becoming visible once tests failed. Finally, new test development ground to a halt because all of the team’s effort was spent just tracking and reworking tests based on any changes to the product software. Testing cannot be ready in time to test the software, if it has to constantly play catch-up.

Test Interfaces

Small changes in product development constantly breaking automated tests highlight another aspect of test automation and agile-style development models. Traditional development emphasizes interface control in SW development to make sure any changes do not cause uncontrolled effects outside the modified components. As with all other changes, interface changes are more rapid and common. Control is still important, but its role is more communicative and less blocking.

Automated functional tests have several possible interfacing levels, for example, in the UI. Tests can interface with any combination of the actual display and control hardware (test robots), UI elements programmatically (cuTeDriver, Squish, Selenium) or via a lower level API. The higher the interaction level, the more completely the test system tests the full product stack, but also the more fragile the test system and tests are to any changes in the product UI. When working with multiple variants of the same product family, the harder it becomes to use the higher layers. When working with an unstable UI – colour themes, small changes requested by the customer, unfinished features and so on – test development on the highest level suffers. Capable manual testers can overcome such minor changes, but test automation very rarely can. Even when product development knows the limitations of test automation, trying to work with unstable test interfaces will incur a considerable risk and cost to the project. Both in testing and in development.

 
Lesson learned: Test automation lives or dies with the stability of the test interfaces. Finding the right balance for the test interface level is crucial. It should be as high as possible to cover as big part of the product as possible, but not too high to either prevent test automation sync to product development or stifle product development capability to respond rapidly to change needs. This interface decision needs to be part of the product development architecture and design work to provide the suitable interfaces for testing. Again something that needs to be considered when any changes’ impacts are analyzed.

Automated testing is now practically intertwined in the product architecture, design and implementation. Having a test development team separated from product development is not practical. It’s not important, how the work is organised. Tests can be implemented just as well by a dedicated test team members assigned to work closely with product teams, by dedicated test developers inside product teams or even the product developers themselves. The – critically – important part is planning and implementing tests and product code together.

Link Motion and Irdeto Join Forces to Provide Automobile OEM’s a Complete Security & Safety Technology Platform for New Lines of Connected and Autonomous Cars

Link Motion integrates Irdeto’s new smartphone-based secure vehicle access and safety solution, Keystone, into the Link Motion CarBrain platform. Automobile OEMs that implement Link Motion’s CarBrain will now provide consumers with the simplicity they expect to safely manage and operate today’s connected cars and autonomous vehicles, especially in new ride-sharing business models. From controlling the speed limit of the car, time of use, geolocation, trunk or glove box access, number of passengers in the vehicle and much more, car owners have the flexibility and freedom to customize their driving experience by enforcing vehicle usage policies.

“Traditional business models are rapidly changing with the development of the software-defined car and autonomous features,” said Pasi Nieminen, Vice President of Link Motion. “Most OEMs don’t want to source their technology offerings with multiple vendors, but rather integrate one technology platform that can deploy all offerings. By combining Keystone with CarBrain, we provide OEMs with a joint solution they want to ensure their product offerings keep up as OEM business models change. We also look forward to including these features in our own smart ride business as well.”

For further informaton, please read the full press release.