Ruby on Rails achieves this goal by simplifying web application development and removing configuration decisions so that the developer can focus on solving the business problem. With this in mind I thought there may be value in exploring an equivalent framework for mechanical part and assembly design.

The Basic Framework

The framework would be based on a file structure with names that follow the Principle of Least Surprise. The file structure would encourage engineers to organise their data and working files consistently across teams and projects. The default file structure would be generated and supported by scripts and file templates. Scripts would also be used to create new assemblies, parts, references, and generate reports. Additionally, the framework would leverage a number of established standards for engineering data – for example MatML for material property data. The following is a first pass at how this might look.

At the first level the framework would contain directories for configuration, management, references, scripts, templates and work.

The configuration directory would contain vendor, supplier and project details together with specific framework configurations.

The management directory would contain typical project management documents including customer supplied data, reports and commercial and technical quality plans. Registers of the data would also be included as XML and could be potentially maintained automatically using scripts.

The reference directory would contain engineering reference data such as MIL Handbook or ASME data that is used across the project and is approved by the customer. In some instances this data may be public domain but the majority is likely to be proprietary to either the customer or the vendor and would be separated accordingly. An important assumption (convention) would be that all data would be current and approved for use. Ensuring this assumption holds true may be difficult, especially on larger projects, but this is something the framework could help maintain using automation. Reference data would be separated into design, analysis, manufacturing and materials. Ideally data and methods would be stored in neutral formats to maximise reuse opportunities.

The scripts and templates directories would contain standard scripts and templates together with any customised functionality. Templates would be defined in XML and styled using XSLT.

The work directory would contain the parts and assemblies structured according to the part hierarchy. An XML file would store these relationships for interrogation or reporting purposes. Part numbers would be used to uniquely identify part and assembly directories. For each component the design inputs and outputs would be separated. Inputs would be further separated into geometry, applied loads and materials and ideally stored as XML files. The outputs would be representative of the design lifecycle and resulting data formats, typically CAD, FEA, structural analysis reports and manufacturing plans. The maturity of the design could be captured in an XML file for each part according to a standard product lifecycle.

Framework Infrastructure and Automation

A scripting language would be needed to support the framework and the obvious choice would be either Python or Ruby. Since the framework is intended for the engineering community, Python might seem like a prudent choice as it has always had a strong association with the scientific and technical computing community. However, the clean expressive nature of the Ruby language together with the Gem system for package management makes Ruby the preferred option.

Users would interact with the framework in the same way as they do with Ruby on Rails. For example from the command line:

% engfwk project_name vendor_name client_name

% ruby script/generate assembly assembly_name parent_assemby_name
% ruby script/generate part name parent_assembly_name
% ruby script/generate material source_filename.xml
% ruby script/generate load source_filename.xml

% rake report:progress

% rake verify:project

% rake stats

Benefits

In my experience, on large engineering design projects the approach that different engineers take when they design or analyse parts is largely dependent on how they did it last time, rather than best practice guidelines or company standards. The benefits of coercing the design and analysis activity into a standard structure is that users know exactly where to find and store data. While this may sound minor, on large projects this makes a huge difference to team productivity, ensuring the right reference data is used and the ease with which engineers can pickup another engineers work. Another benefit to structuring data in a consistent and predictable way is that engineers would be able to developer tools or pluggable extensions to the framework that could be reused across other projects.

Concerns

The main concern with this idea is that the proposed framework could be considered just a simple, file-based PDM system. This is a valid concern, but the low costs and flexibility of the proposed framework probably negates this concern.

Next Steps

The best way to explore the potential benefits of an engineering design framework would be to try applying it to a design problem. This will be my next step…

Small Regular Deliverables

At the heart of agile is the incremental delivery of projects in small regular intervals, rather than one large delivery at the end. Each of the delivery iterations is a subset of the entire development lifecycle and is demonstrated to the customer. This has the effect of reducing the risks associated with the development progressing in a direction that is not consistent with customer requirements. Applying this principle to engineering design does have some limitations, particularly since the cost and complexity of construction usually prohibits multiple iterations. However, within the design phase of an engineering project, there are good opportunities to use this approach and it is this part of the product life cycle that has been considered.

During the design phase of an engineering project, milestones are often introduced to mark preliminary and critical phases of the design. These milestones do encourage incremental delivery, but they are neither small enough, nor regular enough to be consistent with agile principles. Modern CAD tools enable rapid development of digital mock-ups that can fulfil this objective. The CAD model can contain sufficient design detail to accurately represent the product and surrounding structure. As a result the CAD model can be used as the basis for verifying many different acceptance criteria. Additionally, rapid prototyping systems enable the creation of physical mock-ups that greatly enhance customer engagement and interaction with the design process.

From an agile perspective these deliverables are important for customer engagement and verification of the design direction. However, prototypes that do not add directly to the final product are not valued as highly as actual progress toward the final delivered product. That said, there is still significant opportunity to make incremental deliverables part of the design process and no technical reason why this cannot occur throughout this phase of an engineering project.

