FEATURE EDA
CHOOSING THE RIGHT TOOLS FOR THE JOB
Tool chains for embedded software development are changing in response to mounting complexity. Anthony Pellerin, Director of Technology, Witekio, explains why choosing the right software tools for the job is now crucial to project success
T
he mass market adoption of technology is enabled by one
important aspect; simplicity of use. The simpler something is to use the more likely it is to be adopted. In electronic devices, complexity on the surface will often mask complexity underneath and the gap between these two extremes is only getting wider. Of course, complexity doesn’t only exist
to make the end user experience simpler. The draw of the IoT is putting pressure on OEMs to integrate connectivity at the device level and complement that with corresponding services in the cloud. This represents an increase in complexity for many OEMs. However, the evidence points towards a business landscape that relies less on hardware and more on services. The term ‘As A Service’ is now applicable in many vertical markets that, not so long ago, would have been dominated by the development and supply of more conventional ‘hardware’ based products. This means that software development
for OEMs is no longer restricted just to the embedded domain and as consequence it is becoming necessary for those OEMs to adopt tools that address this new and challenging paradigm. Fortunately, many of the tools in question already exist in the enterprise sector, along with the methodologies needed to make use of them. While these may at first be unfamiliar to manufacturers in other sectors, such as industrial, medical, automotive and consumer, the need to manage software complexity is undeniable. Software development now starts at a
much higher level of abstraction. For example, the use of tools based on UML (Unified Modelling Language) allows systems to be modelled in detail before any low-level development work starts. And this effort isn’t wasted; tools such as Visual Paradigm (which can be integrated into popular and more conventional IDEs including Eclipse and NetBeans) support the automatic code generation of source code in Java and C++ from UML models.
18 JUNE 2017 | ELECTRONICS
recognised coding standards such as MISRA are growing in availability. So too are tools that manage revision control of different branches of software. This is becoming more relevant for OEMs that produce more than one version of a product, for example. One of the ways in which software
complexity is being addressed across all vertical markets is in the use of Frameworks, which are intended to support further software development. In the embedded sector, semiconductor
The use of automatic code generation
tools in the embedded space is, arguably, still the exception rather than the rule. But it is gaining support, as it is an effective way to address complexity. It is also becoming less imperative to optimise every single line of code in an embedded application, thanks to the continued increase in affordable processing power. It is also true that IDEs are, in general,
becoming more comprehensive and capable. Many will now support Static Analysis, which checks source code against coding standards to help ensure a consistent development style. While this is no guarantee that the code will be bug- free, it is recognised in many industries as a way to develop code that is inherently easier to debug and maintain. More software is now sourced externally (again, to manage the complexity of development) from either open-source projects or from semiconductor manufacturers. Often this code is provided without support, so while it is a solid foundation for application code, it does little to alleviate the integration process. Tools for analysing source code against
Figure 1 (top): Capture WEC7
Figure 2 (above): QtCreator40
Choosing the right tools for the task has always been important, but as the definition of the task changes and grows to include more connectivity, analysis and control it will become more important to ensure those tools are not only suitable but able to work collaboratively, with the minimum of configuration
manufactures are adopting frameworks in a way that builds on existing ecosystems, to include more elements of software such as operating systems and middleware. Frameworks provide an environment of pre-integrated and pre-verified software components that support the manufacturer’s processors. While such frameworks may limit the choice in software configurations, it can reduce the development and integration challenge and as such can significantly accelerate product development cycles. Another change in the way software is
developed and used relates to cloud services. Software can be developed using tools that reside only in the cloud. Virtual machines can be leased by the hour, to host development tools running on server blades that provide the processing power needed to develop, debug and virtually run application software. This is perhaps the most impactful and
disruptive change happening in software development, one that isn’t limited to the embedded domain. The use of cloud services to augment hardware is now pervading all sectors. The Industrial IoT (or Industry 4.0 as it is also known) will make greater use of cloud based services to provide remote monitoring and predictive maintenance, using machine vision and deep learning algorithms that are simply too resource- intensive to run locally.
Witekio
www.witekio.com T: 0117 369 0932
/ ELECTRONICS
Another way software is developed and used relates to cloud services
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44 |
Page 45 |
Page 46 |
Page 47 |
Page 48 |
Page 49 |
Page 50 |
Page 51 |
Page 52 |
Page 53 |
Page 54 |
Page 55 |
Page 56