What we engineer

It’s almost as if René Magritte was thinking of engineers when he created his famous painting The treachery of images, famously undertitled Ceci n’est pas une pipe, which I am sure you will recall looked almost exactly like this:

Is it a pipe? In the minds¹ of most engineers, it both isn’t, as Magritte insisted, and it is, and much more besides.

We’ll certainly talk about and refer to it as a pipe at work and - probably very briefly - if family or friends ask about our work. Since pipes rarely occur by themselves in a system, it will carry a distinguishing name, too: the feed or return pipe, for example; left or right, front or rear; high-pressure, low-pressure; gas or liquid. It might be called synonyms of the word “pipe”: tube, line, conduit, etc; it might be a hose. With such distinctions in the name, we as humans automatically grant it an identity that turns this idea of a pipe into an individual. During project meetings, we’ll talk about its status, open issues, timing, costs, suppliers and so on, all as if it were an object we could reach out to, pluck from the bill of materials, and place in front of us on the table. That image of it firms up the identity, even if we know that, in reality, it won’t be a simple, dull grey.

We’ll talk about its data as a 3D model, too: who needs to know what about it, how up-to-date and settled or mature it is, where the data is stored and whether it has been synchronised with its counterparts in the rest of the system.

Ideally…

Clearly, my pipe doesn’t yet contain enough information to be useful: it’s an idea or a concept that hints at what could be. Right now it can’t be connected to anything, not even virtually, as it lacks important features such as endforms and fittings, or any information as to what it’s to be made of.

It lacks itself, in many ways: it’s incorporeal, a “mere” representation, both of what it should be - a pipe - but also of what it isn’t: a pipe, yet. It is made up of (digital) bits and (human) ideas, not atoms, but it’s buzzing with identity and potential. In our minds, that image and its identity are hooks on which to hang further data and information that help to refine our engineering interpretations and definitions of it, to bring the pipe as we see it now closer to matching what we intend it to be.

As the researcher and philosopher of information Luciano Floridi would point out, our image of the pipe is a sign or symbol, a token: in all, a proxy, of some specific thing that is to be made. It stands for the pipe, but doesn’t stand in for that thing. Our intention of the pipe can’t carry any fluid, only the intention of a fluid. Whilst Gilbert Simondon wrote of The Mode of Existence of Technical Objects, what we’re talking about here is the mode of existence of technical objects that aren’t yet.

Data upon data, information and product

My representation comes from a CAD model. This we’ll want to update and complete, then send to someone (another mind) who will have to interpret and act upon the data by, for example, starting to develop the bending process to convert what was implicitly a straight piece of tube into a correctly, intentionally, bent pipe. We’ll probably need to derive drawings from the 3D, and will certainly have make sure it’s been properly and sufficiently specified, with materials and tolerances and other quantifiables, before we can distribute the design data more widely.

As the informational load associated with this part begins to increase, its sub-components, features and functions begin coalescing for us into the idea of a product that could be delivered to a customer somewhere, ready to fit into their system. Specifications and requirements (themselves needing interpretation) preceding, following and accompanying our CAD models, will result in digital simulation and then physical test samples (which, although now physically present in the world still aren’t the “thing” that we sell), followed by validation reports (always returning to data); the design generates cost estimates and expected profit margins and contracts then, eventually, hopefully, an official release to enable our object to be made and sold at volume, profitably.

There are many layers of information through which we can view it, but sometimes, more often than we realise, we simply call it: the pipe.

Let’s return to the tool that helped me to produce that simple idea, CAD.

Assembled for duty

When we see a CAD model on screen, we can apply several different mental layers of interpretation to it. We can correlate it to the intended product, as I mentioned above, or to specifications, functions, costs and all sorts of other aspects.

We use CAD to define the basic geometry of a product, which matures as our models and intentions progress. What we see on screen also informs and affects our design, perhaps even our intentions themselves. But what is a CAD model, actually, especially that of an assembled product? As a colleague of mine pointed out recently, a CAD assembly isn’t really much more than a list of the parts and components that it contains, plus some positioning information.

