Syftet med kravautomation och processen är att driva utvecklingsarbetet framåt så att “rätt sak” byggs från början. På köpet får vi en gemensam, delad förståelse av vad som ska byggas och när vi väl har automatisering på plats får vi dessutom en “levande” dokumentation som vi kan lita på och som beskriver systemets aktuella beteende.
. A test platform is simply a platform with a special purpose – to test something. Let us try to define two kinds of platforms:
- Software Platform – A software environment to write applications and run them.
- Hardware Platform – A set of compatible hardware on which software applications can be run.
Choosing the right platform solution is not easy and may be a combination of both software and a hardware platform solution and it is obvious that one size does not fit all. But why use a platform at all? Since the platform concept is widely used, there must be some benefits that is worth investigating.
Why a Hardware Test Platform?
- Cost effective – reuse of hardware resources
- Reuse software modules – reuse of hardware dependent software
But there are some drawbacks that need to be considered:
- Hardware interface – typically there is an exchangeable part of the hardware platform that can be replaced with an interchangeable fixture. This interface is typically a large connector of high quality, but this connector is usually quite expensive.
- More resources than you need – since the hardware platform most likely should support future product, it may contain resource that is not needed for the moment and might never be used.
- Longer physical signal paths – since hardware resource is located in a common part of the station, and test object is typically placed in a fixture, the cables and thereby the length of the signal paths might be increased.
Why Not a Hardware Test Platform?
- Simpler – a non-platform solution typical is designed simpler and only contains the resources needed for a specific test object. No need to plan for future products using the same test hardware.
- Short physical signal paths – resource may be placed without any consideration of reuse and replaceable fixture and typically ends up closer to the test object.
Why a Software Test Platform?
- Reuse of code – the most obvious reason of building a software platform is the reuse of code. Instrument administration, configuration and result management are software parts that typically are the same for all system.
- Faster Development Process – Less new code to develop and usually easier to introduce new team members to a new project who is already used to work with the software platform.
- Extendable – a software platform typically has a well-defined interface for extension plugins and also usually has a high level of flexibility for changes.
- Documentation – if there are many users, documentation may be reused and then actually also be written.
But as with the hardware platform, there is some drawback with a software platform:
- Increased complexity – mechanism for especially extensions causes more advance programming like object-orientation, callbacks or other software technics that requires some software skills. It might also be quite hard to know how to do things correctly.
- Endless configuration – since the software platform may need to support many different hardware solutions, there is need of configuring the correct setup of hardware resources that might be quite complicated.
Why Not a Software Platform?
- Simpler coding – since the software is written for only one particular purpose, there is no need for complex mechanism like object-oriented solutions like abstract classes, callbacks and is it much easier for a non-skilled programmer to use.
- Easier to maintain – if it is easier to understand it is usually also easier to maintain at the beginning.
Lessons Learned – to platform or not to platform?
To platform, or not to platform, that is the question. As always there is no simple answer, but there are some important aspects that might help.
- Maintenance – who is going to maintain the test platform? Is it easy to make changes if a new test object or variant should be added? What kind of skills is needed?
- Loose coupling – how easy is to reuse the platform in another project and only retrieve the parts that are actually needed in the new project? Dependency Injection in object-oriented software platforms is a powerful mechanism to achieve loose coupling.
- Design for the most common scenario – do not try to make one size fit all, keep it simple!
- Too simple solutions – if the platform is too simple, it typical lacks the flexibility to deal with later changes and it may end up being a mess of workarounds and patches.
From my experience, building a successful platform is more about making the right trade-offs than it is about best technology. Good luck!
About the author
Mattias Ericsson is a system architect who always wants to be one step ahead. He thinks that one of the most important things to do for a successful project is to do right from scratch, by asking the right questions and by never guessing or assuming.