Deliverables Measure Progress

Customers often propose an earned value schedule for a project that is based on deliverables and is linked to either financial payments, or the release of additional project funds. These types of earned value measures are compatible with agile principles, particularly if they are granular enough to encourage close customer involvement in the project.

For engineering design projects, the CAD model is increasingly becoming a digital representation of the complete product including geometry, materials, manufacturing details and even the original design intent. Measuring the progress of CAD model maturity and conformance with acceptance criteria will provide the most agile measure of project progress.

Customer Collaboration

Customer satisfaction is considered important in engineering design projects, but the value of customer involvement in the development and review of the design as it progresses, is not widely utilized. Many project resource models fail to consider the benefits that can be achieved through close engagement with the customer, even for tasks that may appear well defined and understood.

Traditionally, the approach has been to develop highly prescriptive specifications and then negotiate changes with the customer using forms and documents such as Engineering Change Notes. In an agile environment, changes are driven by the customer and embraced by the development team. During the design phase of an engineering project there appears no reason why the same approach cannot be used. Additionally, when collaboration occurs between the customer and the engineering design team, the customer will tend to accept a greater level of responsibility for decisions as they can clearly see their impact on scope, schedule and cost.

The Scrum model advocates meetings that occur daily and at the end of each delivery iteration or sprint. The daily meetings involve the customer and all team members and are an opportunity to discuss each team member’s progress, plans and any obstacles. The iteration review and planning meetings also involve the customer and is their opportunity to prioritise the order in which features are implemented. This ensures that the development team are always working on the features that are of the highest value to the customer. These meetings may not always be practical because of team size, geographic locations or prior commitments; however, even at a small scale they have significant value. In large projects where the majority of engineering design work occurs in a separate location, a daily telephone or internet conference call with all team members will achieve a similar result and is a technique that is very valuable.

Simplicity and Design

Starting with the simplest possible solution that satisfies customer requirements and then maturing the solution during course of the project, is a common agile practice. This approach is somewhat at odds with software architecture design principles, which often need to be addressed early in a project. The conflict is typically resolved by developing software in such a way that it can be re-structured as easily as possible.

The main techniques for achieving this include: maintaining loose coupling between components and implementing automated tests. The loose coupling provides the opportunity to easily replace components or restructure the overall design with minimum impact. Automated tests allow architectural or component changes to be verified quickly thus further lowering the cost associated with changing and evolving the solution through the course of the project. This process is often referred to as refactoring.

For engineering design projects, implementing the simplest possible solution is an implicit assumption for most engineers and therefore compatible with agile principles. What is lacking however, is automated testing that verifies design changes. Significant work has already been done to automate structural analysis methods using both computational and classical analysis methods. However, this analysis is generally performed manually as a supplementary activity, rather than a concurrent activity that is automated. Therefore an opportunity exists to implement automatic design verification against customer defined acceptance criteria.

Embracing Changing Requirements

Traditionally, engineering project management practices have emphasized the need to control change. This is partly because project change has been closely associated with project cost, especially within a fixed price environment. Conversely, agile principles are based around an assumption that change will inevitably occur during the course of a project and that it is better to position the solution and working practices so that they can easily adapt. Furthermore, in an agile project it will be necessary to compromise at least one of either project; scope, cost or schedule and customers need to appreciate that they are responsible for guiding this compromise.

The agile practices of refactoring and automated testing help, software projects adapt to change, while the close customer involvement ensures that changes are identified as early as possible. For engineering design projects these principles can be applied as equivalent technical solutions exist, however the costs associated with automated testing can be very high. Consequently, engineers typically question the return on investment associated with automated verification. Additionally, engineers often take a conservative approach to alternate design methods and therefore changes are typically met with strong resistance. That said, there is generally a trend towards engineering automation and this is likely to evolve into automated testing.

Pair Programming/Working

Pair programming has attracted controversy because managers typically assume that having two developers implement the same functionality is only half as efficient as conventional working models. As an agile practice, pair programming has the effect of increasing software quality through peer review. Quality is critical as it ensures that the resultant software is in a state where it can be adapted to meet changing or additional requirements.

In a typical engineering design environment, the practice of pair working is uncommon. This maybe in part because of how tasks are broken down and matched to people with appropriate skills and experience. Another reason maybe the perceived cost ineffectiveness. Either way, the clear benefits that pair working provides should justify its adoption more widely.

With this in mind, there may be better ways to decompose engineering design tasks so as to exploit the skill and experience combinations that pair working offers. An example could be pairing a structural designer and analyst, instead of having the designer initiate structural layouts and the analyst size the structural features. This would encourage a more concurrent approach and result in a higher quality design and less rework.

Summary

Agile methods have become the default approach for software development projects. Many of the agile practices and principles can be more generally applied to other disciplines including engineering design. The opportunity for engineering design organizations is to improve the reliability of project success and the quality of resultant designs.