Wednesday, January 25, 2017

Tesla and the future of the autonomous cars

I have been following companies like Tesla and SpaceX for quite some time. Elon Musk has an amazing ability (or sense) to identify which established mature industries are ready for some shake up. It is fascinating to watch how companies like Tesla with no prior experience come and disrupt their corresponding industries. Being "out-innovated" should be one of the biggest fears and yet many large organisations (both in the car manufacturing and space technology industries) didn't get that sense of urgency. They were too slow. This could be due to various reasons - organisational culture that doesn't support innovation, the cozy feeling that you are safe because there are no new players to change the status quo or the sense that the entry barrier is too high. 

What makes Elon Musk's approach unique I think is partially due to his software industry background. The "release early, release often" mantra, that is so common in the modern software development world, allows his teams to iterate at a higher pace (compared to other players), receive valuable feedback and close the feedback loop by releasing newer versions faster than their competitors. It might be OK to release new products/models once a year in the classic auto manufacturing scenarios (with major overhauls every ~4 years) but in the software development world that would be a crime. And we can certainly see the software industry influence in Tesla's approach. The pace of innovation at Tesla is just crazy. They "will never stop innovating".

Earlier this month Elon Musk announced that the new revision for Autopilot HW2 will be rolled out to the first 1000 Tesla cars. All other Teslas that support this update were promised to also receive it but it would run in the shadow mode. This means that it won't be actively controlling the car but it will be collecting stats on the background (what it would have done if it were enabled).



As you can see from the 2nd tweet, the plan was to enable this mode for all cars by the end of this week. With just a minor delay we received this update:

So just after a couple of weeks of testing all Tesla cars with the HW2 package started receiving the update. By running the system in shadow mode on the first test group of cars, Tesla engineers certainly were able to collect valuable real life data that helped them to calibrate sensors. But as you can see from the last tweet, some cars won't be able to complete the camera calibration process and will have to visit a service station for the "adjustment of camera pitch angle". In parallel (according to Musk), engineers are working on a software solution to this issue. Preparing a software patch to mask/compensate for a hardware problem is a very common approach in the IT industry - this is another indicator of what is in Tesla's DNA.

And now this tweet:

As more data arrives, Tesla can keep tweaking and adjusting the capabilities of the new system. This is a spiral. Releasing updates in relatively short 2 to 6 weeks iterations is very similar to the agile approach, that has become a common practice in IT. It delivers increased value to the customers (end users) sooner.

Late last year Elon Musk has announced an ambitious goal for 2017 - a Tesla car (fully autonomously - no touch) should be able to drive from LA to New York, drop the driver (passenger? occupant?) off at Times Square and then automatically drive away to find a parking spot. We live in the future!

As a side note - sometimes it feels like Elon makes a public announcement first and then forces his employees to stick to these commitments. It's a nice way to maintain the high pace.

Another important news this week came from the National Highway Traffic Safety Administration (NHTSA). 

In May last year a 2015 Tesla Model S operated in the Autopilot mode collided with a tractor trailer in Florida. In June 2016 NHTSA opened an investigation PE 16-007 to "examine the design and performance of any automated driving systems in use at the time of the crash." They have finally released a report after completing the investigation of this crash.


 The result of the investigation?

NHTSA’s examination did not identify any defects in the design or performance of the AEB or Autopilot systems of the subject vehicles nor any incidents in which the systems did not perform as designed.
This is great news for Tesla. But, this is not all. This report also highlighted the safety benefits of Tesla’s Autosteer features. Automatic Emergency Braking (AEB) technologies include the following: Forward Collision Warning (FCW), Dynamic Brake Support (DBS), and Crash Imminent Braking (CIB). 

In 2016 20 car manufacturers (99% of the US new car market) made a voluntary commitment to make AEB "standard on virtually all light-duty cars and trucks with a gross vehicle weight of 8,500 lbs. or less no later than September 1, 2022"

IIHS research shows that AEB systems meeting the commitment would reduce rear-end crashes by 40 percent. IIHS estimates that by 2025 – the earliest NHTSA believes it could realistically implement a regulatory requirement for AEB – the commitment will prevent 28,000 crashes and 12,000 injuries.
12 thousand injuries (!!!) with some of them inevitably being fatal. Imagine how many people will make it safe back home to their loved ones - thanks to this amazing technology. A 40% reduction in rear-end collisions alone is a pretty big deal!

