That's garbage. Systems engineering is looking at the system as a whole. Software engineers are dealing with the software in the environment defined by the system engineers. Sure, system errors may be found when testing software, but that doesn't make them system engineers.
Yeah, so if the bulletin said it was caused by gremlins...
No, I would expect it to be what it is.
Non sequitur. The systems level engineers should have considered the possibility of the concurrent application of ignition and brake. They didn't. The software has *no* control over the application of the ignition or the design of the hardware.
I don't know where you've worked, but even the place where I worked that _did_ have people with the job title "systems engineer", and even when the term started to mean "people who dealt with the whole system" and not "smart, necessary people whose work we don't understand", they didn't get down to that sort of nitty-gritty level. Maybe in some ideal world the system engineer's job is as you describe, but here in this universe the people who need to insure correct operation at that level have the word "software" in their job title, not "system".
I know that anywhere that I've worked, and for every client, if there's software that's capable of twiddling the pins on the board in such a wise that a motor is left on until it burns up, that it is damned well the responsibility of the person writing that software to damned well make sure that that motor does, indeed, not burn up, ever, under any circumstance except for the electronics faulting. And if it did happen, saying "oh, it's not my job to make sure my software doesn't burn up the motor that's at its mercy, that's the fault of the system designer" would earn someone a place on the short-list of People to be Laid Off First, if not a trip straight out the front door.
--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com
If the software engineer doesn't know the motor will burn up, is it his fault? It is the system engineer's responsibility to define the operation of the system as a whole including the interaction of the parts. As I have said, the environment must be defined for the software engineer and that is called systems engineering. We aren't talking about something that can be read in a data sheet. From what I have read this bug is complex and involves interaction of various parts of the car, the designers of no one part have known to prevent it. It was a systems level design goof.
If an embedded software engineer doesn't know that leaving a motor on, in a stalled state, for an extended period of time, will burn it up, then he/ she needs to learn their business a lot better.
I agree that there was a failure of systems engineering here -- but keeping stuff like this from happening is everyone's job.
--
Tim Wescott
Control systems, embedded software and circuit design
I'm looking for work! See my website if you're interested
http://www.wescottdesign.com
You can pick any isolated example and say someone should have a priori knowledge of it. The *important* point is that important interactions of the hardware have to be specified at the systems level in order for the lower level sub-systems to be designed. *That* is the critical aspect of designing any module, having proper specifications. A car is such a complex system these days and no one, including the systems engineers have a *full* knowledge of the entire car. Proper program management is essential to designing cars that work.
That's a beautiful dream, but, while it wasn't often, it was more than once that I had to cobble together a feature (yes, with inadequate information and imperfect control) that the designers upstream had decided it would be easier to sluff off. So there I am, retro-designing the system to see what's available at the taps I can get at to do what needs doing. Musikmesse two weeks away and me the only one who can change anything at all in that timeframe.
When it's too hard for hardware, give it to software.
Because there will be things about systems issues that software people will be the best at.
Example: I once worked on a system where there was a throughput "shall". We had a board. I "proved" the board would not support sustained rates required because of one of those fine Marvell Ethernet chipsets.
I would have used a SmartBits but they wouldn't buy one, so I wrote test drivers, with instrumentation (counters) accessible by Telnet/SSH session. These were roughly proportional to RFC1213 style counters. Please note that the RFC1213 counters provided by the system didn't work. It didn't have any way to estimate dropped packets because of the chip's architecture.
Then I wrote a Tcl script to put snapshots of this instrumentation into Excel. Easy peasy.
This took approximately three man weeks.
There was no "systems engineer" there that could have even gotten started on that task - note that a SmartBits was considered superfluous.
"Systems engineering" was nothing more than a career path to "program management".
This is key: The organization itself *didn't want to know*. They didn't care if it worked. They cared that there might be a contract award.
I don't work there any more. It continues as a confederacy of dunces. If they made things that worked, people would have negative career impacts.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.