Our previous posts related to the topic of application software discussed how the operation of Danfoss Drive’s products can be customized to suit customer processes simply by tailoring the software. And how customers can have a role in this software development, either directly or indirectly. This post goes a little deeper into the fine points of application software development, as it may be a somewhat unknown area to most readers. More precisely, we will discuss what is expected from the Application Software Developer rather than the actual technicalities of software development.
An Application Software Developer must have a certain knowledge of electrical, automation and software disciplines, as the task involves working with electrical equipment (drives, grids, motors/generators and all surrounding auxiliary devices). He must also have the ability to recognize how the Danfoss Drives products can be incorporated, using software, into the surrounding automation system and process itself. Of course, it isn’t a critical prerequisite to have a background in all of the fields right from the beginning. The necessary know-how on, for example, electrical aspects can be learned on-the-job.
As the function of the Application Software Developer is to customize a product’s operation to a customer process, the developer is a natural participant in any customer meetings regarding the technical aspects. The role that the Application Software Developer can play and the input he can give depends, of course, on his expertise on the subject matter. It can range from being a mere ‘listening student’ to a system-level expert who can point out possible problems in the design and known issues that need to be taken care of by the customer system. He can even identify how certain functionalities the customer wants may not exactly be what he needs and present his own solutions.
Design, development and testing
The application-software-design process naturally starts already in the first meeting regarding the technical aspects. And it culminates in a Functional Requirement Specification document that can be approved by the customer if deemed necessary. Development is carried out in an IEC 61131-3-standard-based PLC programming environment which requires knowledge of the PLC-like system’s special aspects, for example cyclic and special tasks.
Testing can be the most interesting phase as it is at this point that the application developer must build a test setup that emulates as closely as possible the customer’s target system. All VACON® products are inherently scalable, so emulating operation of a megawatt-level system can be carried out using kilowatt-level equipment. And, as the control boards are the same between all size-class products, the same software works the same way in all products.
Commissioning, and field use in general, are very important aspects of software development. Their importance for the developer’s own and for the application software’s development shouldn’t be overlooked. Only then is the developer capable of getting actual first-hand experience, and can see how the application software can be enhanced even further. I have personally always asked how an engineer can possibly develop good products to be easily and reliably used in the field, if he himself never goes in the field and uses the products himself? There might be people who are able to do that from their office desk; but my opinion is that any and all developers, especially application software developers, have to go to the field at some point and actually see the outcome of their work in its ‘natural environment’.
Software maintenance involves changes to the software in the form of new functionalities and bug fixes. If the software in question is customer-specific software, it makes the changing of the code less stressful as the developer does not need to worry so much about breaking some functionality that another user may need. Adding special new functionalities to commonly used application software that is used by many different users makes the changes much more challenging and time consuming. One prudent action in extreme cases can be that the user is instructed to use another software which has almost the same functionality and the change is implemented there.
For some developers, bug fixing can be quite an interesting job. As the Application Software Developer is often working with, for example, rotating motors in part of a large system like a paper machine, additional spice is brought to the role as you cannot just stop the process to check what the output of some function was. Alternative methods have to be used for debugging than those that are available, for example, in PC software development, like simultaneous online monitoring of multiple drives/inverters and dataloggers triggered by some predetermined events. Depending on the developer and the case in question, bug fixing can sometimes be a straightforward process of finding the typo and fixing it. But, on the other hand, it can be described as completing a jigsaw puzzle depicting an action film (sometimes with real explosions) where the puzzle parts are just very small portions of still frames recorded with a colorblind camera which is not necessarily pointing at the action!
This has been a small and limited peek into the duties and responsibilities of Application Software Developers. I hope that it gives an idea of what is expected from you if you want to apply for an Application Software Developer position or you are thinking of taking over Application Software Development for your own company. Both options are very welcome to Danfoss Drives.
Check back regularly with us here at FocusOnDrives.com for regular updates on the best ways to ensure that your investments in AC drives are always fulfilling your process requirements. And let us know in the comments how we can use our extensive application expertise to help you.
Author: Timo Alho, Product Manager, Applications, Danfoss Drives