Models in motion

Constraint modelling looks for design problems and then solves them. David Fowler explains how the process works

Back in the 1980s, two colleagues at Brunel University’s department of manufacturing and engineering systems were discussing a problem. Professor Tony Medland, previously with PA Consulting and Cambridge Consultants, had a background in consultancy and problem solving. He was trying to use CAD to design rather than for draughting.

Dr Glen Mullineux, a mathematician, believed that what Medland was trying to do was impossible, because the design process has so many variables. Systems of this sort, with more than five or six free variables, were unstable and not susceptible to rational analysis. He set out to prove this by trying to devise a program to optimise a mechanism with 10 free variables. To his surprise, it worked.

The result, a technique known as constraint modelling, is finding applications in modelling and optimising all types of machinery. If a machine is needed to move along a complex path to pick up an object from a conveyor and put it down somewhere else, constraint modelling software will suggest various mechanisms to achieve this.

But, says Medland, its potential is much wider. `It could be used for anything from designing details of a machine, all the way up to management level.’

Medland and Mullineux, now at the University of Bath, became involved in machine design almost by accident. For five years they developed constraint modelling without grant support. Mullineux’s rudimentary original program, in Fortran, was developed into an interactive version running on PCs.

They originally referred to it as a rule-based system. `But rule-based or expert systems can only give you results that are programmed in,’ says Medland. They devised a better description:constraint-based. Unlike a rule-based system it mirrors the process of design. `When you design something from scratch you don’t know what the rules are,’ says Medland. `You have some idea of the constraints, and more become apparent as you proceed.’

Problems in design are problems of conflict between functional requirements, such as the need to resist certain forces, and constraints such as size. Constraint modelling searches for conflict and tries to resolve it.

An example is the design of a car gearbox. You can size the teeth and the gears knowing the forces they have to transmit. But you might then find that it will not fit in the car. So you have to relax a constraint, such as the gears being made of steel. `To make them smaller you could use an exotic material such as titanium. Then you might come across the constraint of cost,’ says Medland.

`Our software iterates between the functional requirements and the constraints. We identify where the constraints will occur and allow the system to free the constraints, under control, to achieve a compromise which both meets the functional requirements and constraints.’

Mullineux adds: `We identify what the constraints and what the free variables are and it looks for a solution. It either optimises to give the best compromise which meets the functional requirements and the constraints or, if they are not fully satisfied, it flags up the problem so that the operator can modify the constraints.’

Unlike rival systems which optimise different aspects one at a time in a set order, constraint modelling optimises everything simultaneously. It does this through what Medland and Mullineux describe as a truth maintenance system. Each constraint is modelled as a mathematical expression which has the value zero when it is satisfied. The system tries to minimise the value of each expression. Constraints can be weighted to bias the search in a particular direction.

Medland and Mullineux got into using the technique for machine design by accident. `We had started on assembly problems: can you design a mechanism to give you a particular motion where the solution is not obvious, such as a figure of eight going through 16 defined points?’ As a result they became involved in an EPSRCproject which was the forerunner of the Link High Speed Machinery programme.

Working with Unilever and the Metal Box group (now Crown Cork & Seal) in what is known as the Camford (constraints as methodology for design) group, a windows-driven version for Unix workstations was developed with a catalogue of standard mechanisms. The catalogue gives the operator a choice of mechanisms which approximate the motion.

To use the system, the designer clicks in a series of points on a screen to define the path required and specifies a type of mechanism. The catalogue includes four, five and six bar linkages, slider cranks and cam-based mechanisms. The system displays the 10 mechanisms of the type chosen which come closest to the path specified.

Often the catalogue mechanisms work well enough, but they can be refined. `Quite often the motion isn’t an absolute track,’ says Medland. It may have to be precise at a point where it has to dive into a cavity and pick something up, or to match the speed of the mechanism to that of the object on a conveyor at the pick-up point, or transport the object with near constant velocity, but constraints on the return motion after the object has been put down can be relaxed. The system allows this sort of optimisation to be carried out.

A practical example of constraint modelling was on a guillotine for cutting paper on a high-speed packaging machine. The mechanism kept jamming. It was designed to follow the paper in order to be moving at the same speed at the instant when the two blades closed to cut it. It then returned against the flow of the paper with the blades open. By modelling the mechanism the team discovered that the lower blade hit the paper an instant before the top one, lifting the paper instead of meeting it and the top blade cleanly. Also, it started on its return path while the blades were still closed, crumpling the paper.

By running a model of a corrected motion profile backwards, a new cam profile to generate it was devised. `But the first set of cams wouldn’t fit in the machine, so an additional linkage was added to magnify the movement,’ says Mullineux.

Medland’s team collaborated with the University of Salford on a robot gripper to pick up margarine tubs from a production line. It was able to match the gripper’s speed with that of the tubs and devise a motion to get the gripper into the tight space between the tubs.

The food manufacturing industry has been the source of numerous applications for the technique to improve machine reliability. This is at a premium because turnround times are fast and breakdowns can mean missing a delivery date.

Development is continuing on several fronts. The software is now available for Windows NT and 95. The Constraint Modelling Collaborative Group has been set up to solve specific problems for subscribing firms, by modifying the underlying computer code. Useful new features are embedded in the more stable version of the program which is more widely available.

One such firm, the Inbis Group, a recent buyout of the non-automotive parts of Ricardo, is looking to integrate the software with standard engineering analysis tools to create a powerful design synthesis tool. It has already made significant improvements to the design of robot grippers.

In a project named Backbone various packages are being integrated in a package called Swords. These include Bathfp, Bath Fluid Power Group’s software for designing fluid power drives; motor and control system selection software from Aston, Birmingham and Wolverhampton universities; Mechanical Dynamic International’s Adams stress analysis software; and Spatial Technology’s Acis 3D modelling.

For example, data from the constraint modeller can be read into Adams automatically; it will calculate the forces and output a torque which the drive must supply. The system can be set up to iterate through Adams to minimise the torque, then switch to Bathfp to design a drive.

Another project aims to do the opposite of Backbone: split the constraint modeller into a series of communicating cells to allow design to be done at geographically separate places. Cells would work independently to optimise different aspects of the design, provided they did not conflict.

For example, a car body could be designed in Coventry and an engine in Japan. Interfaces are being written to allow each cell to export and import data by e-mail, which they can open, read and act on automatically.

If a conflict is identified the cells try to resolve it, alerting a human operator if this is impossible. The problem and the members of the design team affected would be identified, and videoconferencing could be used to solve the problem.

Constraint modelling’s potential is vast, Medland and Mullineux believe. `We got into mechanisms because of funding,’ says Medland. `But the technique could solve any problem you can define as a set of constraints.’

More information and a Java simulation of the constraint modeller can be seen at: