字幕列表 影片播放 列印英文字幕 WAYNE PIEKARSKI: Welcome to the Fireside Chat for Brillo and Weave. I hope you've had a great day seeing all the talks here at the Ubiquity conference. As you can see, we've had a whole bunch of really cool information just come out today about Brillo and Weave and all the exciting possibilities that it has. My name's Wayne Piekarski, and I'm a Developer Advocate at Google. I work with the product teams to communicate information to developers and also feed information back to the product teams to help make our products better, and so forth. So we all work together, and we run events like this, and so we hope you found it very useful. What we thought we'd do is have a session where we can sit down with some of the important people on the Brillo and Weave team-- talk to them about what makes them do the things that they do, and what they find interesting, and what kind of ideas that they have. So today, we have three speakers. We've got Ryan Cairns, we've got Paul Westbrook, and we've got Guarav Shah. And what I'll do is I'll start off by just asking them to say a little bit about what they do at Google and what their important role is. RYAN CAIRNS: Sure. My name's Ryan. I'm an engineering director. I run the Brillo and Weave project. I started the project about three years ago. And I take care of all the engineering stuff. PAUL WESTBROOK: My name is Paul Westbrook. I'm the engineering lead of Weave. We're focusing on the mobile device side and server side of Weave. GUARAV SHAH: Hey, I'm Guarav. I'm the engineering lead for Brillo. WAYNE PIEKARSKI: Cool. Thanks. I was hoping with the Fireside Chat, we'd have an actual fireplace here. But we don't have that. They wouldn't let us run a fireplace screen on this thing. Anyway, today we had the little pet feeder during the keynote. That's something where I was like, you know what, I really want this pet feeder, because it solves a problem that I have. And so I thought it would be a really cool question to ask. What magic device have you always wanted that, now that we have Brillo and Weave, you maybe could build-- or someone else could build-- and sell it as a product or whatever? What's something that's exciting? Guarav? GUARAV SHAH: I guess my dream project is, all the walls are screens, and it's easy for me to project anything on any of the screens, or rather, the walls. So that's what I would like to be able to prototype. WAYNE PIEKARSKI: I guess some of these little boards were giving-- they have like, little HDMI ports on them, so you could do something like that pretty easily. GUARAV SHAH: Absolutely. And you can also drive LEDs and LCD screens via the [INAUDIBLE] WAYNE PIEKARSKI: Yeah. Actually, one of my colleagues had this cool project where they were controlling strips of lights and they were blinking, all kinds of things. And there's all kinds of cool possibilities of little things you can do that doesn't require a massive screen, but you can use really cheap little components to make something interesting. GUARAV SHAH: Yeah. Definitely. You can daisy chain them, and yeah. Pretty exciting. WAYNE PIEKARSKI: Cool. What about you, Paul? PAUL WESTBROOK: One of the things that I want to build is something to control my garage door. Because oftentimes, I will-- I'm always worried about leaving it open. RYAN CAIRNS: Well, then you just drive your car and come back home and check again, and then drive off. Right? PAUL WESTBROOK: Well, that, but then-- you're wasting gas. But the other thing is making sure the lights turn on and off, especially to detect presence. WAYNE PIEKARSKI: I was thinking I've always wanted something where it's like-- what's the state of all the doors? Show me every time they opened, show me a log or something interesting like that. Because the door may have been opened unexpectedly or something like that. Yeah, it's interesting. What about you? RYAN CAIRNS: For me, it was really-- I was working on Chromebooks at the time, and we were doing a bunch of Wi-Fi stuff. And I really wanted a Wi-Fi router that was easy to use. So I'd kick that product off. And then, beyond products, one of the reasons that we did Brillo and Weave in the first place was we just saw people wrestling with the same set of problems over and over again. Google was getting into doing hardware. Everybody was fighting to figure out, OK, what Wi-Fi solution do I need to use? What Bluetooth solution do I need to use? How's auto-update going to work? What's my security story? And we already solved a bunch of that stuff, so we were looking at, how do we package that up for people? That was really my goal with this. WAYNE PIEKARSKI: Yeah. Security is an interesting thing. Because I always have this terrifying thought of, well, if my heater is controlled by my computer, and someone hacks into it, they can set my house on fire or something like that. So security seems a really big deal that you really have to get this right. And so, what kind of things are we doing to make sure that security-- because it seems like that's like the number one priority for a lot of things nowadays. So what are we doing to make it really awesome? RYAN CAIRNS: There's a few things. At a high level, we're working on some platform security features in the OS, and we'll let Guarav talk about that in a second. We're enabling software updates, because we don't think that you can have a security solution with devices being fixed in the field. You always need to be able to push new code to them. And then on the Weave side, I'll let Paul talk to what we're doing about local authentication and things like that. GUARAV SHAH: So yeah, I can speak to the Brillo side. Interestingly, before I was working on Brillo, I was working on Chromebook security. And we ended up designing a very defense in-depth model for building a very secure device. And that's pretty much been verified time and time again based on various security competitions and intrusion detection-- the performance of Chromebooks at these kind of events. So for Brillo, I think there are a couple of things that are in boat on the platform. So verified boot, which makes sure that you're not running malicious code on your device. I think that's a core part of the security, and we talk about verified boot starting from when your device boots up, so all the code that runs is verified. Then the other thing that you want to enable is, we want to enable sandboxing and other mechanisms that are default on and that are very easy to use. So we have kind of build a lot of the same technologies that Android already has, plus some of the things that we designed for Chromebooks, like second BPF and other sandboxing mechanisms. These are a core part of Brillo. The final part that Ryan alluded to is updates. We really feel that updates are really a core part of building a secure device, because anything you build, any software you write, it's always going to have bugs. And being able to update this device in the field, and doing so in a way that is very seamless, non-destructive, error-free is very important. And so update is a core part of Brillo security as well. WAYNE PIEKARSKI: I guess one other thing is that a lot of OEMs will make a device, then they just forget about it, whereas at least Google does some of the work of doing the security patches. And you can just pull down updates and build it out without having to have your own team maintaining all these. You don't have to worry so much about security. GUARAV SHAH: Yeah. I think a large part of why we don't see a lot of updates happening in the field is that it's kind of always the device side, the device software. But there's also infrastructure for running updates, for actually serving the updates, for managing updates. And with Brillo, we are making that something that is the same infrastructure that we use in Google, for Chromebooks and other devices, and we are making that available for developers to use for their devices. So I really feel like that really makes updates a no-brainer, if you're building a connected device using Brillo and Weave. WAYNE PIEKARSKI: See, I've got to focus on feeding dogs. I don't want to worry about all that stuff. RYAN CAIRNS: Just to add to the update story-- one of the big things is like, when people are shipping devices that don't update themselves-- the whole internet is moving forward all the time, right? People are building new code. So those devices are just going to break over time. They're going to bit rot. The user is going to buy an experience today, and in a year, that experience is going to be broken. And what we really want to enable is an always up-to-date, always working experience, for devices that get better, as opposed to degrade over time. WAYNE PIEKARSKI: Yeah. You want to say something, Paul? PAUL WESTBROOK: Yes, I was going to talk about the Weave side. WAYNE PIEKARSKI: Sure. RYAN CAIRNS: So on the Weave side, one of the benefits of it is actually dealing with the Google Clouds. So the devices themselves actually have a secure connection to the Google Cloud, so they can ensure that the commands that are received by the device are actually authenticated to come from Google. And then also, the other part is actually the authentication, or actually, the sharing model. So the user has ultimate control over which user, as well as which applications, have access to their device. And so then they can both grant access as well as be able to revoke it, in case there's a bad actor or some behavior that's actually not expected. WAYNE PIEKARSKI: Well, that's the thing. I mean, there's the possibility of bad actors at so many places in the chain that it's very important that you secure everything. You can't just get away with having some parts secure and some parts not. PAUL WESTBROOK: We agree. And in addition to the cloud connection, Weave also has local authentication. So when commands-- like for example, let's say the internet connection goes down. So commands that go between a phone to a device, we can still ensure that that communication is secure as well. WAYNE PIEKARSKI: Cool. So one question I hear people ask me every so often is, so we've got Weave. And then we have Nest, which have their own IoT story as well. So how does the whole Weave story fit in with what Nest is doing right now? RYAN CAIRNS: They're different product experiences for the consumer. From a technical perspective, we're very compatible. In fact, we're trying to offer Thread in Weave on top of Brillo, so that people who want to build works with Nest devices with Brillo are able to do that. So with Thread, you've got layer 2, layer 3. With Weave, you've got higher-level protocol. And with our Weave, really the idea was to tie in the mobile experience with the device. So we wanted to focus on gateway protocols instead of focusing on more edge-oriented protocols, so that we could leverage the technologies that are in the phone-- so primarily Wi-Fi and Bluetooth. WAYNE PIEKARSKI: Yeah. OK. Anything else? PAUL WESTBROOK: In addition, as some of the previous talks mentioned, about the schemas-- so we've been actually working with Nest, too, on the device model schemas. So there's a consistent model for actually representing devices across both platforms. WAYNE PIEKARSKI: OK. Cool. Another question people commonly ask me, which I thought I'd bring up here as well as that there's lots of IoT devices and microcontrollers and kits and different ways of building little apps that flash lights and things like that. So how does Brillo differentiate itself from there? It seems like the market is quite saturated with different projects and companies. So what are your guys' thoughts on that? RYAN CAIRNS: Yeah, so the thing that we found with a lot of these other platforms is that they're really great experiences for trying something out, prototyping, having some fun on a weekend. But when you go to commercialize a device or take it to manufacturing, there's a lot of challenges. Right? Then it's not easy to do out of the box. And what we have is a system that you can take all the way from the prototyping stage-- where you've got a bunch of dev boards that you can buy, when you've got new silica, and it's very easy to move your project to a new board without much code change-- and take that all the way through the manufacturing process. And I think that's a key differentiator. WAYNE PIEKARSKI: So how does that work? So the manufacturers have some ability to customize them, or? RYAN CAIRNS: No, it's more about being able to work with the silicon vendors and tap into the hardware ecosystem so that you can have a common bit of code, and then go to a Qualcomm, or a Marbel, or Mediatech, or an Intel, and get a BSP from them. WAYNE PIEKARSKI: So they provide the support package for their particular processes, whatever. So then you can make your own board, and then drop their processor, and they've ported the kernel over, and the drivers, and all that kind of stuff. RYAN CAIRNS: Exactly. So you're not tied into the platform that you ended up prototyping with. You can go talk to anybody, whether it's Imagination or Intel or-- WAYNE PIEKARSKI: Mhm. OK, cool. Right now, I guess everyone got their little kits to work with. Some people got DragonBoards, some people got Edisons. The cool thing about them is they're very similar, the build process is the same. RYAN CAIRNS: And over time, as people build these devices, we anticipate that they're not actually going to build one. Right? You're going to be successful. You go out this year, you have different silicon than you have in the next spin of the product. And the code, maybe, is the same, and we want to make sure that your projects can-- you can have the same project on top of multiple boards that you've shipped, so that you don't end up with a morass of all this code that you have to maintain for basically different spins of the same project. WAYNE PIEKARSKI: Yeah. So in the past, when someone made a router or a light or something like that-- so what, they had teams of people who had to have kernels, and what's the difference from before till now? Now that we've got Brillo and Weave, this is the workflow. How complicated was it before? Do you want to explain how much people you needed to have to build a product? GUARAV SHAH: I think-- the development model was very specific to the board, and it was pretty much throwaway work. So let's say that you are trying to build a router, and you started on a particular chipset. You decided to move to a different chipset. It's just going to mean a completely new code drop, and you're going to start from scratch. You're going to rewrite a large number of portions of things, because you don't have things like a HAL. So the hardware is not abstracted. So you're writing a better software, but you're also writing a better software that is very much dependent and makes assumptions of the architecture it's running on, on the specific details of the hardware. And I think one of the things that we're trying to do with Brillo is to make that to abstract away those interfaces, whether it's things like various hardware peripheral interfaces, or it's like, how do you configure your [? kung ?] specific features, or APS for dealing with sensors, for example. So we're trying to abstract away these details so that when you're writing your code, you don't have to make assumptions about the various hardware implementations. WAYNE PIEKARSKI: Yeah. Yeah. It sounds like a nightmare where it's like, a kernel bug comes out, so they might patch in a Linux kernel or something. But then you don't know it's there, or you don't know what version you're on. You might not follow it. So if you forget to pull those patches, you got all these vulnerable devices that people don't know about, it's just-- yeah. And if you've got a billion devices out there, and you need to keep them up to date, if you missed this patch, then it could be catastrophic. RYAN CAIRNS: Right. And what we're trying to do is create a center of gravity for all these BSPs upstream in our repository so that when these bugs get found by the vendor or by us, they could get fixed in one place, and then everybody can then pull from them for their own individual products. WAYNE PIEKARSKI: Yeah. Cool, cool. Nice. OK. We have the audience here. We have a microphone floating around somewhere here, so if anyone has any questions you'd like to ask of the team-- do we have a mic somewhere? RYAN CAIRNS: We've got two mics in the back on the ends out there-- WAYNE PIEKARSKI: Yeah. In the corner of the room, we have a mic there, and a mic there. If you had a question, we'll see what we can answer for you. AUDIENCE: Excuse me. So if I understand correctly, you want us to make our devices available on Weave or through Weave, but Google itself will not make Nest available through Weave? Because it's special? I don't understand this. WAYNE PIEKARSKI: This is more about the Nest experience. So what does it mean-- RYAN CAIRNS: Yeah, we're working with the Nest team to try to make Nest available through Weave as well. The big thing today is that they're different because we're different teams, and we're trying to align those things. Like Paul said, we're working on shared schemas so that the developer experience for a Nest device shouldn't be different than developer experience for the same, like kind of Weave device. AUDIENCE: So it will become available through Weave? RYAN CAIRNS: We'd like to. WAYNE PIEKARSKI: I guess the thing with Weave is that right now, we have specs for it. There's all these different device types. I can't remember off the top of my head. Do you remember? It's like light bulb, and-- PAUL WESTBROOK: I can briefly talk about the schemas. So we actually have some device guides that actually talk about light bulbs, and air conditioners, and a number of other things. But the one thing about the schemas is actually, they're composable. So we actually take the individual traits of, let's say, a light bulb may be dimmable or not, or have color or not, and a hardware maker should be able to take the individual components that they want and actually define the behavior that actually corresponds to their device. So yes, we do have device guides, but we also define the schema as individual traits fit. RYAN CAIRNS: We're also trying to work to align the Nest cloud and the Google Cloud, so that developers can work with both. WAYNE PIEKARSKI: The other cool thing is that, with these schemas, if you build a device that implements the light bulb schema-- anyone can write an app that controls light bulbs. And anyone can write an app that controls air conditioners. And the app doesn't have to be tied to that device. It's kind of nice. Because you could have a house with different light bulbs from different companies, and they can all talk together, which is sort of a new thing that-- I think someone talked about it today, earlier, during one of the talks, which is, you want to be able to make these things all work together. You come home, your light bulb turns on, your doorbell is synced to it, your music starts playing, things like that. So people have the ability to build these kind of cool, combined experiences that has been very difficult to do before. PAUL WESTBROOK: Personally, I'm very excited about some of the opportunities that app developers have now. I mean, being able to actually combine these capabilities into a single experience. WAYNE PIEKARSKI: Yeah. Do you have any things that you're excited about in particular? Is there a particular kind of scenario or demo that you want? Because I'm sure someone will have one of these built by the end of the code lab tomorrow. PAUL WESTBROOK: OK, so this is what I want. For example, I think being able to unlock a door and actually have your lights turn on automatically for you, or based on the time of day, have different behaviors. I think there's a lot of experiences, especially across different manufacturers, to be able to actually have the consumer not have to worry about buying one particular brand of a product, and be able to actually have it work on multiple brands. WAYNE PIEKARSKI: The other thing is, because this is a ubiquitous computing conference, and we're talking about many different areas-- so beacons could be combined with this, like a beacon can announce presence. You could have a beacon on your key chain, or you could have one in your car or something. And then it's possible for your phone to detect, OK, I noticed you've just gotten out of your car, but now you're approaching your house. Or Wayne has come home, or Paul has come home, or whatever. And you can detect different things. And you have different theme music on. So when I walk in, I can have my theme music. Actually, I remember I went to a conference once, and this guy was talking about this concept of playing theme music whenever he came home. RYAN CAIRNS: What would your theme music be? WAYNE PIEKARSKI: I-- Wait a minute, I'm asking the questions here. What's your theme music? RYAN CAIRNS: I have no theme music. PAUL WESTBROOK: But I could imagine using the beacons to actually detect presence in the room and actually turn on and off lights, to actually control the air conditioner fans. There's a lot of opportunity, especially being able to talk to devices as well as detect. WAYNE PIEKARSKI: What I want to do, actually, is I want to put a beacon on my dog's collar. And then, I have a sensor on my couch that detects when they get on the couch. And then it sets off an alarm or something like that. Because I actually have a legitimate problem with this. A lot of my ideas that I build are actually problems that I'm trying to solve for myself, but I turn them into work problems, so then I can write blog posts about it and stuff like that. But my current challenge is a couch detector or something to keep them off. Because it's actually really hard. And I would love to buy something like this. And like a trash can that detects when it's been popped open incorrectly when the dog sticks his head in there to pull food out, you know? All kinds of-- yeah, the internet of dog products. It's exciting stuff. RYAN CAIRNS: I was going to add, the big thing to me is that we don't make end users programmers. Right? Like I want to buy all these products, I want to bring them into my house, I want to do different things with them, but I want those experiences to be suggestive. I don't want to have to think about, OK, how am I going to combine these things? WAYNE PIEKARSKI: Yeah. I was thinking a lot of people don't know-- they want to have a good time, but they don't know how to code. And you don't want to have a "if this, then else" type scenario. And I guess that's where Nest has been successful-- this thermostat. And it just does the right thing. And you play with the thermostat, but it's not a traditional, set-the-number type thing. It tries to look at your patterns. And I guess now people have the opportunity to build exciting things like this. But that's the challenge now. And so we've had a bunch of talks about machine learning and TensorFlow and all these other things today. I guess the thing with ubiquitous computing is we're combining all these different areas together. So you've got your air conditioning, you've got your car and your-- but you can use machine learning algorithms to study patterns and try to do the right thing for the user when they want it. And we have a question in the back there. Yeah. AUDIENCE: Hi there. I hear a lot of you talking about both Brillo and Weave on setting state, on, "This will turn a light on." "I will know when a light is turned on." I'll have all of these things. What I'm not hearing are the inputs for some of them. So I'm not hearing, for example, how to use Weave to create the light switch-- just the switch part. I kind of have an idea on how Weave would do that on sending it, but not how that switch would say, OK, this person has now toggled-- this person's now issuing showing a toggle command. Or even on the Weave side, how to read for a toggle command. So that's what I want to hear more about at this point. WAYNE PIEKARSKI: Yeah, that's a good question. Yeah. PAUL WESTBROOK: Sure. I can start with the Weave side of this. So as part of the schemas, like for example, let's take a light switch, for example. The schema for a device actually represents a couple of different things. One is the commands that it can handle, and the second part is actually the state that it's currently in now. For example, an application or a service can actually watch the state and actually watch state transitions and potentially use that as a trigger to perform some action. Whether the action happens to be another command or happens to be-- whatever it wants to be. The other part is actually the commands. For example, in order to issue a command to a device, there is some schema and so applications would have to actually do that. So in the case that you gave, like for example, a light switch, I would imagine-- this is just off the top my head-- I would imagine a light switch would actually define a state which is on or off, maybe its brightness if it's a fancy light switch. But it would also represent a command. And so I would be able to issue that command to that light switch to actually trigger that. That command would actually affect the state. So then the application, in addition to actually controlling the voltage of whatever was connected to that thing, it could also-- applications could watch that state change. AUDIENCE: Well, but the problem is that whatever is connected to that thing is another, completely separate Brillo device. So really, I now have a virtual switch and a virtual light, and somewhere I need to make the connection that says, when I toggle any of these three switches on different sides of my dining room, my dining room light needs to turn on. And I can see how each individual part of that works, but I can't see how it comes together. RYAN CAIRNS: So the first kind that we have is very much phone-to-device, but we're also working on triggers and signals, which we haven't rolled out yet. AUDIENCE: OK. RYAN CAIRNS: And that'll let you do things like-- WAYNE PIEKARSKI: That's the glue. RYAN CAIRNS: --the device-to-device stuff, what you're talking about. Like I flicked this device, now I need to go send a message to these other things to go broadcast what changed. Or somebody might have to subscribe to something and say, oh, this state changed. How do I take action on it? We're working on rolling that stuff out. It'll be a little bit, but stay tuned. WAYNE PIEKARSKI: I guess the thing, also, that's important is that the Weave API is a very cross-platform. They work on iOS, Android, web-- have I missed anything? Yeah, they work across most of the major devices. So it's nice, because you're not restricted to just forcing it to work on a phone or anything. You could build something that runs on a server in the cloud somewhere or whatever. OK. While we're talking about light switches and stuff like that, what kind of markets are you guys excited about for different-- what are the big areas you think are going to be huge? RYAN CAIRNS: We're doing a lot of consumer stuff right now. We're talking a lot about home automation. And I think the opportunity here is a lot bigger than just home automation, which I think is a really interesting vertical, but not the whole pie. The thing I've been telling the team is like, think about how we put a computer in every device, and what does that look like? And I think there's a lot of scenarios like smart cities, like parking meters and things like that. There's a lot of industrial use cases. There's a lot of, potentially, healthcare use cases-- I don't know if we're going to get into that or not, but definitely a lot of potential to put computers in things. And interesting problems fall out. And I think we can-- WAYNE PIEKARSKI: Yeah. Well, that's the thing with software-- not everything is about consumer devices. There's a lot of companies that do contracting work, who-- they're asked to build infrastructure, to put a smart meter in every house to measure its power usage or something. And those kind of things will all be useful for that too. RYAN CAIRNS: One example would be cars, right? Everybody thinks about cars in terms of, oh, you're going to put a computer in the car, navigation system, infotainment, that sort of stuff. And that's great. I think Android Auto is pretty awesome. But there's all of these other subsystems inside of cars, too, that we don't address. For instance, in a Tesla, they have an NVIDIA Tegra processor just running the gauge cluster, that's doing some basic graphics for things like speedometer and end user input and things like that. And there's all sorts of other subsystems too. WAYNE PIEKARSKI: Yeah. Earlier, we talked about displays. So the little Brillo boards that have an HDMI output-- what kind of hardware do they have for graphics rendering? Do they do open gel, or? I'm not sure, actually. GUARAV SHAH: Right now, graphics support is-- we can support very basic, non-x related graphics. But we're working on it. But nothing to announce right now. RYAN CAIRNS: The goal is to be headless, for the short term. WAYNE PIEKARSKI: Yeah. Well, that makes it really low-powered. Although those boards are really powerful. They're almost the same chip as in a cell phone, basically. RYAN CAIRNS: Right. A lot of that comes from the fact that we were trying to get something to market quickly. And Qualcomm and all of our other partners wanted to put out a very full-featured set of boards so the developers have access to everything. And the goal would be you start with something like that, that's geared towards a cell phone, and then scale it down. WAYNE PIEKARSKI: Yeah. Yeah. OK, cool. Any more questions? One in the back there, yeah. AUDIENCE: This is going back a little bit, back a question or so. So my use case is, I just got the word, I'm heading into Tier 3 from PG&E. My question is, who's responsible around here? That's a historical question. Where does Weave run when you have a question about a number of devices that are all secondary devices? They're power users. And I can get how much power they're using, but where do I put it? Do I have to throw it all the way back to the cloud, and does that scale? Really? If it's a local resource, is it a capable device? A capable thermostat that it would run on? Or some kind of neutral gateway device? WAYNE PIEKARSKI: It sounds like there's logging in here. Where would we put that? AUDIENCE: Yeah. I do historical log-- I log continuously. PAUL WESTBROOK: Just to make sure I understand the question correctly-- you would like to create a device that actually tracks the power usage at your house, or you want the power usage of the Weave devices? AUDIENCE: Oh, of the lights and the appliances within the house, not the-- WAYNE PIEKARSKI: He wants to find the culprit. RYAN CAIRNS: You're aggregating everything. AUDIENCE: Yes. Yeah, and recording it piecemeal. PAUL WESTBROOK: Sure. This is possible to do with Weave. One thing that you can do is actually create a Weave device that actually aggregates this and actually represents this power state as state changes. And you could actually decide-- if you don't associate that device with the cloud, then that logging would actually remain local, and you can continue that. Or you could actually associate that with a Google account, and then that would actually then propagate to the cloud. AUDIENCE: OK. And this would not be a smartphone platform. This would be a permanently resident device within the home, perhaps DSL modem, an augmented gateway device. Weave capable. PAUL WESTBROOK: OK. So there is a hardware device that's in the house that would actually gather this information? That should be definitely doable with Weave, as well as that could run Brillo, as well. RYAN CAIRNS: It's in the things like the data retention policy, and how much you upload to the cloud, and how long you keep things uploaded to the cloud, and who's allowed to see it, and things like that all come down to sort of both OEM preference and probably user preference. And depending on who made the metering, or what the user wants to pay for, or what the economics of the situation are, the device maker, I think, would come up with a suitable policy there. But we should be able to have a lot of flexibility in the platform to be able to do different things for that. WAYNE PIEKARSKI: The devices can be shared, too. Like if you came over to my house, I could say, hey, I'll share this device with you, so you could feed my dog or something like that. So you can give access to other people for the device-- PAUL WESTBROOK: That's correct. And even sharing devices, not even necessarily for functional, but for viewing access. So, for example, in the case of a power meter. Let's say, for example, I want to share this device with my wife so she can see how much electricity we're using at home. That's also possible as well. WAYNE PIEKARSKI: OK. And we have another question over there. AUDIENCE: Yeah, I got a couple questions. Just really simple is, what Android version is Brillo based on? And then is there any plans to bring that modular update architecture to just standard Android on phones? So I don't have to wait like a year for the Marshmallow update on my phone? WAYNE PIEKARSKI: OK. RYAN CAIRNS: So nothing to say about updates on Android, but we can tell you what version. GUARAV SHAH: It is based on the latest AOSP sources. In fact we do all our development in open source. And we do it regularly, not just code drops. RYAN CAIRNS: Yeah, we work in the open. GUARAV SHAH: In terms of versioning, I think one thing to keep in mind is that we're not using the same version or numbering scheme as-- WAYNE PIEKARSKI: Yeah, it's not like KitKat, Marshmallow-- GUARAV SHAH: Yeah. And that's just because all our development is in AOSP. RYAN CAIRNS: Having said that, we don't want to encourage people just to take random snapshots of AOSP and push them to users. We want to have some well-defined releases, but we want to do it at a more granular level than what Android does today with the dessert releases. AUDIENCE: And also my second question is, what's in it for Google, or what's your monetization strategy? Is there some kind of licensing that you're doing for hardware manufacturers, or are the app developers going to have to pay its licensing fees, or what's up with that? RYAN CAIRNS: So we're not taking a license fee. When I think about what's in it for Google, especially when people ask me at Google, what's in it for Google, the answer is, we have a lot of Android developers. And we have a lot of developers that we want to make sure that they can program against the physical world. This is one way to do it. We also have a lot of services, and our developers build a lot of services, and we want to create a platform where both our developers and us can easily distribute our software on top of. And I think, by doing that, that creates a lot of future monetization opportunities for both Google and our developers. WAYNE PIEKARSKI: That's also why we're running this conference, I guess, is it's part of all the different products. They all sort of fit together. You've got Brillo and Weave and beacons and wearables and all these different things, and they each bring a piece of the puzzle that-- they can't all solve the puzzle by themselves, but combined together, they do very interesting things. Like you said, there's all these Android developers. That gives them new capabilities and things like that. AUDIENCE: Awesome. Well, thank you for that. The other guys are doing pretty much the exact opposite. So thanks. WAYNE PIEKARSKI: Thank you. Question over there? AUDIENCE: Yeah, I had two different questions. The first one is, considering that Weave is a crucial part of the infrastructure in communications, what is your target SLA for it? And if there's any sort of queuing in case of an outage or any sort of downtimes? WAYNE PIEKARSKI: I missed the last part of the question, but-- PAUL WESTBROOK: Yeah. Would you mind repeating the question? AUDIENCE: Just, what would be the SLA of the Weave services as a whole in the cloud API side of it? And is there any sort of road maps for queuing or any sort of contingency plans when there is an outage? PAUL WESTBROOK: Google services are-- the Weave service is running in our backend. I don't know if we publicly say SLAs. RYAN CAIRNS: Yeah. Being that this hasn't been fully released to everybody yet, I think we're holding back what our SLAs are. But-- WAYNE PIEKARSKI: Yeah, right now it's a developer product. So please do not build a nuclear reactor or anything important with it. Because that's not cool. It is beta software, so please treat it accordingly. RYAN CAIRNS: Like any Google product, we're all carrying pagers. And we're all trying to get latency down. And we really care that 90th percentile is really fast and their uptime is really high. Unfortunately, I can't quote you an exact number right now. AUDIENCE: Fair enough. Yeah. The second question is, the whole movement of Brillo Weave is about interoperability, ability to connect everything. But the realistic sense is that there are several other IoT-based platforms out there. And for you to expect a consumer to only use Brillo or Weave-connected device is probably unrealistic. And is there any thoughts-- and this is not any plans or anything like that-- any thoughts from you guys as far as any future plans or talks or discussions with other major partners or players out there for interoperability between platforms? PAUL WESTBROOK: At least from the Brillo and Weave point of view, we're open. For example, if a OEM wants to make a Brillo and Weave device, we're not going to prevent them from integrating that device with any other platforms. AUDIENCE: Thank you. WAYNE PIEKARSKI: Another question over there. AUDIENCE: Just curious for your thoughts. Let's say that I'm a device manufacturer, and I'm deciding what platform to build my new device off of. I'm kind of curious what your thoughts on the story would be that you would tell. Why would I choose to build on Brillo, say, as to just putting together a set of yocto patches or some other embedded Linux system? Is it just primarily the Google services, the over-the-air updates metrics, that sort of thing? Or are there benefits to, say, using the Android stack, or other things that you see bringing an advantage to a device manufacturer over something like that? RYAN CAIRNS: I think a few things. I'll take a couple, and then maybe Guarav can chime in. But the one I think of most is the Android hardware ecosystem. It's very easy to go to any silicon vendor who's supporting Android and say, give me a Brillo thing. And the second one is, obviously, the services that you mentioned. There's a lot of stuff like updates and analytics and things like that that you get from Brillo that you don't get in other stacks. Guarav, security? GUARAV SHAH: Yeah. I think security developer experience, hardware ecosystem-- yeah, I think that covers it. I think we're also very proud of the services with respect to analytics and updates. I really think we have the best of the great there. AUDIENCE: Thank you. WAYNE PIEKARSKI: Over there? AUDIENCE: Yeah. I'm pretty sure this is more of a manufacturing concern, but we talked a lot about security. How about safety? Like when you define the schemas or whatnot, are you concerned? Like I might turn-- a user or a developer might turn on the thermostat to like 160 degrees rapidly, or even other things like that. PAUL WESTBROOK: That's kind of hot. I think there's a couple things. One is, we are working with the OEMs and the hardware makers to actually define the schemas. So there's going to be-- the schemas also support limits and ranges. For example, let's say if all manufacturers agreed that-- I'm just going to pick a thermostat-- say, that 160 degrees is too hot. There would be some agreement, working with all the manufacturers to actually have some fixed limit. But ultimately, the hardware maker is the one that's responsible for making sure that the hardware actually functions correctly. I think that whether it's actually through Weave or someone just spinning the dial too far to the right, the device itself should behave correctly. WAYNE PIEKARSKI: That's something else to think about. Because when I was building the dog feeder, one of my concerns actually is that if the dog feeder fed continuously that entire tub, it can actually kill a dog. I've actually taken my dog to the ER twice from eating too much. They will eat too much. I couldn't believe it, right? Cost me $500. But anyway, the point is that I was like, well, if the software fails, or if a wire shorts out, or something, you really have to build multiple layers of protection into the device. So maybe with the switch that runs the paddle feeder, it should say, well, if the switch ticks more than four times in a second, you should shut down. And if this happens, you should shut down. You could have all these extra safety features in hardware as close to the metal as possible to shut it down and put it in a fail-safe mode so that it fails gracefully, because putting all the food out is unacceptable. It's like an airplane shutting its engines down if it doesn't know what it's doing. You've got to design the hardware in a way that really tries to think about, what's the worst case scenario, and what can I do about it? So like if it had a 160-degree thing, you'd have a thermal fuse that melts at 150 to stop it from getting to that point. Have multiple levels of protection, and don't just rely on the software somewhere else. Because the user, if they set the dial, then it would be kind of crazy to allow them to do that. RYAN CAIRNS: Yeah. We certainly can't design Brillo and Weave to deal with operator error or malintent from the hardware or things like that. WAYNE PIEKARSKI: Well, that's the thing is that there might be cases where you want to set a thermostat to 160 because you're building an industrial oven or something, and that's a desirable outcome. So you've got to make sure that-- the designer still has to think about these things very carefully. Any more questions? Yeah. AUDIENCE: Was that dog that overate different than [INAUDIBLE]? WAYNE PIEKARSKI: A fellow Googler from the San Francisco office had that dog. My dogs are at home, but different dog. It's a constant challenge. And it's a great motivator for coming up with innovations. AUDIENCE: Early adapter dog. WAYNE PIEKARSKI: Exactly. Exactly. Yeah. RYAN CAIRNS: I got to say, I hope you guys are learning as much about Brillo and Weave as I am about Wayne's dogs. WAYNE PIEKARSKI: I gotta write a book about them one day. Yeah, question. AUDIENCE: So I haven't heard much mention of this, and I don't know, it's kind of early, but I was wondering what the pricing model for [INAUDIBLE]? WAYNE PIEKARSKI: All right. Just to repeat the question-- for anyone else who has questions, if you could go to the mics. But the question was, what's the pricing model for the cloud services and things like that? RYAN CAIRNS: TBD. Right now, there's no charge for, I think, up to 500 developers. WAYNE PIEKARSKI: 500? RYAN CAIRNS: I think, for early access. Don't quote me on that. It might be 100. AUDIENCE: So some of the other cloud services, they offer assistance [INAUDIBLE]? WAYNE PIEKARSKI: Assistance with programming stuff? Like what kind of assistance? RYAN CAIRNS: Like do you want back-end storage and things like that? And how are we going to price those services? TBD. Nothing to talk about today. Sorry. AUDIENCE: Right now it's just bare bones [INAUDIBLE]. RYAN CAIRNS: Yeah. Right now, we have crash reports, analytics, storage for updates-- Lawrence, do you have a number in mind? WAYNE PIEKARSKI: Do you want to go to the mic? Are the mics ready? Yeah. MALE SPEAKER: So for things like metrics, the storage requirements are so low that it's likely that they'll remain free. But for updates, for now, everything is free. But once we see what the adoption is like, and if people start to store a lot of different updates and doing it every day, then we may have to revisit that. But for now, it's free. And TBD what the pricing model will be. WAYNE PIEKARSKI: Actually, I remember when I saw Lawrence's talk earlier. It has all these graphs that you can draw of like temperatures and things like that. And I think it's going to be really cool, because some company's going to make a fleet of devices, and they're going to be like, wow. We had a huge failure rate, and all of them had a little spike in temperature one week before they blew up. And so a week before, you hear, oop, that device is going to fail. We can send a field technician out. And so there might be a possibility that you'll just get a call saying, hey, your oven's about to fail. We've already scheduled someone to come out between next week and next Christmas to come out. And they can fix it up for you, or whatever. It will be a way of preemptively doing maintenance. Because the worst thing that can happen is, it's the middle of Thanksgiving, and your oven fails. Whereas I think there's all kinds of exciting possibilities to learn about your device fleet and what's going on. And it helps you with maintenance and doing research into making more reliable products, and-- RYAN CAIRNS: Yeah. It helps with things like phone support, too. If you could give that data to your phone techs in the future, maybe that's a problem that we can help solve. WAYNE PIEKARSKI: Many years ago, I did tech support in ISP, and doing that was the hardest thing when you didn't have remote access. You had to coach them through a phone. And it was even better when they couldn't get the phone to their computer, and then you had to talk-- RYAN CAIRNS: Well, I mean not so much remote access. I mean like if you had people working the call center, and you knew that there was a big failure of all your devices in the field, you could tell them like, hey-- call volumes are going to go up, and here's what you can tell people. WAYNE PIEKARSKI: Yeah. Yeah. RYAN CAIRNS: Even before the remote access stuff. WAYNE PIEKARSKI: I think it's going to add a lot of really cool possibilities for that. We just haven't been able to have that kind of thing. Like PCs, they can kind of do remote support, but every other device is kind of like, press the button and bring it in and replace it. And that's quite expensive. If devices could self-report, that would be really cool. Any more questions? AUDIENCE: That's actually a great lead in to my question. We heard a lot about rollout support. What about rollback support? So if-- WAYNE PIEKARSKI: As in backing a firmware update? AUDIENCE: As in, if you push something out to the field, and you start seeing a tremendous number of failures with that, is there a way to say, OK, let's easily go back to the previous version, which may or may not still be installed on the person's device? Because we heard about partitioning, also. Is there a way to say, look, you know that thing that we sent you yesterday? Forget it. Just forget it. GUARAV SHAH: We can always-- there's always the option to push back a previous update. When the update is pushed , your user data is on a different partition, so that's not clobbered. So you can, actually, go back in the same state you were before the botched update. But in general, we have actually designed the update model to make it easy to do rollbacks. AUDIENCE: And is that a real rollback, or is that just pushing out a new version that just looks like the old version? GUARAV SHAH: So there are two kinds of rollbacks. There is a rollback that will happen automatically when the device detects that the new update is bad. And that's basically-- it won't finalize the new update. And it will keep the old version around, and it will roll back to it when it detects that condition. And if that, that usually catches 99.999% of the cases if done right. And I think we do it quite right. And if that doesn't work, then there is always the option to push the old update payload again, and use that to bring the device back to the original state. WAYNE PIEKARSKI: OK. Cool. All right. Well, I guess we're almost out of time. Did you guys have any final thoughts? Oh. You had a question there? AUDIENCE: It was an extension of the OTAs. Is there going to be a certain time limit the OTA should complete? Like it shouldn't take half an hour if my door lock can't open for half an hour. So is there going to be like, your update should only take 30 seconds or? RYAN CAIRNS: So updates actually happen in the background. So the device should still function while updating. It's when the device decides to apply the update which is the question. And that policy would be different depending on the type of device that's there. So the user shouldn't be hung up waiting to interact with a device while it's updating. That would be a pretty bad experience. GUARAV SHAH: Yeah. And the other technology we have is we do delta updates. So the actual size of the update is very small. So you're not downloading-- let's say your image size is 100 megs. You're not downloading 100 megs, you're just downloading the delta, which might be something as small as like 6 megabytes. So that means that the time to download and time to apply is also less. WAYNE PIEKARSKI: Cool. AUDIENCE: Just a last question. The main goal of Weave [INAUDIBLE]? RYAN CAIRNS: Yeah. The question was, is the main goal of Weave interoperability? PAUL WESTBROOK: I would say that's one goal. The other goal is actually enabling-- well, security is always a goal. But I think it's enabling application and device developers. So I think that with the Weave APIs in Android and iOS and web, it's very easy to write an application that talked to multiple devices. RYAN CAIRNS: And one thing that we haven't mentioned about Weave is smart setup. One of the big challenges that we see is when users take these devices home, the first step is getting it on your Wi-Fi. The second step might be provisioning an account. And the third step might be downloading the app. And with the smart setup stuff, you can just go and say OK, Google, set up my device. We scan for the device, you select it. The app for that device automatically downloads in the background, and it connects to your Wi-Fi automatically. So the provisioning of it is very seamless. And what we find for legacy products are things like-- things that were designed to be used in a dumb way and maybe a smart way is that-- AUDIENCE: For dumb TV remote controls. RYAN CAIRNS: Potentially still dumb TV remote controls, as well as smart TV remote controls, but yeah. But the idea is that you don't have these misconfigured devices. There's a lot of people who sell Wi-Fi enabled devices where something like 50%, 60% of the users don't actually connect them to Wi-Fi ever. And one of the goals of Weave is making sure that the complete experience is configured out of the box without much effort. WAYNE PIEKARSKI: Yeah. Nice. OK, well, we're kind of out of time. We got another session coming up. At the end of this session, we have a bunch of demos happening during the cocktail hour. So some Googlers have actually brought in machines and devices that they've built to show off some things that they've done with Brillo and Weave. We've got that happening. We're all going to be around to ask questions of. And then tomorrow, in the code lab room, which is outside the building and one building over, we have computers set up where you can try out the Brillo BDK on one of our machines. You can also show up with your own laptop. And we're going to have office hours, where various people from the Brillo and Weave teams-- all kinds of different people, like engineers, programmers, managers, things like that-- everyone's going to be there. And you can ask questions, show them code, or we can walk you through the code labs and things like that. And if you've had trouble setting up one of your devices that you got in your little toolbox, we can help out things like that. So there's a lot of-- please take advantage of the fact that everyone's here tomorrow, and enjoy that. So that's the end of this session. Thanks very much for coming by, and we hope you all had a good time. Thank you.
B1 中級 與Brillo & Weave團隊的爐邊哈拉(2016年Ubiquity開發峰會)。 (Fireside Chat with the Brillo & Weave Team (Ubiquity Dev Summit 2016)) 101 3 謝啟仁 發佈於 2021 年 01 月 14 日 更多分享 分享 收藏 回報 影片單字