A little more precisely, a CAD assembly is a list of the components that comprise it, plus the “news” of their positions and relations to each other, in the sense of what features of which part are connected to which features of which other part, and where they all sit in space. Combined, CAD and PLM programs enable the integration of a very rich set of additional information, like materials, coatings, positional tolerances, constraints and mechanical degrees of freedom, special characteristics, and so-on, plus the metadata of the assembly itself, such as its maturity state (in work, released, etc), revision levels, authors, contexts and - as always - so on, all related to this one object (and all other associated objects).

Part and partial

The interesting thing to me is that those parts used in the assemblies are, at heart, the same in nature as the assemblies. They are not much more than a list of sketches and features plus (the news of) their dimensions and relations to each other in the sense of what elements of which feature are related to which elements of which other feature, plus where they all sit in space.

Actually constructing those parts in 3D requires a trained mind, ingenuity and patience, and the ability to apply clever methods to achieve the goal of describing the intention of the product - which is why we often see companies employing specialist CAD designers to focus on that work, in the same way that engineers don’t always end up hammering the part into shape (or into the final product), unless they’re working at a startup, or on very early prototypes. CAD designers are a bit like the software developers of the mechanical world.

The combined skills of engineer and CAD designer result in the 3D representation of that part that indicates how it is intended to “be” in the future: again, that word, intention.

Even less real

Now we’re in this flow, we can consider those sketches and features themselves. Fundamentally, they are “nothing more than” code describing basic shapes and complex curves so that they are interpretable by our workstations, both for further logical operations and - in our human-engineer-centric fashion - for displaying the results on screen for us to interpret.

Perhaps that’s the crux of what we’re considering here. Within this hierarchy of data, reaching all the way down to digital bits, up to fully manipulable 3D models and all the way back down to synapses firing, we’re constructing mental images, generating and connecting information and knowledge that we need to be as robustly interpretable as possible, so that when we come to pass on these informational ensembles to others - people, organisations and machines - who will, ultimately, make, test, buy and use the “real-world instantiations” of those models, we will be able to finalise the development, have met an SOP (Start of Production) goal, and call the project a success.

Return to data

As complex systems become ever more simulateable and “senseable”, we are entering the realm of the digital twin, where data returns to data. The physical objects that are doing work in the world are one aspect of the value that we have achieved, but the data that they produce and return to the models is just as valuable.

It’s like the data that our apps produce to send back to the makers… well, for advertising purposes, mainly, but also, more helpfully, to understand how we use the app and to tune their work accordingly.

Eventually, perhaps even soon, even in my world of mechanical design, data will be managed by data to create new and better data, all within machine intelligences.

This is where the ethics of the thing arise: should we set a minimum level of human interaction to accompany artificial design intelligence (generative design, etc), or could we envisage black-boxes designing things for us and rating only the outputs? I guess that’s a topic for a future post (by my AI agent…)

Gamification

There’s an interesting offshoot to this line of thinking: a pipe for a computer game. There, the pipe never leaves the digital realm, but retains many of its intentions, including that of carrying some (no doubt toxic or lethal) digital fluid. However, since it stays digital, it doesn’t need any “entry visas” or any other passport documentation to enter a market in the real world.

The mere fact that it doesn’t enter the physical realm appears to mean that it needn’t carry as much information as a “real” thing.

Thingifying it²

Once our original pipe has been released into the market wild, the question still pertains: What is our pipe, in the end? Even that isn’t always clear. From our initial sketches and CAD models, whole manufacturing lines have sprung up to make pipes by the thousands each day: sales and forecasts are loaded into ERP systems, machines and tools get swapped in and out to make certain numbers of these pipes - or whatever it is we’ve been working on - quality tests and measurements are made and logged. Boxes and cartons, racks and dunnage have been designed and made available to ensure safe and efficient handling, and our products are now distributed widely, perhaps even globally, unobtrusively doing their thing.

Is one of those pipes, somewhere, our pipe? Are all of them, in sum, or is the whole apparatus behind them “our pipe”?

Or is, really, ceci our pipe?