General Engineering Introduction/CDIO

Art, Science and Business activities will dominate a project. Each of these results in an engineering document called a "deliverable." There are 100's of deliverables. The deliverables are grouped into Front Material, Body, Attachments and References. There is one thing that is not a deliverable ... a narrative of what happened.

A narrative contains place, time, people names, sequences, phases, pictures of what happened, etc. A narrative indicates playing. Playing is defined as building something and then documenting it after the fact. Engineering involves documenting what is going to be done before doing it. Doing it (no narrative). And then analysis afterwards (more deliverables).

The result open ended engineering project is document. It is not a demonstration. It is not a product. It is not atoms. It is not a pile of materials. It is an electronic document that includes video and pictures. What can not be replaced is the engineering captured in the project document. The world of material things can not be used to recreate the engineering. The next team to work on the project does not want to start from scratch. They want to start by repeating the previous teams successes, failures, demo's and presentations.

The biggest problem with an archival system owned by the public is that trash attracts trash. Crap breads crap. So everyone has to understand the goals of an engineering document repository, what to expect in the engineering documents and work at maintaining standards.

This is the outline of an engineering project document, one layer deep:

Front Material
   Executive Summary
  	World-Team Problem
        Next Steps
   Possible in any CDIO section:
	Team Problem
        Tasks, Project management
	Decision Tree, Decision Matrix
	Theory of operation
	Outstanding Problems
	History of anything above
Attachments ... stuff created by the team
References ... previous teams work, work found on internet

Conceive Design Implement Operate

The philosophy and language of CDIO originated at MIT in the Boston Area. The four initials CDIO outline the life cycle of an engineered product or service. CDIO now represents a series of objectives that Engineering schools are beginning to teach. There is not a specific course on CDIO, but rather a series of learning experiences that are sprinkled throughout the engineering courses you will take in the future.

In section 4 of the CDIO syllabus, the four steps of engineering design represent boundaries where one group of engineers creates documents that are handed to another group of engineers. This is absolutely necessary in huge project involving many engineers.

In medium-sized firms, one group of engineers will do the conceive and design and other group will do the implement and operate. The first group are called design engineers and typically get the patents. The second group are the manufacturing engineers that typically create the product or service.

In smaller engineering firms the same engineer typically tries to do everything. Through the school of hard knocks, small engineering firms learn to "shoot the engineer" and hand the project off to someone else at one of the CDIO boundaries.

What follows here is an outline of CDIO.



Conceive could be called planning.

Identify the Client

An engineer serves two people: clients and customers. The client is the typically the engineer's employer. Sometimes the client is external to the engineer's employer. If the client is a scientist, then the client is called a Principal Investigator (PI).

The customer (Video Tedx Amos Winter wheelchair) will use the product or service developed. Sometimes the customer needs to be interviewed or survived to justify the project.

The first thing negotiated with the client is a problem statement. This is a description of the project. The problem statement may be refined, may be modified during the course of the project, but ideally the problem statement is not changed. The client's responsibilities are to evaluate the project at the beginning and the end. At the beginning the client agrees with the problem statement. At the end, the client says yes it was done or no it was not. The client may or may not be an engineer. In any case, the client wants the engineer to do the work.

Here is an expanded version of Conceive.



The word "Design" is used over and over again in Engineering courses. It is a process that captures the creative part of engineering, the business process of engineering and the science or calculations of engineers.

Sometimes firms outsource the design engineering. The most interesting aspect of this is called crowd sourcing.

Other companies hire consultants/experts to bring in fresh ideas or to expand the diversity of the backgrounds of those involved in the project. Often the consultants are older, retired engineers.

Here is an expanded design form.



Engineering calculations use science to predict what is going to happen. Most engineering disciplines use expensive modeling software that requires computer drawings to be made first. However, the skill of doing calculations on paper is always needed to make sure the computer is in the right ball park. This is because computers fail.

When the modeling software fails, then engineers correct the software so that it never fails again. Like building codes, failures lead to "lessons learned" and improvement of engineering practice. Modern modeling software captures "lessons learned". However this makes life easier for technicians, not engineers. Now technicians can use the evolving software to do what engineers formerly did.

Engineers are always on the edge of change. They must know what the modeling software can do reliably and what it can not do. They must know when it is being asked to do something it has never done before. The engineer must know approximately what to expect from the computer when doing something new.

An engineering education is basically learning how to "do the calculations." This is what separates engineers from scientists and technicians.



The design process typically starts out on paper, then simulated. The implementation process is building and testing. Draw physical shapes with 123D (free software from AutoDesk) using the Google 3D warehouse. Concentrate on assembly. Design circuits at Build circuit boards with Fritzing.

The expectation that engineers fiddle with materials in the physical world and make things work is a reality only in one particular, very small branch of engineering called "prototyping". And even most prototyping is done by technicians. Employers value engineers that can put instructions on paper. Employers then hand this paper to technicians. Employers don't become dependent upon a particular engineer this way. So don't expect to be given a lab bench and permission to play. This rarely happens. Most of the time engineers have to draw.

Engineers draw with expensive software (about $10,000 per seat per year). This is the expensive software mentioned in the calculations section. Knowing the limits of this software and dialoguing with the manufacturers of the software to improve it are a big part of a modern engineers job. All types of engineers draw. Pro/E is an example of such software for mechanical engineers. Orcad is an example of such software for electrical engineers.



Implementing means different things in different types of projects. When only one is going to be built, then it means getting it to work. In larger projects the first prototype is built at the design stage and implement means getting the manufacturing process to work. Or it can mean delivery to the customer and making sure they are happy. Or it can mean getting into a supply chain. For the purposes of this book/course/project, implement means getting a demonstration to work.

The most common components of implementation are test, verification, validation and certification.

There are many stories of an engineer that produces a design that can not be manufactured. The design engineer has to be brought back in while manufacturing engineers watch to see exactly what "magic" the design engineer did to get the prototype working. This is why companies do not like design engineers to build prototypes but would rather have the design engineer tell technicians how to build the prototypes. In this way the manufacturing engineer has a more reliable design to work from.

The hand off from the design team to an implementing team usually requires different personalities. Designers tend to overlook problems that fresh minds stumble into. The hand off from implementing to customers/end users has to be clear. Help desks have to be setup, FAQs created and modified. Problems, stumbling blocks have to be solved by modifying the hardware, creating a new version of software or educating the customer. In any case, these issues have to be captured to improve the next implementation.

Here is an expanded Implement document.

Where do art, science and business activities go in these categories? Every project, every team, every individual will find different ways to organize the information. A "best way" or "best practice" will emerge as the project matures its own context.



Operation means the day-to-day activities that keep things going such as management, support, preventative preventative maintenance, consumables, life cycle value and costs, and quality. Quality engineers are sometimes the second engineers hired in start up firms after design engineers. This is before the president, CEO or accountants are hired.

In an introduction to engineering class, operation means other students and instructors can operate or demonstrate the device. Selling engineering down into the lower grades and attracting donations up into the engineering community demand demonstrations of past success. Project fruit will die because it falls apart, takes up huge storage space, or is hard to explain.

Here is an expanded Operation documentation.

Operations sounds boring, but it is not. There is a pyramid of jobs an engineer can have with conception reserved for few older engineers. Most engineering jobs are in operations. And they are fun too.