Initial software development can be tested on development or evaluation kits that allow you to easily connect different devices to the processor you’re targeting. Some boards contain buttons and LEDs that allow you to test simple user interactions, such as turning Bluetooth on and off via a button press.

These prototyping kits allow you to develop and test code quickly, ideal for both proof-of-concept work and full product development. If software is developed on a development kit, it means that once the custom electronics are ready there should be less work required to get the product finalised, reducing overall development timescales.

For our SmartBell, the electronics engineers are developing the custom PCB for the product, the software engineers can use the development kits to develop communications between the app and the device, along with getting data from a connected accelerometer.

Software is deterministic – if you give it the same inputs with the same timings it will behave in the same. This can sometimes lead to a view that software does not need to be tested, which is incorrect. Software should always be tested in some manner, with the level of testing being determined by different factors such as the complexity of the software and if the software poses any safety risks.

Software testing can be performed at differing levels of detail.

• At one end of the spectrum, we have unit tests that look at the smallest components of software, checking that individual functions give the correct output for given inputs. Unit tests can be automated and run when any changes are made to the software.
• At the higher-level we can perform system tests that look at all the software modules in the product and how they interact with users and other external factors. System, or integration, tests can also vary in their detail. A daily smoke test can be a short procedure which is performed each day to make sure the product maintains basic functionality; a tester has a written procedure they perform with expected results from each action.
• A full Design Verification Test would include testing the device against each requirement (remember in Part 1 we said requirements should be testable), and would have a given test procedure, criteria to pass a test, and accompanying evidence to show it passed.

An example of a unit test for our SmartBell would give a pre-defined series of accelerometer data (not live data from the accelerometer) and make sure the direction function correctly classifies the direction. A step in our smoke test procedure would check that the device connects to the phone app. An item in our Design Verification Test plan would perform a series of bicep curls and check that the accuracy stated in the requirements is achieved.

So the software has been designed, coded up, and tested on your chosen platform. The next step is to get it out into the real world. A first round of releases can involve simply generating the executable files and programming them onto your device, PC, or phone. However, the first release is rarely the end of the software development process. In most cases, new features will get added into your product as time goes on and you may want to fix defects that weren’t visible until the software was released. In this case, you need to keep in mind how the device is to be updated in the future (another item for the product requirements).

Update procedures can involve sending the device back to the factory for reprogramming, or can be done by the user as a field update. Field updates may be done over USB from a PC, over Bluetooth from a phone, or directly over the internet for internet-connected devices. Regardless of the method of updating the software on your device, it is important to be able to work out which version of software is on the device. If you have multiple versions of your software available it can be very difficult to work out how to fix a problem with the device. This can be done through assigning a unique number to your software release and making it “visible” in some way.

For our SmartBells, we would allow the phone app to get updates from the Google Play or Apple store, and the device firmware can be updated via the app using Bluetooth. We can display the app version on an “About” page in the app. The Bluetooth Low Energy specification defines a Device Information Service which can be used to broadcast which version of software is on the device, amongst other pieces of information.

Software development can be a complex process, but don’t fear, i4PD's experienced team is here! We can support your software project at all levels, from simple proofs-of-concept up to fully developed, medical products with complete design and verification documentation. Our software team work closely with our inhouse electronics engineers for fast product development but can also help with updating software on your existing electronics platform.

If you’ve got a new product or idea you would like to develop, book a call to speak to one of our experienced engineers who can help bring your ideas into reality.