Agreed, Mr.Acharya, the com style depends on the organization. The bridge document between hardware and software for the Command and Control Processor on the "International" Space Station was written in PowerPoint. In a series of about 20 such documents, the chief engineer described how he expected the hardware and software to interact, subsystem by subsystem. We followed the document, and when questions arose, we could just ask for clarification. It worked. And it didn't involve mediation by the system engineering clergy, or $60K/seat "requirements" CAD tools.
Another lesson learned (or addendum to #2 in the document) could be a well set-up communication process between the hardware and the software team. The communication style mostly depends on the organizational structure and in this case since the hardware & software teams do not share the same reporting authority, setting-up an inter-team communication process is essential. A hardware-software integration requirement document or something like that generated by the software team and then reviewed and approved by hardware team would have been helpful in catching the miss-outs.
My career centered around automatic test equipment for twenty years, one foot in hardware and one foot in software. I once asked a question in a meeting and heard a yes and no at the same time. I told them that it did not matter what the answer was, but that both of them had to say the same thing. He said, she said, and then I said.
Regarding an unplugged device not giving any errors, even worse is when unplugging something causes a crash of the whold system and you are unable to report an unplugged device condition.
The reason for the divide between software and hardware is that the two are so very different. Those who are able to write good code based on a set of complete requirements have a quite different skill set from a design engineer who knows how much power each section of the circuit must deliver, and how much it will consume, and what signals must be protected from other signals. IN short, there are two completely different skill sets, and the few folks who are in possession of both are quite valuable, and therefore probably quite expensive, if they are any good. The higher price assures that many managers will seek to avoid having many with both skill sets around.
There's another lesson here. If your design has a means for detecting errors, then your design must also provide a means for generating those errors, so that you can tell if your detection scheme is working. It's amazing how few designers get this right, until after they've shipped a system that did not. (I'm not one of the few; I had to learn this the hard way.)
Even if you have decent requirements, there are other pitfalls. I worked for MITRE once upon a time, and was hired by NASA to review a contract for a very large software configuration management system. The aeorspace contractor wanted to build it themselves for $50K. We thought this was just the usual loss leader... I found out that one of the commercial CM systems had 250K lines of code: no one was going to duplicate that for $50K. Needless to say, with that little bit of research my popularity was rising on one side of the fence, falling on the other. Next, the contractor had a meeting with NASA with me present to explain just how wonderful their extras were going to be. After about the third time the contractor explained "we don't have that in the requirements" in response to a NASA question, the woman in charge for NASA leaned over to the contractor's requirements manual. She flipped about 4 or 5 pages, and announced: you only have the odd pages of the requirements document. It was hilarious... although I managed to keep a straight face. Make sure that you have decent requirements, and while you are copying them, do it both sides...
As daunting as this scenario may seem, I believe it is all too common in the hardware and IC design sphere. I am interested to hear what method was used during development? Instead of head down mode, I want to add another tip...which is to follow Agile development methods and for a program manager and project manager to require daily scrum meetings so that hardware and software work together to make decisions about what and how requirements can be met within the project scope. In addition, real-time communication should happen when both hardware and software teams analyze the requirements document. The marketing team should also be alerted about the outcomes of these team analyses to ensure clear communication on all fronts. Prototyping and modeling should also be evaluated. There should be multiple safeguards to this process (not Waterfall) to ensure that the team's excellent efforts are not wasted or held back because of either poor decisions or miscommunication.
I have witnessed the hardware / software divide my self over many years as a EE. I can't help but think part of the separation arises from there being both a hardware development group and a software development group as separate structures in most companies. This just reinforces the lines of separation. Perhaps, it would be best to develop products with an integrated team from the beginning as this would reinforce the team approach. I am also wondering why there was a “loss of optical signal” hardware alarm bit designed in if it was not in the requirements document for the product?
Strange this still happens today.
It depends how the engineering team is composed and managed.
Usually there is an embedded team engineer/manager who can manage software and hardware, or bridges both domains.
A department without an embedded expert usually runs into problems.
In fact, more companies today start to cut on pure software guys, and shift more effort on embedded (cos these are the best guys who can do RF, analog, digital, MCU and practically like a multi-purpose commandos)
I find it a little funny the hardware engineer calling out that the software engineer may not read a page in the functional specification, but never calls himself out for not reviewing the software requirements specification. By doing this, he could have discovered the oversight early and pushed for his feature to be covered.
I also find the us vs. them tone of the whole article disconcerting. It's not hardware vs. software, it's a team putting together a product. By watching each others backs in a team effort, issues will be found earlier and fixed faster.
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...