Public transportation does not get used enough, for the simple reason that it doesn't go everywhere people want to go, when they want to go. Plus, you need to run buses that are just about empty for much of the day, if you expect the system to be at all usable. Few people would depend on a public transporation system that might leave them high and drive, e.g. if they have to stay late at work. Unless there are no options.
So it turns out not to be as efficient as you might think.
I use public transportation to get to work every single day (well, not quite, I do have to drive to get to it), but it's useless for me on weekends. AND I have no illusions about our system being usable by everyone. Far from it. It's very inefficient between suburban areas, for example, yet many are employed in suburban office complexes these days.
The future, I have no doubt, will be increasingly self-driving private transportation. At first, collision avoidance sensors. But it will go from there.
I would rather have public transportation to be built than machine controlled individual car transportation, it would be so much more efficient...today I am going to work (in Vancouver, Canada) using SkyTrain technology that has no driver, is fully computer controlled and works flawlessly...it is much easier and cheaper to be built than some enormously complicated and error prone car controlled system...Kris
But the process tends to be thus:
Vendors make systems more complex/sophisticated because they can. To try and extract extra value the vendors describe extra features and benefits the system WILL/SHOULD have.
Punters bite and the system works less well than expected for all sorts reasons; usually the unintended consequences of the added complexity.
Punter tries to return to old simpler version of system to find it is no longer for sale.
On the smart car technology, I've been saying for some time now that the time will come when we'll look back and marvel that people were ever "allowed" to drive manually. How was this even possible?
Consider this. There is a practical limit to how many roadways can be built, especially in sprawling urban areas. In the LA area, for example, they are even talking about double deck freeways. So one might wonder, why not use the same roads, but much, much more efficiently?
And this can be done. You automate the whole process. Cars can be made to move faster, and be packed closer together, if you take human drivers out of the loop entirely. This sort of upgrade can be installed only on the most congested freeways at first. Doesn't have to be all or nothing. Side streets, rural roads, etc., can go on for a long time with manual driving.
There are tons of examples of previously manual functions that are now always done automatically, and no one gives them a second thought. For cars, think of the choke, or the fuel-air mixture, or the spark advance, or even the gearbox. Automation makes all of these functions far, far more fuel efficient and less polluting. You wouldn't even think of installing an 8-gear manual transmission in cars, yet with an automatic, no problem.
Yes, the too wide temperature cycling range is a nuisance. But it is not the fault of IoT per se.
That is a good example of what I'm talking about. Thermostats connected to HVAC systems have existed for a long time, and no one ever throught to give a a cathy name like M to M comms. Now that fancy thermostats might make use of IP, perhaps even to allow remote setting by a user, people make it sound like there's been a fundamental shift. But there hasn't. It's a simple evolutionary change, that may or may not fit people's needs.
I agree that heating needs to be smarter, more economical; can't our utilities synchronize our kettles / coffeepots /washers across the county to reduce peak loads? As long as it gets done overnight, I don't mind it taking a little longer because the thermostat has to wait ten minutes for a slot in the community power ring. Sort of like micro-power-cuts, but imperceptible to the user?
I suspect that widespread implementation of M2M technologies will result in much the same situations that arose when other innovative technologies were brought to prime time. The early innings are rough; features or abilities that aren't quite ready are frustrating; others do work, and are appreciated. With M2M, however, there is a large potential for abuse, and this will certainly result in all sorts of effort to mitigate the abuse. What will decide whether or not M2M is valuable is if it brings a something to the table. True, not all successful technologies bring anything of real value to the table: much of the worlds commerce is based on selling entertainment, something you can live without. But if auto fatality rates can be reduced by 1%, or if no one could start a car drunk, there'd be a lot of incentive to push the technology forward.
I am less sanguine than that, however. I am a "if it's not broken, don't fix it" sort of guy: I like my car the way it is; I don't want it monitored by the thought police to hear my comments. I don't want my house wired for sound, or even my heating and living patterns. I don't care if it saves me $1000 a year, the less Big Brother knows about me, the better. I think it might be worse still if instead of Big Brother we have Dave...
I suspect, though, in the end, people will wind up accepting limitations on their freedom and privacy in the name of safety and the public good. Just wait until the cops show up because you lit a cigar in your bedroom...
Those of us who grew up steering and braking (and sometimes breaking) for ourselves will likely resist a lot of this type of automation. But the road goes on. My mom never really got used to cake mixes rather than baking from scratch. Many film photographers resisted digital for a long time.
Many people will fear wide scale M2M, but most will eventually come around. My kids' kids will likely think actually driving for yourself to be a foreign as my kid do the thought of not having ubiquitous Internet.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.