Software Development Tools for the Whole Development Cycle
What's Wrong With the Typical Project Development?
Teknic has more than a casual interest in improving our customers' time to market. Teknic supplies machine automation products exclusively to OEMs. We sell products at volume prices even when an OEM is only buying prototype quantities, plus we only use non-commissioned, factory-direct application engineers instead of manufacturer's sales reps and distributors. This business model is very expensive during the development phase of a project, so we rely heavily on our OEMs' ability to bring a project from concept to market as quickly as possible. Because of this, we decided it would be very helpful to know what the impediments are to bringing an automated machine to market quickly and reliably. So, a number of years ago, Teknic commissioned a study to determine just that.
We found that although the exact lengths of each development phase vary quite a bit from project to project (and market to market), an analysis of dozens of projects revealed a surprising degree of similarity in the sequence of the various development phases. The project cycle of an automated machine (see below) starts with concept development and almost always goes next to the design and prototype development of the electromechanical subsystems. These subsystems (or functional modules) get some rudimentary testing when they arrive from the prototype shop and then get integrated into the overall machine. It's somewhere during this integration phase, after most of the electromechanical design and integration has been done, that significant software development begins. Further analysis of the implications of this sequence was quite illuminating. At the risk of a little oversimplification, our clear conclusion was that one of the main problems in automated machinery development is that software design and coding begins too late in the project cycle.
Why is this? The main reason is that the software development requirements in the beginning of the project are significantly different from those in the middle and end of the project. But, the tools for writing code for automated machinery that come with machine automation products (e.g., motion control cards, etc.) are geared nearly exclusively to the needs of the software engineer during the core application development phase of the project (i.e., the middle of the project). These tools are not well suited for a number of important tasks before and after that phase, nor are they generally suitable for use by anyone other than experienced software engineers. These shortcomings have significant negative impact on the efficiency and risk of the project.
The first problem is felt by the mechanical and electrical engineers who are looking to test their newly delivered electromechanical prototypes prior to system integration. To do this effectively, these engineers need software to run the module in a way that closely mimics how it would run in the integrated machine. Unfortunately, most machine automation products and software tools don't lend themselves to this; they require a large software infrastructure to be created prior to being able to write any useful code. There are no software tools optimized for use during this early phase of the project. In almost all projects Teknic analyzed, this problem precluded the mechanical and electrical engineers from doing any significant testing of their modules prior to the start of the core software development. This meant that the electrical and mechanical design problems that inevitably arise at some time in the development, tended to surface relatively late in the project as the core application started to really exercise the system. This not only caused redesign at a later stage in the project, which is always bad, but to make matters worse, mechanical and electrical problems uncovered at this stage also interfered with the software engineers' ability to write the application code. This led to time lost along the critical path of the development and the inefficient use of resources. It was also very frustrating to all involved.
The collateral damage of this time lost is that software engineers come under tremendous pressure to deliver more code faster. This leads to software with an excessive number of bugs late in the development. Furthermore, anything that's not related to the development of the core application code gets pushed aside. The development of test and debug code, as well as production test code frequently gets compromised. Understandably, this important software gets eliminated or severely scaled back to keep the core software development from slipping further. Of course, in the end, there's a price to be paid for this, and it's usually in the form of significant problems in early-stage production and "beta" releases to customers.
This basic pattern of problems related to the late start of software development repeated itself (to more or less a degree) in nearly all the projects we examined—surprisingly, even in the successful ones.
How Does ControlPoint Solve the Problem?
Armed with a clear understanding of how the development of an automated machine project progresses, Teknic designed ControlPoint to address the problems caused by the lack of phase-appropriate development tools. ControlPoint comes standard with three complimentary software components. In addition to offering a rich, full- featured suite of tools and software for the core software application development—ControlPoint's "sFoundation"— ControlPoint gives you two other potent development tools. The first is a graphical Control Panel application for quick and easy control of system motion, I/O and other functionality without the need to write any software. The second is a powerful Script Development Interface (SDI) that gives users—from technicians with a little bit of basic programming knowledge, to expert software engineers—the ability to quickly write software in interpretive Visual Basic for controlling multi-axis machines with I/O. The SDI affords users the power and debugging tools of Visual Basic, and is actually even easier to use.
These two tools are geared toward the test, evaluation and refinement of early electromechanical prototypes and other technology designed prior to the start of the core application software development, and to the development of production test code. Collectively, the Control Panel and SDI tools form ControlPoint's "Rapid Prototyping Environment" (RPE). The RPE combined with ControlPoint's sFoundation core application development framework, gives you a powerful toolkit for completing automated machinery projects in significantly less time and with higher quality than ever before possible.