Human driver typical reaction time ranges from 0.7 sec to 3 sec with 1.5-2.3 being the average. 0.7 seconds is an eternity in the world of computers. Remember when automatic gearboxes were first introduced? They were slow and clunky. Purists were advocating for the manual gearboxes - better control of a car, faster launch times (quartermile) etc. Technology kept evolving and then suddenly one day we saw models equipped with the auto gearboxes showing faster times. We just have to accept the fact that computers are faster. The same is happening with the Autopilot technologies. 0.7 seconds is plenty of time for a computer system.

Image courtesy of https://www.technologyreview.com/s/534981/car-to-car-communication/


Now combine this with the car-to-car communications and capability gap becomes even wider. Cars will be able to update each other and provide situational awareness. A car driving 2 cars in front of us in the same lane sees an obstacle and initiates emergency braking. A human driver wouldn't be even aware of this emerging situation yet. Compare this with our autonomous car that immediately receives this information and responds by priming the brakes, reducing engine power and preparing to slow down and stop (actively measuring the distance to the car in front of us).

These recent successes and overall progress in the world of self driving cars got me pondering - how will these technologies change the world around us in the near future?

Faster reaction time means that autonomous cars can travel at faster speeds and potentially closer to each other (to increase the flow rates). This will most likely result in dedicated lanes for autonomous cars only (human drivers will not be allowed to drive there). These lanes might also be equipped with additional features to aid navigation and safety.

Since autonomous cars will be safer, the insurance premiums for the human drivers will go up. Do you want to enjoy driving? You will need to pay more for this "luxury". Imagine telling your grand kids stories how you were driving cars yourself - manually - and that those cars were burning toxic flammable liquids in their engines. 

Companies like Uber will introduce autonomous taxis. Unlike humans that need to rest (or work multiple shifts), new taxis will be able to work 24/7. Eliminating the need to pay human driver salary will drive the cost of this service down (compared to standard taxis).

The idea of car ownership will change too. On a typical business day I need a car 1 hour in the morning to get me to work and 1 hour in the evening to bring me back home. It might be tempting to become a passenger in the autonomous car and enjoy reading or browsing Internet while this car takes you to/from work. 

After dropping you off at work:
If it is a taxi it will drive to service the next customer. 
If it is your own car - it will either automatically find parking (to wait till you need it again in the evening) or it will join the fleet of taxis for a few hours while you work to earn some money for you.

Buying a new car will be fun! You will go to your favourite car sales web site, search for a model you like, complete the transaction.... and the newly purchased car will automatically arrive to your doorstep. "Beep, beep, I am here!"

Private car sales might change too. It might be possible to complete the transaction online (most likely via some sort of escrow service for added safety). But there will be no need to find time to meet face to face for inspection. The car will automatically drive itself to the mechanic of your choice. You will receive an inspection report online. After completing the transaction the car will drive to your home address by itself.

Parking will look different. It will most likely go underground to save space (no need to have huge surface parking lots anymore). It can become more dense too - there will be no need to open up doors and autonomous cars can be guided more precisely to park centimeters from each other (while eliminating chips and scratches)

The cars will automatically visit service stations for scheduled service or necessary repairs. They will  also be able to go to the car wash service and return back home. 

Crowd-sourced navigation services like Waze work well. But the true potential of this approach will be unlocked when connected cars begin talking to each other and to some soft of a central traffic planning and navigation centre. By knowing current locations, planned destinations, and current road and weather conditions it will be possible to select the best routes and optimise overall city traffic flows. 

Navigation planning and car-to-car communications will allow special services (police, ambulance, firefighters) to command all self-driving cars to slow down and move aside to free up a lane. It will also be possible to isolate a section of the road or an intersection for roadworks so that autonomous cars will find alternative routes.

We will see more and more electric cars on the roads. And electric cars are silent. Car enthusiasts (rev-heads) love the engine sounds (which might become extinct soon). That meaty, low pitch sound of a V8 engine... Sorry turbo fours and sixes - your sound just can't match it. Remember how popular were mobile phone ringtones? I predict that in the near future electric cars will come "equipped" with a few standard engine sounds (mainly for the enjoyment of the driver). And there will be an option to buy and download additional sound packs containing any imaginable engine sounds for a small fee.

As a security professional I can also see the new risks. For example, what if someone simulates an emergency breaking signal? It could just be a harmless prank - just to watch all autonomous cars coming to a screeching halt. Or it can have more nefarious reasons. The bad guys may trick a car stop or slow down in a given location to make it easier to attack it. There have been similar attacks demonstrated recently when a low tyre pressure signal was simulated/faked leading a driver to pull over and stop to check tyres.

