Hi. Welcome to Developing the Industrial Internet of Things Course Two. In this module, you will learn about what it takes to develop a process for designing, building, testing, validating, and shipping your product. You will come to see the importance that documentation plays in creating and running an efficient project. You will learn about how to build a bill of materials for a product, and in conjunction with this, you'll write a short paper after performing a product teardown. A great deal can be learned about how to build products by taking other products apart to see how they are constructed. Students will learn about the process, importance of defining a process, importance and role that documentation plays in the engineering workplace. When we get to the material, you'll see there's quite a bit of documentation. If I haven't said it already, but I might have, you're going to write a lot of documentation over the course of your career, way more than you can anticipate right now. So, writing skills is important because you do a tremendous amount of writing. How to build a Bill-Of-Materials, what that is, what that looks like. It's part of the assignment. We'll talk about that. So, some excerpts from a book I used in my undergraduate class, assembly language programming course, that author Marilyn Wolf had some material design process. So, in this one, she wants you to think about two ways this works. You start with a set of requirements, and then you move to a specification, and then you move to an architecture. These would be documents. Requirements might be a document, or might be in a database. There's many different ways to capture requirements. At Micron, we used to use this enormous spreadsheet that had 3,000 or 4,000 or 5,000 lines of requirements and we're moving it all into a database application now. Then, what she calls components, and then system integration where you bring everything together. So, there is this notion of doing a top-down design where it's very abstract at the top and as you work your way down these levels, it gets more and more detailed. Once you get down to this level and you've, actually understand the full scope of the program and all the work that needs to be done, you can go back the other way and do a bottom-up design. So, you can start building smaller modules, state machines and data paths and engines, and who knows what, your Ethernet ports and USB connections and display for the logic to control LCD display on your product, for instance. You start putting these things together and you build your way back up. So, that's the term bottom-up design. In my work, I've never split these two out. This was strange to me. Specification and architecture is the same thing to me. So, I only really see four levels, in my experience. She had this other, some other notions. Time, I think, was going that way in this figure. Again, requirements, architecture, coding, testing. Then, maintenance on your product once it's out the door. I'm not sure I fully grasp how maintenance goes back to testing, goes back to coding, goes back to architecture, goes back to requirements. I don't quite grasp that. This one makes a little more sense. So, I always think of this as a cone. There's three vectors at the bottom down here. There's requirements, there's design, and then there's test. So, there's three, I guess. I can't do with my fingers, all right. But there's three vectors there. In this notion, you start out with the system feasibility and you loop around through your requirements, through your design, and how you're going to test it. You revisit these things over time as you work your way down to the building prototypes and building the initial system and enhancing the system. Yet another one, and this is very similar to a diagram we'll see at the end of the slide set in the agile development process. But you make some specifications, or think about this as requirements. Then, you do some architecture work, then you design and then you build, and you test. Then, you iterate again. You refine this, so this is the initial system, and then you go through a period where you refine it and you jump back up and you check your requirements. I'll tell you requirements come at you as a design engineering team constantly, and eventually you have to get to this point where you cut off and say, "We can't accept any more requirements because we have to put our heads down and get this product designed and developed and tested, and get it out the door." So, these requirements then need to be moved into the next product. It's really hard to say no because of the business unit. People will come to you and say, "Man, we have to have this feature because it represents another $50 million of revenue, annual, and if we don't have that, then we're going to miss out on this revenue." But as an engineer, you're looking at all this work that you have to do and you think "We're barely going to get done as it is right now and if we have to implement this additional requirement, there's no way we're going to meet our schedule." So then you slip your schedule, the customers are disappointed because they've been told when they're going to get their product, and everything sculpt sliding to the right, everything pushes out and in time. So, there can be tension there between new requirements coming in to your team and where do you finally decide to cut off. But, again, getting back to this, so you go back revisit your requirements, make sure those are good, you revisit your architecture, revisit your design, make some design changes if necessary, build that and you test it. This process can repeat so many n times and eventually you test your final product. Then, you're ready to go into production. So, those were several different ways of thinking about the design process. It's good to have a design process. It always has to start with requirements, have to start with requirements. This is primarily what your customers are expecting to see in terms of features capability: a requirements document or database will have some notion or "shall" statements. The product shall do blah blah blah. I've got an example here. It's not on this slide. Anyways, it's a list of shall statements. Not, it might be nice to have, or we want this, it's shall do. It's essential to meet the product requirements in order to be a saleable product in the marketplace. So, capture all of those requirements in a document or a database, but that's where it starts. The architecture specification takes those requirements and figures out at a high level, writing down what and how, but not a detailed implementation. When I wrote my architecture specifications for SSD controller chips, I took it down to a level that I believed that there was a logic design solution and a firmware and software solution. That is as low as I went because the design engineers would then take that, they could read it and they could understand what the intention was. Data was going to flow from here to here, and here to there, and then it gets transmogrified into this and it gets stored in this SRAM. Then, we take it out and we move it over here, and we do some more stuff to it, and eventually it ends up out on the media. It's important that architecture specification doesn't go too low. Many engineers have trouble with this abstraction because they want to get down to flip-flops and gates, and resistors and capacitors, and wires, and testing lab equipment, and power supplies. It's really challenging to keep yourself from going too low, especially when you write your first architecture specifications because you want to figure everything out. But just remember what I said. Take your architecture specifications down to the level where you believe a solution exists, but don't specify what the solution is. Let the design engineers do that in the implementation phase. Include as many figures as time allows. I spent huge amounts of time in Visio drawing all kinds of drawings and embedded those drawings in my architecture specifications and was well-received by the consumers of those architecture specifications, having lots and lots of pictures of what's supposed to happen. Figures and drawings remove the ambiguity of words. So, here's an example. Which is more clear? These are just words. The data shall enter the transmogrifier where it is XOR'ed with the Hobbes register value. The data can then be temporarily stored in the snowman SRAM, or forwarded on to the Spaceman module as per the Sled register value and the Calvin register settings. So, this is how Calvin and, raise your hands if you've read Calvin and Hobbes comics. Okay, couple of you, all right. Picked the wrong comic to take names from. All right, you can read this, and you can slow read as, get an image in your head. But if those words and this picture were together in an architecture specification, we see that we've got data input here being XOR'ed with a Hobbes register value. We've got this Sled register that sends it to this mux or takes the data and puts it in the Snowman SRAM register. Then, the Calvin register selects whether the data flows through that mux or is taken from the snowman SRAM and sent on to the Spaceman module, or supposed to be Spaceman Spiff. So, hopefully, you can see the value of pictures. I think it's important to have both. I think pictures without the words doesn't communicate enough. I think you got to have both of them, but take the time to draw lots of pictures. It's a pain, taking the time to draw all of those. It takes a lot of energy and time, but the consumers of your specifications that you write will thank you for it and clear up ambiguity and make sure that your product gets implemented more correctly. Components. This is design and build all of the pieces. Going back to that original Marilyn Wolf drawing. System integration is putting all the different pieces together. Loss of the Mars Climate Observer, who's familiar with that? What went wrong there? There were individual modules that were built and tested. They never caught this on the ground before they launched the Mars Climate Observer. One module was using imperial units and another module that it communicated with was using metric units. Then, when those two had to talk to each other as the Climate Observer was approaching Mars, a catastrophic failure and the Climate Observer was lost as a result of that. I don't understand how they didn't test this when it was on the ground, but it wasn't tested. So, there was a failure in system integration when they put all the pieces and all the components together. But there's way more to the process than these simple pictures that we've looked at so far, especially those ones in the first handful of slides.
