For 30 years electronic engineers worldwide rely on Altium products to develop and create printed circuit board (PCB) designs. With the acquisition of TASKING and its toolset for embedded software development in 2001, Altium reached out to target the compiler business and with that the software side of things such as automotive applications. Since then the combination of Altium Designer and TASKING tool suites provides an excellent system of hardware plus software design solutions.
Today, Altium is well positioned with regional headquarters in all major markets and revenue of 70 million USD in 2014. Altium, through its TASKING brand, is a dominant player in the field of programming tools for automotive under the hood applications such as powertrain, chassis control, and ADAS. If you drive a European brand, it’s almost guaranteed that the software inside your car was built using TASKING tools.
Mr. Vink, where do you see the TASKING brand positioned within Altium? And how are you positioned in the market for embedded software development tools?
The tagline of Altium has always been that we want to provide affordable tools for everyone. So, the customer can be NASA as well as every other regular developer. The intention of Altium is to grow both Altium itself as well as the TASKING brand, and that growth could be either organic or through acquisitions.
TASKING has its roots in the Netherlands. It was founded in 1977. We entered the embedded compiler business in approximately 1985, and the roots of that business came from Philips. Our sales model is based on enterprise selling. That’s completely different from the Altium sales model. For TASKING to be successful, we first had to set up a tight relation with silicon manufactures for example, Infineon. Such relationship enables us to sell our software development tools to OEMs and Tier Ones, and subsequently to sell the tools into their ecosystems as well. We address the high-end of compilers for the automotive industry, with a focus on powertrain, chassis control and advanced driver assistance systems. In Europe we dominate this market space, in the USA we face fierce competition from local tool suppliers, in the APAC we're well established, and we recently experience a rapid growth in Japan and Korea.
How would you describe the R&D organization at TASKING?
The R&D organization and office with approximately 50 engineers is located in Amersfoort, the Netherlands. We also have a small engineering staff in Boston USA that work from home offices. What matters to us is the technical talent of our engineers. Therefore we attract engineers of different nationalities to fulfil highly-specialized engineering roles.
All compilers for the different target architectures that we support such as Infineon AURIX, Renesas RH850, Freescale/STMicorelectonics Power Architecture, and ARM are built using one and the same compiler construction platform called VIPER. Our organization is structured accordingly. One group is responsible for the platform technology. This group is research oriented and technology driven. Each target architecture is supported by a dedicated team. These teams are customer/market driven and are in close contact with the silicon vendor(s) of that specific target architecture.
First line customer support is close to the customer and is handled via the regional sales offices, whereas second line support is integrated in the engineering organization. In addition we have a group that delivers professional services, those services are typically related to the TASKING toolsets.
You started working with software applications almost 30 years ago. What has changed in the way you see these applications are being utilized by the automotive industry?
In the 1990's we changed the pace. If you look at the automotive industry, you see that the quality of vehicles increased significantly in the 1980's, and in the 1990's a lot of mechanical systems were replaced by electronic systems. For example, electronic fuel injection became a commodity and anti-lock braking systems were introduced. This caused a rapid growth of our company. After 2000 the complexity of the microcontrollers applied in automotive increased rapidly. Multicore became the norm to fulfil the computational and safety requirements of powertrain applications. The increasing complexity of the algorithms applied in chassis control and ADAS systems, combined with the safety issues that occur if these systems fail triggered the introduction of safety standards such as ISO 26262.
In the early days the discriminating factor between compiler vendors was in compiler optimization. We mainly competed on code size and execution speed. Nowadays the correctness of the generated code is of utmost importance to our customers.
What types of cars contain your software? Is it to be found in every vehicle type, from electric vehicles to conventional vehicles?
Our software is found in more than 50% of all cars. If you drive a European brand, then it’s almost guaranteed that it contains software that was built using our tools. This applies to compact models as well as to the most luxurious cars - from combustion engines to, hybrid, to fully electrified. For example the electronic systems in the BMW i3 car are mainly programmed with TASKING tools.
The automotive industry is evolving rapidly. How does TASKING, as a brand, manage to stay competitive in this market?
By doing serious research and by focussing on a specific market segment. The requirements of the automotive industry deviate from those of for example consumer electronics. We have to focus on the issues that are relevant for the particular market we are in. We are customer driven, we listen to our customers and adapt our tools to their needs. If two customers require different solutions to solve the same underlying problem, for example specific extensions to support a multi-core architecture, then each customer gets a toolset that fulfils their particular requirements.
One of the trends of today within the automotive industry is compliance with safety standards. For us, it’s very important that our tools can be used in a safety-relevant environment. This means that particular features had to be built into the tools, for example features to minimize the risk that due to incorrect use of the tools a safety issue could be introduced, or go by undetected, in the systems built by our customers.
How do you evaluate the product quality of your software tools, and how do you see the relation between product quality and process maturity?
For me, product quality defines whether a product is bug-free or not, and typically that’s the most important characteristic of a code generation tool. Product quality is measured via exhaustive testing and comparing the results against the results obtained by toolsets of other suppliers. In order to develop a bug-free product, you must have mature processes in place, otherwise you are not able to develop and maintain a product that adheres to the state of the art. Suppliers to the automotive industry typically implement their processes in conformance with ASPICE compliance level 2.
You said product quality is measured via exhaustive testing, did the testing methods for compiler software change over time?
From 1985 to 2010 all compiler vendors applied the same test approach. In the early days the International Standardization Organization (ISO) standardized the C language, and also supplied a test suite to verify the correctness of a compiler implementation. This was a large suite of small test programs that cover all features defined in the ISO-C standard. However, each feature was verified in a shallow way. In the 1990's the ISO stopped the development of verification suites and companies such as Plum Hall and Perennial took over. Today these test suites are very mature, are used by virtually all compiler vendors, but still apply the same test approach. In this period there were no real innovations.
Suddenly in 2011, a clever PdD student at the university of Utah developed a new way to test compilers. He created a method to deeply test all corner cases in the optimizations applied by compilers. This moment became a bit humiliating for some in the industry. Although compiler construction is a mature engineering discipline and compilers are typically more reliable then the software that is being compiled this new test approach revealed many issues in all compilers of all brands. This event caused the industry to put more effort in increasing tool quality and stability.
The success of this student, now associate professor in computer science, inspired many others to also do research in compiler verification. Whenever a new test approach is introduced, we, and everyone else in the industry, have a quick means to compare the quality of our products with our competitor's products to see whether we comply with today's state of the art.
What can you do to further improve the quality and stability?
Process improvement is an important topic. However, testing combined with process improvements – when applied to extremes – is not cost efficient and still doesn’t guarantee that your product is perfect. At the moment we are doing experiments with formal verification. We are now at a stage where we have a prototype where we can guarantee, with a machine checked mathematical proof, that the register allocation phase of our compiler is correct. That is one of the few real innovations in compiler technology that I see at the moment.
Being compliant with current Functional Safety Standards is always one of the major concerns for pretty much every supplier in the automotive industry. What are your priorities in that area?
First of all the work processes applied in the organization must adhere to ASPICE compliance level 2. All safety standards, no matter whether it’s ISO 26262 or DO-330, required that all software development takes place in a "managed" environment.
Second, we have all information, aka evidence, available that is required for certification, and we must have the systems in place to efficiently pass that information to our customers when they need such information during their certification efforts.
Third, automotive components have a lifespan of more than 15 years. If after 10 years some modification to the software should be made, it is not an option to switch to the latest and greatest compiler version. Instead our customers want support on legacy versions and we must have the systems in place to be able to rebuild old versions of a product, make modifications to it, and deliver a slightly altered version back to the customer. As a result our customer’s costs for doing the qualification or certification of their product is far lower than it would have been if they switched to a new compiler.
I know that you offer an ISO 26262 support program. Could you tell me a little bit more about this approach from your end?
We offer two cost and lead-time efficient solutions to help customers achieve certification against ISO 26262 and other safety standards.
We supply a compiler qualification kit which enables our customers to qualify our tools in their work environment. Tool qualification is not a generic issue; it must be done in the context of the use cases as applied at the customer’s site. The qualification kit contains a safety manual that describes how to configure and use the toolset in safety-related projects. The customer also gets access to our problem reporting and bug tracking database which contains all issues found by TASKING as well as found by our customers. This system is updated on a daily basis and is accessible via the internet.
In addition we provide professional services to help our customers with the certification process. For ISO 26262 the qualification kit typically provides all evidence that is required by the certification authority. Customers can use our services for qualification against other, more stringent, safety standards.
What does the future hold for TASKING and Altium, any new updates of tools to be expected for 2015?
Just very recently at the ‘embedded world 2015’ in Nuremburg, we announced our compiler for the Bosch GTM-IP MCS Version 3, which is a timing processor that will be incorporated in microcontrollers of various silicon vendors. Version 3 of the GTM-IP MCS is the first version that comes with a C compiler, the necessary adaptations to the instruction set architecture were made by Bosch in close cooperation with TASKING.
Thank you for your time, Mr. Vink.
Gerard Vink accompanied the evolution of TASKING from almost the very beginning. Being the Head of R&D he is responsible for compiler and debugger technology. Gerard Vink studied mechanical engineering and computer science. Before joining TASKING in 1988 he worked on MCAD and computer animation software. During his more than 25 years at TASKING he witnessed microcontrollers evolve from simple 8-bit cores into complex heterogeneous multicore systems, where the complexity of compiler and debugger technology advanced accordingly.