Potentially someone could try to gain an unfair advantage by transmitting wrong data - e.g. to free up a lane or get the priority when crossing an intersection.

But all these issues aside, I am excited about the future. And thanks to the grand vision of people like Elon Musk this future is becoming a new reality.

I would like to hear your feedback. What are your thoughts? Do you have a self driving already or are you planning to buy one soon? How do you think the world will change? Please leave your answers below.




at 2 comments:

Thursday, January 12, 2017

Top 10 recommended books for a DevOps manager

I have been browsing Google and Amazon sites looking for new books to read. For those of you who don't know me - due to the nature of my work for the last few months I've been focusing on security engineering but before that, for 6 years, I've been managing a DevOps and Security team. As a side note - combining DevOps and Security in one team is a very smart move. And we were doing it before the industry coined terms like SecDevOps or Rugged DevOps. But this is a topic for another day. What I realised though is that there were plenty of lists and blog posts providing recommendations for DevOps (in general) but nothing specifically targeting DevOps managers. Granted, there will be an overlap. E.g. how can you not mention The Phoenix Project, right? But at the same time the lists for DevOps engineers/practitioners and DevOps managers won't be identical.
In my previous company our CIO recommended (or I would even say - promoted - thank you Ajay!) several books to our IT leadership team. We've read them collectively and it was a very enjoyable experience to discuss chapters with my colleagues. While not necessarily technical books, I've learnt a lot from them as a manager - especially from the point of better understanding the business side.

Let's start:

The Phoenix Project by Gene Kim, Kevin Behr, George Spafford

This is one of my favourite books. I have it both in paper and electronic forms. I remember when I was reading it for the first time I was sharing entire paragraphs and even whole pages with my colleagues. This is how I excited I was and how well this book was resonating and matching my own professional experiences. I finished this book in just 4 nights. I have essentially made it compulsory for my team of DevOps engineers to read it.

Gene Kim is a celebrity in the IT world and you just can't go wrong when you read his books or watch his talks. If you haven't read it yet - promise me that you will read it this year ;)

This book describes the theory of constrains in a modern language applied to the IT world. It is a pleasure (and very enjoyable and light reading) to follow the journey of one company how they go from crisis after crisis to success of a well organised, high pace machine.
Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble, David Farley

Jez Humble is another heavyweight of the DevOps world. This is a highly recommended book for anyone in software or application development.

A large portion of DevOps activities revolves around automating the delivery pipeline.

One of the mantras in our DevOps team was "we cannot be a bottleneck". We should be able to move with the pace of development. And when a developer checks new piece of code in - the expectation should be that in a few minutes a new build will be completed, tests will be executed and this code (automatically!) reach production.

Delivering Happiness by Tony Hsieh

This is not an IT book but something that any manager should read. Tony Hsieh (CEO of Zappos) can be controversial in his approach. As an example, he offers $2,000 to the newly hired employees to resign. Or how about removing all roles in the company operating in a completely flat organisational structure? This is very unorthodox and this makes this book very interesting to read.

The book teaches us to focus on company culture and making customer service the responsibility of the entire organisation. I really liked the "ordering pizza" example. Please read the book to find out what I mean.
Tribal Leadership by Dave Logan, John King, Halee Fischer-Wright


Every organisation consists of relatively small groups of people ("tribes" in this book) and connections/interactions between those tribes. Each tribe has its own culture, which defines the behavior/attitude of the tribe and affects organisation's success as a whole. 

The book teaches us how to diagnose and measure this culture, while defining 5 levels or stages. The most common are Stage 2 (passive, sarcastic, resistant to change culture) and Stage 3 (defined as "We are great, you are not"). 

I was really impressed by the way how tribe's thinking changes as it progresses up towards higher stages. At stage 5 a hospital has cancer as the enemy. They focus on bigger things. They don't think about competitors - they have a much larger goal in mind.

You can also download a free audiobook from the official site
Leaders Eat Last by Simon Sinek

This book is full of inspiring stories. It is a must read if you value supportive culture in your team or the organisation as a whole. Supportive mentality leads to people willing to take more risks because they know their colleagues would do the same for them.

This book is about inspiring trust and commitment.
Site Reliability Engineering: How Google Runs Production Systems by Betsy Beyer, Chris Jones, Jennifer Petoff, Niall Richard Murphy

