Hello, I couldn't find a single newsgroup to post my question, but I needed a good group of people to post my question to. So let me apologize if you don't think should be in your newsgroup. My question is regarding the value (or importance) of System Engineering practices in the R/D World. I work for the government and there are about 40 people in my branch. We do a lot of R/D projects as well as projects for the testing groups. I would like to know from people in the R/D world how important do you feel System Engineering practices are on your job? Many of my co-workers say, "oh that's for really big programs, we don't do that hear". Do you agree? Some believe System engineering only pertains to the integration of the pieces of the design. To me that is only part of SE, there's so much more. Without being long winded, can those who work in the R/D world, could you please give your opinions of SE in your workplace? Is it important or a waste of time? What practices do you feel are necessary? Is SE only for the production people? I appreciate any responses and hope I don't offend anyone for posting my question. My intention is to gain enough information to convince my coworkers to use some of the SE practices I've read about.
In the companies where I've worked, and in most other companies, if no one knew exactly what you did but they knew you were valuable they called you a "systems engineer". Some of these people ended up either doing or coordinating the design tradeoffs between hardware, software, mechanical, etc.; others couldn't engineer their way out of a paper bag, but were good for dealing with certain esoteric problems that required large brains.
So you'll have to define "systems engineering practices" for us.
In most places where it needs to be done the design tradeoffs between disciplines that I'm speaking of tend to be done by the project manager, or they happen by committee, with electrical, software and mechanical engineers getting together and hashing things out. If the project manager is smart and/or if the committee gets together well then this can make for some very good systems designs. Unfortunately it's a chain that's weaker than its weakest link, so you have to be careful.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
Hello, to be brief SE involves requirements analysis, risk managment, controlling your design processes, interface control, supportability, realiability, maintainability, reproducability, peer reviews and technical reviews, test planning, integration planning. SE is used to manage a project to control costs, schedule, and performance. I"m still learning all the areas and probablity left out a ton of stuff. Although, I'm more interested in the technical side of SE, rather than counting the money stuff.
What is "System Engineering" anyhow? If you mean someone who plans high-level designs without detailed knowledge of the underlying technology, my company certainly has nobody like that, and my customers, gigabuck big-science projects and aerospace companies, don't seem to either, as far as I can tell. The people who do the highest-level thinking, the grand architectures and the new ideas, seem to be just the best of the technologists.
I think the bigger the project the more you will need systems engineers, in smaller projects the typical system tasks (requirements definition, interface specifications, trade studies, test plans procedures, spec compliance verification, test equipment integration, debugging high level field integration problems) usuallly are integrated into the software/hardware engineers work schedule. If you tried to force the creation of a systems engineer position is a small project you probably would need to create unnecessary busy work to keep him/her employed (forcing the generation of unneeded documents). As projects get bigger these functions are too much for the software/hardware engineers to support and the creation of a formalized system engineering function becomes necessary. The majority of systems work is customer/production related, so R/D has much less need for dedicated systems people, just my opinion.
It's just a cynical observation that the stupidity of a group can be equal to the sum of the stupidities of the participants.
I have seen this sort of design by committee go both ways, so I shouldn't be cynical. If the group is aware of the pitfalls and not afraid of constructively criticizing each other's work then the results can be superior to what any individual could do by him/herself. If, however, the group has even a few jealous empire-builders then the effort tends to collapse upon itself.
Similarly, if an insecure project manager does the systems engineering then the system design will often be bounded by the project manager's limitations plus the limitations of the group. If the project manager isn't afraid of other people in the group knowing more than he then the system design will be strong everywhere that anyone in the group is strong; if the team's _really_ good they'll recognize their weaknesses and either change the design to avoid them or get external help in those areas.
I've been named "system architect" on more than one project, and I've always been profoundly grateful to the folks that have caught out my errors. I always let folks know this, too -- and not just the folks finding my errors, but their managers as well. At worst the equation goes like this: I do something stupid, you notice and don't say anything; we both look bad. Alternately: I do something stupid, you point it out, we both fix it; we both look good.
The best thing about this attitude is that it is one of the areas where, with the right PR, ethical behavior and selfish behavior march hand in hand. When I can say "Ralph found an error in my system design, I did some analysis and found out that my integrator wasn't nearly deep enough for the modified filter" then the project wins because an error has been fixed, Ralph wins because he's gotten credit for finding a problem, I win because I found a solution, _and_ I win because an embarrassing problem with my design was found at an early stage instead of in front of some Major in procurement who really wanted to buy the competitor's product instead.
--
Tim Wescott
Wescott Design Services
http://www.wescottdesign.com
So where does the systems engineer fit into the organization? Who does he report to, who reports to him, and how much authority does he have? Does he have to sign off on stuff?
My experience has been that the best systems are architected by a single person, not by committee.
The EARLY Pentiums were architected by a single person. Need I say more ?:-)
...Jim Thompson
--
| James E.Thompson, P.E. | mens |
| Analog Innovations, Inc. | et |
| Analog/Mixed-Signal ASIC's and Discrete Systems | manus |
| Phoenix, Arizona Voice:(480)460-2350 | |
| E-mail Address at Website Fax:(480)460-2142 | Brass Rat |
| http://www.analog-innovations.com | 1962 |
I love to cook with wine. Sometimes I even put it in the food.
At least you can get some job when you somehow do plan these things, it would probably more useful with new people or an unexperienced work group. Many of the procedures fall now into different peoples responsibility, not everyone will react delightful when you take his tasks away. For the NASA it will be more beneficial than for a specialized nice-market company, that has simply not the money to pay another engineer sitting in his office. OTOH this is the ideal function for outsourcing to a consultant.
System engineering is not need if the design group all pee in the same urinal. Information flow is perfectly terminated with no reflected waves. Notice I did not say design team, they have leaders that don't comprehend the task. Oh, don't get me started! Harry
Hello, I didn't say that one project needs to assign a System Engineer. I'm only concerned that the individuals or project lead follow System Engineering practices. What I have seen where I am working, is that the engineer will get the requirements from the customer, then go off into his/her cubical, design the widget, and then deliver. Many times the widget doesn't meet the customer's requirements or a nightmare to program due to hardware limitations. Many of my co-workers say, we don't follow SE practices because our designs are small (their opinion). I'm trying to encourage them that you can apply some of the principles of SE, for me to achieve this I need to see what people in the R/D world are doing, are they using SE?
In my experience, folks who do R&D (which can mean differerent things to different people) tend to be messy desk types who prefer to live that way. SE tends to put some discipline in the process which can be good. There are things out there like being able to integrate matlab with tools like CVS that can help smallish groups.
requirements analysis - the system guru's job for the technical things which can be the whole thing - a marketing / engineering job to trade off feature cost / benefit. (Sales will want everything tomorrow). I've never seen the latter really work but it might in concept.
risk managment - what kind of risk? Market risk? Technical risk? Financial risk? Schedule risk? etc. etc. I've seen engineering risk analysis presented that included likely cost/schedule impacts and mitigation actions for the biggies. Only for larger systems. Silly risks are avoided by good engineering - like not choosing to use weird parts, avoiding tricky calibration in the design, etc.
controlling your design processes - isn't there a VP Engineering to set policy? Isn't there a way to communicate what's working and not working? It must be a really overdone project to need a *person* dedicated to this.
interface control - yeah, on really big, diverse developments. Otherwise a pari of drawings / specs just need to be coordinated and kept in sync. (I once worked on a project as a young engineer ... gee maybe I was the "system engineer" ... I was responsible for an autopilot - which, as you can imagine, was a major system block / module. The system was being built down the street by a large aerospace company. I got a call from a fellow who wanted to better understand one of the components that was used in the autopilot - so I drove over to discuss it with him. Lo and behold, the guy had *no* idea about how the component was being used in the autopilot - none. It was really hard to have a cogent conversation and was really hard to help him).
supportability - a worthy area of endeavor. Best done by someone who understands the infrastructure and the end-use needs where the product will live. Better be done up-front. Suggests the system guru again.
realiability - when the "system" is a single FPGA you are kinda stuck aren't you? Post-design it's nice to keep track of what's breaking so you might actually fix something. I can remember a lot of times when a customer would have a problem and somebody inside our company would say: "oh yeah, I remember that came up about six months ago" (and nothing had been done). It's nice to be able to try to decide what to fix and what not to fix before some system comes crashing down in the middle of a critical situation. Rarely affordable to have a "person" except in aerospace. Not to say that you can't design for good or bad reliability .... but a statistician probably isn't going to have much of an impact in the design choices unless you're going to spend a whole lot of time in meetings and to hell with the schedule.
maintainability - how is this different from supportability really?
reproducability - I think you mean produceability. Just part of good engineering with adequate discussion with the manufacturing folks. Not a special discipline / position.
peer reviews and technical reviews - part of process. No "person" needed.
test planning - sometimes a specialist can be helpful - particularly in software. In hardware it requires someone who really knows what's being tested - as in the system guru or the senior designers?
integration planning - the system guru takes the lead and, unless the guru does it all alone (which is common) then it's a group activity.
manage a project to control costs, schedule, and performance - AKA the Project Manager who is best also the lead engineer or some other effective manager - but not necessarily the system guru. Sometimes there can be staff support (in aerospace again) but it's not all that helpful to the real manager / management in my opinion. I always do it myself so the planning work gets done when it's needed and not just automatically because it's someone's assignment. "Tracking" to an original plan is a guilt trip except on very large projects where BCWP, ACWP etc. are used as indicators where figuring things out otherwise would be difficult. Above all, figuring out how to get from *today* to the end most efficiently / quickly is useful. (Presumably there is somebody who can recognize the situation and take corrective action if there are weak players - without resorting too much to the "measures").
And you didn't mention "performance measures". I may have had a bad experience or two but I've never seen a situation where "performance measures" were anything but mostly mindless obedience exercises. I'm told that some have great success stories (ala Deming, Juran, Taguchi...) but not me! This could segue into a discussion of general QC which I'd rather not get into..... If there were something akin to "system engineering" that might actually be useful to put some energy into, it could be lurking there.
To make a point: It is told that a Japanese company licensed the production of an American engine. They took the original drawings and began production. But they couldn't build engines with those drawings! Why? Because at that time, the Japanese built all the parts to exceptional tolerances so there could be virtually 100% interchangeability. And, because at that time, the Americans had built the parts to looser tolerances and were willing to do some mixing and matching of parts, they didn't recognize that the dimensions in the drawings were "wrong" - that is, a working engine could not be assembled out of a set of parts that were perfect according to the drawings. I don't know if the story is true but it's sure interesting.....
You hit the nail right on the head. That is what my work environment is like. No discipline at all. I'm trying to add some process control and not having much success with the older more experienced engineers. But, the younger engineers are very excited because following SE practices allows them to help manage complexity, which is good.
You can find some definitions and nice opinions about sys engineering here:
formatting link
P.S. If I were you, I would use more specific terms when trying to convince my colleagues to do something, instead of ambiguities such as "system engineering practices". Take software projects for example, terms such as CMM are a lot more well-defined and therefore more powerful.
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.