Even for R&D purposes, the cloud is a great leveling agent. When designing a product that requires many hours of computation, only large companies were able to afford to buy enough computers and software to make it cost effective to do this. Now, large quantities of computers are available for rent on an hourly basis. Companies providing things like simulation software would be well advised to look at their business models, and how they could be profitable renting their software on a cloud rather than selling it.
This discussion seems to break down into:
1) use the internet to allow geographically dispersed teams, perhaps working across all time zones. This happens already in many companies both big and small (my company did it out of necessity when there were only 5 of us in 3 continents)
2) use huge shared computing power to run big jobs such as regression testing, simulation, finite element analysis, etc etc. Lots of things engineers do already but the cloud adds the element of not needing to own the hardware or justify buying it to the boss. However the cost of routinely using cloud resources all the time is higher than owning those same reosurces - it only works out cheap if you use a big resource for a small time
3) there is a possibility to make products seem a lot brighter than they are by letting them hook up to the cloud to deliver some of their functionality - look at Siri on the iPhone - the brains are not in the phone! So can we have cars, cranes etc which have very high capabilities but all that is builtin to the car is the sensors and actuators, the rest is in the cloud? The problems are: a) what happens when you lose the uplink?, b) what are the sensitivities to latency? c) how do you ensure that there is enough compute resource in the cloud to service all your products when they need it (eg simultaneously). EG if every iPhone owner uses Siri simultaneously - does this mean Apple needs to have a beefy server for every phone they sell?
But not only software development. Way back in ancient history (1998-1999), I worked on a multi-continental IC design that used "the cloud" very effectively. Some of the major IP blocks were developed in the U.S. and others in Europe. Every morning at the beginning of our day here, we had a conference call with the team in Europe to get a data dump on their day's accomplishments, which files had been updated & checked in, what was next on the integration task list and so on.
Of course we didn't call it "the cloud" -- it was just an NSF automount between our network and theirs, so we could all check files in & out of a single revision control repository.
Today this kind of thing is very routine, and companies in the revision control & design management business have made it easy for teams all over the world to access a central repository on the web (or is it "the cloud"?), and yes, those time zone differences do allow for more progress to be made in each 24 hour day.
But in the context of this article, I think the notion is that cloud-enhanced services and devices can boost manufacturing because they are more intelligent -- like the example the author gives of a U.S. crane manufacturer embedding intelligence (and connectivity) into his products to better compete with Chinese crane manufacturers. Of course, the point missed is that the Chinese can do exactly the same thing.
If by "the cloud" we actually mean "embedded intelligence and connectivity" then I agree that this can add value to a wide variety of products and this could be a boost for manufacturing...but not only for U.S. manufacturers.
Well how the "Cloud" could certain revolutionize manufacturing makes no sense.
Where it could help is in revolutionizing software development, enable mass software production.
As for globalization, the cloud helps there too. For example, 24 hours in a day breaks down neatly into 3 8hour shifts. You could have a team in the USA/Canada, who works throughout the day and hands things off to a team across the pacific. They work for 8 hours and hand things off to a team in Europe. They then complete the cycle and give it back to the North American team.
You could divide the teams by function (management/requirements, coding, testing), or just process the software pipeline in the same way in each location.
This will enable 24 hour software development. If nothing else programmers could appreciate having overnight testing and bugfixes done to their code overseas.
Speaking of the "cloud" this just moved across the wires (even the military is getting into the act):
Northrop Grumman Awarded Army Private Cloud Contract
MCLEAN, Va., April 4, 2012 (GLOBE NEWSWIRE) -- Northrop Grumman Corporation (NYSE:NOC) has been awarded an Army Private Cloud (APC2) contract by the U.S. Army. This contract will enable warfighters to have global access to information and allow the Army to achieve higher levels of computing efficiency, security and flexibility.
While I was on the West coast talking to companies and thinkers about the evolution of manufacturing, I missed an important manufacturing conference in my own backyard. Richard McCormack, editor of Manufacturing & Technology News, posted an excellent report on the conference here:
I recommend Richard's publication to anyone interested in reviving U.S. manufacturing. His was a voice in the wilderness when most of the tech community was embracing services and apps as the answer to our economic and employment problems.
What rharding64 has described above is precisely what Zysman, et al, are focusing on. The cloud is being used as a platform for product design and development and, ultimately, becomes a tool to add value in the production process. This example highlights the fact that the cloud can be used for more than enhancing services or writing an app. The result was a real product and the value underlying remains in the West. As Zysman points out, the problem now is transferring some of that value from company stock prices into the pockets of design engineers and the domestic manufacturers of new products.
I have a scenario that may help identify how exactly the 'Cloud' assists in manufacturing and development;
it is frequently the case that everything that makes a product involves people that are located literally all over the planet! Case in point, while Manufacturing Test Engineer at Microsoft XBox, I found that some development teams were located in the Netherlands, EU, and Manufacturing in China, and product design and development in Redmond, WA. Consider the following scenario;
say that there are developers at each of these locations that have a different piece to the product that they are responsible for. the goal is to put those pieces together in the 'cloud' to build it virtually there.
so what happens is, each location has their physical piece to the product puzzle that they do extensive testing, and data acquisition of this testing.
Then, the actual circuitry based tests are loaded up onto the cloud for sharing with the other team members where-ever they may be. These are extensive; as data is gathered on every significant circuit node at say, sub-microsecond timing resolution over the course of that test. so it effectively characterizes that circuit.
then, we have results that can be put into a 'black box' that has inputs / outputs that can be interfaced. so this black box on the cloud interfaces to the REAL hardware in different locations. Why is doing this important??
When designing / building new product, bEFORE we can 'spin' the printed circuit board we have to be certain that the design is correct. provided that we can make these virtual connections to different hardware across the planet, then a picture begins to form and a full product as a system functionality specification is formulated under laboratory conditions.
In the past, and currently, prototypes are sent worldwide, but with the cloud this virtual development/manufacturing makes it possible.
A Book For All Reasons Bernard Cole3 comments Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...