In this book members of Google's SRE team cover the entire software lifecycle and share their experience of how Google builds, deploys, monitors, and maintains some of the largest software systems in the world.

I would recommend this book to both DevOps and Security teams. Rugged DevOps in addition to fast pace of delivery also focuses on the reliability aspects. For larger IT teams it makes sense to have dedicated SRE teams focusing on resilience of the deployed applications. You will learn a lot about what it takes to run large online systems at scale and how to engineer these systems to maintain tight SLAs.
Release It!: Design and Deploy Production-Ready Software (Pragmatic Programmers) by Michael T. Nygard

This is a book about how to build software for the real world. Developers tend to focus on the positive results - that their code does what it's supposed to be doing.... under ideal conditions. Have you heard the "it works on my machine" argument? The real world is different. Instead of running on a single dev box your code will run in a farm. The server you are running on can be rebooted. A chaos monkey can pick your precious server as the next victim. The database that you rely on can be locked or your long running transaction might be killed. The WAN link you are crossing to reach a legacy corporate system may go down... You could run into so many potential (and sometimes unexpected) failures. If you want to build resilient systems, if you are the one receiving pager alerts at 3AM - this book is for you.
The Innovator’s Dilemma: When New Technologies Cause Great Firms to Fail (Management of Innovation and Change) by Clayton M. Christensen

My previous CEO once said that his biggest fear was being outinnovated. When you are #1 it is relatively easy to defend against the copycats. By definition they will be behind as long as you keep building new products. But there is a risk of a new player disrupting the market and changing the status quo. Worse, you can do everything right and yet still lose the market share.

This book teaches how not to miss or ignore "the next great wave". It was one of the books that inspired Steve Jobs

So here it is - 8 books (a nice round number) that I would like to recommend.

In order to make it 10, I would like to add 2 "honorable mentions"

Good to Great: Why Some Companies Make the Leap and Others Don't by Jim Collins

In this book the author makes an attempt to identify the factors that are responsible for the transition from being good to becoming truly great. They compare similar organisations (e.g. two financial institutions) and then show how one organisation suddenly finds something that propels them to the next level, while another organisation remains the same - good but not great.

I have to admit - I have only completed about 50% of this book. I know for a fact that this is a very popular book, yet it was quite difficult for me to read. I had to set it aside for some time.
The Art of Computer Programming by Donald E. Knuth

Some of you might be surprised by this recommendation. This is an old book. It was quite popular back in my uni days. This is a bible for software developers. It contains LOTS of algorithms for solving various computational tasks. The reason I decided to include it here - too many developers these days don't know the fundamentals. I saw that quite often developers just copy/paste code from MSDN or StackOverflow. By exploring sections of this book and gaining understanding how certain algorithms work, a developer will go a long way in achieving true greatness.


What do you think? What is sitting on your bookshelf? Which books have inspired you? Please leave your comments below and I promise that I will check these books.




at No comments:

Tuesday, January 10, 2017

Android vulnerabilities and market fragmentation

Earlier this week I came across this article and it brought back some of my concerns about the Android ecosystem. The key piece that caught my attention was essentially in the first two lines:
Attackers can pwn 60% of Android phones using critical flaw.
And don't expect a fix anytime soon.
I love (and respect) Android as a platform. I've been using Android phones for a number of years now. Google did an excellent job developing this platform. However, the way how software updates (including security fixes!) are handled by the ecosystem as a whole is just terrible.

A group of researchers measured a data sample of 500,000 Android phones to see if they were affected by the recently disclosed QSEE vulnerability. This vulnerability was published on the 6th of January 2016 and fixed by Google in the January 2016 monthly security update.

From that sample 80% of the Android phones were based on a Qualcomm chipset (the one affected by this vulnerability). And only 25% of these phones had a fix applied, leaving the remaining 60% of all Android phones vulnerable.

The problem with the Android ecosystem is that it is too fragmented. When Google releases a new version of Android (or a fix) it can push/apply it to their own phones but other vendors (Samsung, LG etc) take time to (thoroughly) test the latest code on their phone models to make sure everything works as expected. Many manufacturers/OEMs don't run "clean" Android, instead they (advantages of open source!) make modifications to adjust/tweak some aspects of the Android OS to their needs. The result is - it takes time (weeks, months) for the new version of Android (or a particular fix) to be made available by the OEM.

