Cloud cult

20 January 2016

Last month, Al Dean put forward the view that relatively little has changed in 3D design technology over the last two decades. Since then, he’s seen a few new things emerge that could persuade him to change his mind

Early demo of 123D Circuits linking data to Fusion 360

As someone who makes his living writing about the field of technology within the context of design and engineering, it’s often an interesting process to put a thought out there that you’re well aware is going to nark a few folks.

You’re likely to get a stream of emails, asking if you’ve lost the plot. You’ll start to question whether you’ll be shunned at the next big industry event. But you might just see a few new things along the way that could make you change your mind.

And so it has proved: in the last month, I’ve been made aware of a few new developments that suggest that, finally, after all these years, there is something new on the horizon for the 3D design and engineering technology world.

One of these came to my attention at Autodesk University. While out in Las Vegas, I got the chance to sit down with the team driving Autodesk’s Fusion 360 product and saw a couple of things that showed where the technology’s heading.

While it’s safe to say that Fusion’s geometry modelling tools are maturing nicely, it’s also clear that geometry and drawings aren’t the limit of Autodesk’s goals for this product.

During the demo, the team showed off just how powerful a cloud-based system can be. They’re currently building out an integration between Fusion and its 123D Circuits service.

If you’ve not come across this before, it’s aimed (mostly) at those working with electronics, with tools designed to quickly prototype a circuit (using a virtual breadboard), then develop those into circuit schematics and eventually, board layouts — including tools to integrate Arduinos and associated code simulation.

The integration between Fusion and 123D Circuits (123d.circuits.io) has been established and is live. If you edit the circuit board, the Fusion model updates and vice versa. If you move components, those changes will be reflected across the same systems.

This might not sound that ground breaking, but the potential is huge. 123D Circuits already has functionality that allows you to essentially switch on, test your circuits and run your code.

Fusion 360 holding both 2D schematics and 3D PCB models

The next step is to take that same approach and connect it up to the 3D model.

If your circuit tells a servo in the circuit to move 45 degrees, then the mechanical linkage to which it’s connected in Fusion will also move a quarter-turn.

Another interesting development came from Onshape in the last week or so. While the company is now out of beta with its main offering, it’s now also launched an app store (of course, that’s now the default name for anything third-party developer related).

While there are the usual desktop applications that connect to Onshape and read data to carry out their own special purposes, there’s a different class of product on there — one that is similarly cloud-based.

While this isn’t necessarily new, the manner in which you access these products certainly is.

Now, rather than hunting down third-party applications, requesting a trial download, then going through the purchasing process, you simply ‘subscribe’.

Many of these tools are offered according to the same ‘freemium’ model of Onshape, so you’ll get a certain amount of usage for free, then you’ll have to start paying.

But what’s clever here is that, if you do decide to invest, Onshape handles all of the transaction details and your purchase is billed through the same source as your Onshape subscription.

The tools are available in the same browser as Onshape, often directly inside the user interface. Compared to how third-party applications are traditionally sold, this is a shift and a big one at that.

Onshape, as with most cloud-based tools, rolls out each update to every user at the same time. Presumably, those third-party developers using the highest level of integration will be forced to keep up.

Onshape’s fancy new app store, making third-party applications more discoverable

For those of us used to waiting six to 12 months for an add-on to be updated, just so we can update our main system, this will be a massive benefit.

So perhaps all is not lost after all — or maybe I just had a case of the winter blues last month.

As the roles of many designers and engineers are changing, with smaller teams working on more complex products, so too are the toolsets we have at our disposal.

They’re becoming more powerful in terms of task coverage as well as the ability to, if not carry out additional tasks, then certainly to interact with other tools engaged in the same process.

Alongside this, the process through which we acquire the additional tools we need to carry out our work is shifting, both in how the tools are adopted and used.

Anything that removes time and effort from that process will be a welcome development for many, I’m sure.

Comments on this article:

[Data-permeation, data impedance, ‘G-PLM’ and DM- ‘It’s the RDBMS 'whot' did it’]. I’ve just read the previous blog on this subject of 'not much change'– with the positives coming from 123Dcircuits/Auto desk and also Onshape discussed here, but I feel Al still has initiated an important discussion here. A few points I’d like to add (at not all original, but worth a re-visit). (i) it may seem just a semantic point – and may just reflect the target audience of Develop3D – but I think Digital Manufacturing (DM) is a better term to use for the discussion – not CAD. I did think that CAE might suffice – but I guess that has its own ‘meaning’ within the ‘industry’. CAD and design are of course important and essential in the wider process of Manufacturing-and I take Manufacturing to have the full scope from Marketing (as in market research and New product development (NPD)) – through concept design, detailed design and engineering, make/buy/ procurement, ERP, simulation/CAE, CAM and on to end of life management and everything in between). My aim here is so that we see DM-IT infrastructure and its use in Engineering/manufacturing in its generality, not as specific to job junctions, but as each job function having its own view on data stored uniformly. (ii) this leads to my follow on point that, whilst it is good that say 123Dcircuits (only as an example) and similar can talk to other systems and provide some form of integration – this is I guess at an interface level- other systems cannot ‘see into’ the data (for purposes that the original s/w designers could not easily envisage (or did not want to expose)). It is almost like having a ‘power grid’ where power is distributed partly by hydraulic means, partly buy mechanical means and switching from one method to the other over the ‘network’. Arguably early factories had this with centralised Water wheels – which became the model for centralised steam engines, with power being delivered around the factory. Early factories followed that model with large central electric motors. Of course an electrical grid allowed for smaller, appropriate tools to be distributed around the ‘production process’ both factories and the supply chain (so obvious in hindsight – that’s its ramifications at the time have been forgotten). I’d say that with CAD – sorry DM data we are at the monolithic, electrical motor stage with our data and data transportation – and how we can use that data. Of course vendor tie in is a barrier here- which arguably is of no interest to the user/customer, but until through whatever mechanism we go from monolithic to fully distributed as our baseline infrastructure occurs, DM cannot flourish and give its full benefit to society (and that includes companies). May be that is not Al’s aim – but that is possibly where looking through the prism of paying customers and shareholder driven vendors is actually holding things back as to what could be achieved (and with winners and losers) (this is not mean to be a political diatribe – but does need consideration if we are asking why things haven’t developed as far as we’d hoped). PLM is not a term I’ve used yet as this really does go ‘beyond PLM’ [Oleg Shilovitsky- thank you] – maybe G-PLM (Generalised PLM) might be a working term before something better comes up? (III) The technical bit (no apologies) – the point I am getting to is that whilst there has been good work and progress around say 3D in browsers, and lots of (really) clever people developing algorithms etc, what has never really been questioned is the Data storage and Transportation layer of DM. I’d say that ‘monolithic’ data storage (primarily RDBMS, but also text files and Excel, which are monolithic in a less obvious way) is the ‘steam engine’ of our industry. Even if they are large ‘electrical motors’, we are suffering impedance (in both the electrical and process definitions of the term) similar to the losses caused by step up and step down transformers (at the API level) . I cannot say for sure how moving to new models of data ‘transmission’ might unfold (and I’m taking NoSQL data storage as a starting point- in particular Graph databases’) to give us benefits. However taking the water power, to steam, to electricity analogy – in how production was reconfigured ‘from with in’ to lead to benefits such as the assembly line – starting to look for a reconfiguration in data and the relationships between data (RDBMS ironically barely support relationships- and products are full of relationships) might do the same for the DM industry – or whatever replaces it. Just as the Internet and WWW is built up on simple standards like TCP/IP – we need something analogous for DM data and data relationships (geometric data of course – but all non geometric data as well) to at least transport and store commodity data (points, lines, dimensions, edges and faces, work flows (OnShape’s microversions) in CS terms they are all 'graphs' of nodes and edges). I will hear many people say 'STEP', but what I’m talking about is not about interchange it is permeation into the heart of the data. Standards require agreement, but then may be it maybe people and outside the main DM players who may come up with this and with East growing in population far more quickly than the west - that’s a lot of potential, Einstein’s, Fords, Berners Lees’ or Robert E Kahns to develop the technologies and standards.

Posted by Paul Reeves on Monday 25 2016 at 01:56 PM

Leave a comment

Enter the word you see below: