Linked by Thom Holwerda on Wed 5th Jan 2011 22:09 UTC
Thread beginning with comment 456492
To view parent comment, click here.
To read all comments associated with this story, please click here.
To view parent comment, click here.
To read all comments associated with this story, please click here.





Member since:
2007-02-17
I didn't say I was a Software Engineer, I am a Systems Engineer.
http://en.wikipedia.org/wiki/Systems_engineering
Software is but one part of a system.
The type of systems my teams engineered are Cockpit Procedures Trainers (CPT) and Flight Training Devices (FTD). These indeed take a number of years to build, and there is much blood, sweat and tears to go into it. A decent FTD may use as many as twenty PCs to drive various simulated cockpit screens and the outside world visuals and other player tactical simulations.
http://en.wikipedia.org/wiki/Flight_simulator
This represents a bucketload of software and hardware all integrated together into a complex system. It is actually more complex than the aircraft being simulated.
Perhaps this might give you a feel for the scope of such a project:
http://www.cwu.edu/~aviation/facilit_simlators.html
Having said that, a full-feature A grade movie takes just about as much effort, and that venture is protected only by copyright.
Anyway, back to software ... if one's team had to write the entire software from whoa to go, it would be impossible (the final software deliverable occupies about 20 CDs, and even that uses common components such as the same OS on most machines). The airframe would reach end of life before the simulator on which to train the pilots was ready.
The best approach to providing software for a complex system is to use as much as possible of what already works and is proven.
For example, for the outside world graphics subsystems, we sometimes used this solution:
http://real-time.ccur.com/solutions_businessneed_imagegeneration.as...
The point is that even though this solution is based on open source, we still paid for it, and we still paid about twenty software engineers to integrate with it and write aircraft-specific parts of the FTD software, and it was still part of an overall engineering solution, and money was still made on the deal by both us and Concurrent. To re-use open source solutions for components of the overall system was better for us, better for our customer, better for the whole life-cycle cost (including software maintenance) of the solution because the customer got all the source code, and we got the FTD product out the door at about the same time as the real aircraft was first comissioned.
Where is the problem?
Edited 2011-01-08 12:46 UTC