Then things get even worse - telcos/carriers/mobile network operators ALSO take time to test updates coming from the OEMs on their networks (no one wants to be in the situation when an update kills the ability to call 000 or introduces another serious bug).


As an example, Telstra does a good job updating their customers on the progress of when/how they are going to roll out the "new" versions of Android to various phones:


I have captured this screenshot in May. 8 months later the situation is getting better but I can see that mainly security fixes get prioritised for delivery. This is good! In fact, it is much better than what it used to be. But on the other hand, customer still have to wait for non-security updates, improved functionality etc, and it probably still contributes to market fragmentation (more Android variations to support).



I think most of the manufacturers and carriers are stuck with the mentality that people buy phones on a 2 year plan, use this model for 2 years and then upgrade to the next model. They are not software companies (i.e. they don't understand or don't have capacity to implement/follow the fast software release cycles). I guess it's OK to work on a new hardware model for a year. But it's a crime in a modern software agile world. And on top of that there is no incentive to update to the newer versions - OEMs have already received money for the phone (hardware) and the carriers are guaranteed to receive a certain amount every month for 2 years in most cases.

All of this is the main reason why I've been using Google Nexus phones for several years straight (from the 2011 Google Nexus model all the way to Nexus 6P). These are Google's flagship phones and I agree with the Amazon's 4.5 stars rating. These phones are produced by different manufacturers. As an example - Nexus 6P was made by Huawei, while the previous Nexus 6 version was manufactured by Motorola. But hardware design, specs, and software updates are all controlled by Google. Once a new version of Android is ready, unlocked (i.e. not sold by a particular carrier with a SIM card locked to that particular provider) Google phones receive them first. This is a guaranteed fastest way to receive the update - a matter of a few days maximum. For other phones it may take weeks or even months. Or they may never receive an update leaving these models permanently vulnerable. This is the reason for the 60% mentioned at the beginning.

I am sure Google engineers are aware of this challenge and doing their best to improve it. I can certainly see positive changes already taking place. From the late 2015 Google started publishing monthly security bulletins. These updates get pushed to the Nexus phones straight away. This is a massive improvement compared to the situation when we had to wait for months for these fixes to be incorporated into the next version of Android (leaving all phones vulnerable).

The newest Google phones - Pixel and Pixel XL - is the continuation of the Nexus theme but with even more (end to end) control from Google. This is a great way to reduce market fragmentation. I am surprised by the average ratings on Amazon. I loved every Nexus phone I had. And I am sure Pixel won't disappoint too. If you are thinking of getting a new phone and if you care about security - give it a go. You will get great hardware, modern mobile OS and the best security of the Android ecosystem.

If you are an Android user - which phones do you use and would also recommend to your friends? If you use an iPhone - would you consider Google Nexus or Pixel phones after reading this blog post?

Please leave your comments below and I promise I will answer all of your questions

at 2 comments:

Friday, January 6, 2017

New Year's Eve Fireworks 2016-2017 in San Francisco

Happy New Year to all my readers!

This is my first New Year celebration in America. And, unlike my previous years, this time I celebrated it outdoors. In fact, I was in the very heart of San Francisco - next to the Bay Bridge.

The Bay Bridge looks great on any given day but it looked absolutely gorgeous on that frosty night! And look at those reflections in the water!

This is a static picture but I just have to mention that those lights on the bridge are dynamic. There is some kind of light animation constantly happening there, which makes it even more fascinating!

There were a LOT of people on the streets of San Francisco - all happy and cheerful, waiting for the main event - the fireworks. One of the surprises for me was the marijuana smell. It was EVERYWHERE. It is not illegal anymore in California and I have to say I felt that distinct scent every few minutes.




People were wandering all around the City (or the Downtown as it is called here). But around 11PM everyone moved closer to the river to watch the fireworks.

I have captured lots of photos, which I would like to share with you. Please don't judge harshly ;) I was capturing these views with my mobile phone and the only processing that I've done was to resize the original images. I just want to share the atmosphere, that moment in time and the feeling of the celebration.





















I really enjoyed this show, which lasted for approximately 15 minutes. I think it is on par with what I've seen in Melbourne. But the fireworks in Sydney - thanks to the backdrop of the Sydney Harbour Bridge. the Opera House, and the overall layout of the bay - usually looks more impressive. Anyway, let's start the year with this lightweight blog post. I am wishing you all the best in 2017!

Dmitry


at No comments: