Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
PUBLIC USE
STEFAN DE TROCH
BUSINESS DEVELOPMENT & IPMM SMART PHARMA
FTF-MHW-N1980
MAY 18, 2016
FTF-MHW-N1980
DESIGNING A SINGLE CHIP
NFC TEMPERATURE LOGGER
PUBLIC USE1 #NXPFTF
These Products are Temperature Sensitive
Keeping these products in the right temperature condition
extends their freshness for the market
Monitoring their temperature history
• Provides an expectation of their future freshness
• Increases their commercial value
PUBLIC USE2 #NXPFTF
Other Products
Pharmaceutical cold chain is growing:
• In 2011, 35% of the top 50 best selling drugs require cold chain
• In 2014, 33% of the newly approved drugs are cold chain products
Pharma is regulated via the GDP (Good Distribution Practices)
• Last mile from pharmacy to patient is not covered
• Only 7% compliancy
Source: Pharmaceutical commerce
* UMC Utrecht, University of Utrecht
PUBLIC USE3 #NXPFTF PUBLIC USE3 #NXPFTF
AGENDA
• Why Temperature Monitoring
• NHS3100 Offering
• NHS3100 Starter Kit
• Creating Your Own Temperature Monitor
− Design Considerations
PUBLIC USE4 #NXPFTF
NHS3100
PUBLIC USE5 #NXPFTF
The NHS3100 Proposition
Enabling temperature monitoring from container towards item level
Quality control over the whole logistic chain
• End-user knows the state of the temperature sensitive product
• Allows to identify when the cold chain incident happened
PUBLIC USE6 #NXPFTF
NHS3100 Temperature Monitor
Flexible logger with large storage
• Easy to select temperature boundaries
− Between -40C and 85C
• Freely selectable logging interval
− From seconds to multiple hours
− Software modifiable during logging
• Large storage
− More than 18000 temperature loggings
Readout and configuration via NFC
PUBLIC USE7 #NXPFTF
Integrated Solution
Battery
IO
interfaces
Micro
controller
Flash
Temp
Sensor
NFC
interface
RealTime
Clock
NFCantenna
PUBLIC USE8 #NXPFTF
NHS3100 Properties
Accurate0.3 °C absolute temperature accuracy in the range 0-40C
Real Time Clock accuracy better than 0.1%
FlexibleFully configurable wake-up intervals
Customer-programmable ARM Cortex M0+ processor
Low PowerLow leakage current when connected to battery
Battery start enabling via NFC (extends shelf life)
Over-the-air powered (NFC)
Highly
Integrated
Embedded non-volatile data logging storage (32 KB Flash and 4 KB EEprom)
No crystal required
Embedded wireless NFC interface link to cell phone
InterfacesNFC for readout, parameter writing and powering
GPIO pins for visual feedback (e.g. LED)
I2C
PUBLIC USE9 #NXPFTF
Possible Extensions With the NHS3100
ARM M0+
Non-volatile memory
Temperature sensor
NFC
NHS3100
RTCIO blockGPIO/I2C
Wireless radio
e.g. RfID,
Bluetooth,
Zigbee, WIFI,
DECT, MI, …
• Active battery-powered tag with NFC interface for read-out and a GPIO
• Should be used in combination with wireless chip to allow active
temperature monitoring with alarm function
PUBLIC USE10 #NXPFTF
NHS3100 Package Versions
• HVQFN24
− Ready for ordering
• WLCSP25
− Will be ready for
ordering in coming
weeks
• Gold bump version
(8 bumps)
− Samples in August.
PUBLIC USE11 #NXPFTF
STARTER KIT
PUBLIC USE12 #NXPFTF
Starter Kit
• Contains
− NHS3100 demo PCB
− LPC link board
− Cables
− Software SDK and demo application
• Based on LPCXpresso
− Eclipse based IDE
− GNU C compiler, linker and libraries
− GDB
− Free of charge (download via LPCware.com)
• Available in May
− 12NC: 9353 086 24598 (NHS3100TEMOADK)
PUBLIC USE13 #NXPFTF
NHS3100 Demo PCB
• Ready to use demonstrator
• Contains
− the NHS3100 HVQFN24 IC
− A 3V coin cell battery
− A LED, Wake-Up and Reset button
− Probe/connection points towards GPIO, I2C,
SPI pins
• Available in May
− 12NC: 9353 086 25598 (NHS3100TEMODB)
PUBLIC USE14 #NXPFTF
Starter Kit as Demonstrator
• Easy to give
demonstrations with
− The NHS3100 demo
PCB
− The NHS3100 App
on the Google Play
store
PUBLIC USE15 #NXPFTF
NHS3100 Android APP
PUBLIC USE16 #NXPFTF
Demonstrating the NHS3100
• Use the provided firmware for the NHS3100 demo PCB
• Configure and start the demo with the NHS3100 App
− Touch the demo PCB and keep your phone close to it
− Select the temperature boundaries
− Select the logging interval in secs
− Select configure, wait for confirmation and remove your phone from the PCB
• Wait some time
• When touching the PCB again, you can read-out the logged temperature values
PUBLIC USE17 #NXPFTF
DEMO TIME
PUBLIC USE18 #NXPFTF
Tip
This setup also works to
validate/demonstrate your
hardware
• Ideally with the same
firmware on the NHS3100
• As long as you keep the
same PCB-phone
communication setup
• This demo also works with
our NHS3100 flex foil.
PUBLIC USE19 #NXPFTF
CREATE
YOUR FIRST
NHS3100 PROGRAM
PUBLIC USE20 #NXPFTF
Architecture
Application
Board
Chip
PUBLIC USE21 #NXPFTF
Chip layer
Architecture
chip.h
gpio gpio timergpio…
1 driver per HW block
(direct mapping with HW)
• Single entry point to the drivers
• Describes the specific IC model
• Publishes chip level info
• Internal oscillators
• Internal memories
• Factory data addresses
PORT 0 TMR16
SW
HWHW
Blocks…
NHS3100 IC
PUBLIC USE22 #NXPFTF
gpio
Board layer
Architecture
board.h
chip ledstartup • A board always contains a chip
• Startup SW module
• API per board feature(e.g. LED)
onboard
leds
• Single entry point to the HW
• Describes the specific board
• Abstracts application from HW
SW
HW
NHS3100 board other board specific functionalities
PUBLIC USE23 #NXPFTF
gpio
Application layer
Architecture
User
code
board module nmodule1• An application runs on a board
• Modules can be re-used across applications (“mods”
folder)
• Implements the application flow
• Accesses HW in an abstracted way
PUBLIC USE24 #NXPFTF
Architecture
Application
Board
Chip
An example
Blinky
LED API
GPIO driverPin direction
Pin state
LED polarity
LED pin
Program flow
(on/off period)
PUBLIC USE25 #NXPFTF
Application layer – in LPCXpresso
Architecture
.
• Builds into an executable (.axf)
• At least 1 file (main.c)
• Links with chip and board libraries
• 1 LPCXpresso project per application
PUBLIC USE26 #NXPFTF
The board library knows
how to initialize our board
The board has LEDs, so it
will link in its library, the
LED mod
The chip knows how long
an instruction takes
Includes both the board
and the chip APIs
Architecture
How it works in practice
PUBLIC USE27 #NXPFTF
CREATE YOUR
TEMPERATURE
MONITOR
PUBLIC USE28 #NXPFTF
Create Your Temperature Monitor
• No discussion about the various implementation technologies
• Nothing about PCB, FlexPCB, printed electronics, etched aluminum or copper…
• We will focus on the system and firmware aspects
• Everything discussed here can be implemented, tried with the starter kit.
PUBLIC USE29 #NXPFTF
Our Use Case
• I produce my labels in advance
• I configure the label when adding it to my package
I start the monitor at that moment
• I hand the goods to my delivery agent
• My delivery agent and my recipient can check the correct temperature handling at receipt.
− My recipient can accept or refuse the shipment
• I can check when the shipment went wrong
PUBLIC USE30 #NXPFTF
What Are the Steps?
• Define the requirements for the monitor
− Size the battery
• Design the firmware on the microcontroller
− Optimize for power
− Maximize the logging points
− Logging of the event points (eg. handover)
− Communicate with the smartphone APP
• Design the smartphone APP(s)
− Including the cloud services
PUBLIC USE31 #NXPFTF
Requirements for the Temperature Monitor
Shelf life
• Time that the assembled label is not used
• Design parameter for the battery
PUBLIC USE32 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
− How long is your package in transit before it reaches it’s destination?
− Design parameter for your battery and logging points
PUBLIC USE33 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
− How often to measure the temperature
− Depends on the product and the thermal inertia
− Impacts the battery and the amount of logged points
PUBLIC USE34 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
• Temperature usage range
− What are the expected temperatures that the label needs to work in
Eg. between -20 and +50C
− Impacts the battery selection
PUBLIC USE35 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
• Temperature usage range
• Temperature alerts
− Can be as simple as if a label went outside the specific range, eg. outside 2..8C; but can
be triggered when the label was outside this range for 1 hour
− Impacts the logging algorithm and the storage
PUBLIC USE36 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
• Temperature usage range
• Temperature alerts
• Temperature data logging
− How do we store the logged data
− Impacts the logging points
PUBLIC USE37 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
• Temperature usage range
• Temperature alerts
• Temperature data logging
• Physical dimensions and properties
− Thick, thin, small, rigid, flexible, credit card size…
− Determines the battery technology and the assembly principles
PUBLIC USE38 #NXPFTF
Requirements for the Temperature Monitor
• Shelf life
• Monitoring period
• Monitoring frequency
• Temperature usage range
• Temperature alerts
• Temperature data logging
• Physical dimensions and properties
• Roles
− Different roles can be defined, e.g. an end-user without privileges, a delivery agent which can see the history of the data
− Impacts the firmware and data access control; the Android APP(s)
PUBLIC USE39 #NXPFTF
What Are the Steps
• Define the requirements for the monitor
− Size the battery
• Design the firmware on the microcontroller
− Optimize for power
− Maximize the logging points
− Logging of the event points (eg. handover)
− Communicate with the smartphone APP
• Design the smartphone APP(s)
− Including the cloud services
PUBLIC USE40 #NXPFTF
BATTERY SELECTION
PUBLIC USE41 #NXPFTF
Power Modes NHS3100
Relevant modes for temperature monitoring:
• Deep Power Down
− Most active mode
− IC goes to active by RTC of NFC event
• Active
− Actual temperature measurement
− Handling of measurements into EEPROM and Flash
• NoPower
− Initial mode when no logging
− Battery switch is open, only battery leakage at that moment
• Sleep/Deep sleep not discussed in this talk
PUBLIC USE42 #NXPFTF
Battery: Capacity, Voltage and Internal Resistance
• Capacity: is the energy content of a battery
• Voltage: is the nominal, non-loaded tension that a battery delivers
− When a battery is loaded, this voltage drops.
For modeling purposes, this drop is modeled with the “internal resistance”. (Vdrop=Rint * Iload)
− When a battery discharges, the voltage drops
• The voltage and internal resistance are temperature and charge state dependent
An example discharge curve.
PUBLIC USE43 #NXPFTF
Short Current Peak Behavior
• Batteries are chemical elements with a capacitive effect
− This capacitive effect is important to deal with short pulses in the load current
If the battery misses this effect, there is a significant voltage drop due to internal resistance
− If the battery does not have sufficient internal capacitor effect, one can add an external
capacitor
But this external capacitor contributes to the battery leakage, thus more battery capacity is
needed
PUBLIC USE44 #NXPFTF
NHS3100 and Batteries: How to Check Compatibility?
• From the battery vendor
− Verify the discharge curves at multiple temperatures
− Verify the internal resistance changes at multiple temperatures and charge states
− Get input about the short current peak behavior
• Map your NHS3100 use case onto the battery
− Taking into account your application load profile
− Taking into account the lifetime of your application
PUBLIC USE45 #NXPFTF
BATTERY
CAPACITY
DEFINITION
PUBLIC USE46 #NXPFTF
NHS3100 Power Profile
• The NHS3100 needs a battery with a voltage between 1.72 and 3.6V.
− If the voltage is drops below 1.8V, the brown-out detection triggers
• The NHS3100 has several modes with different current consumption profiles
− NOPOWER: battery disconnected
30 nA
− Deep power down:
2-3 uA (most of the time during logging)
− Active:
250 uA during 200 msec
− Active with Flash Write:
1 mA during 300 msec and multiple current peaks of 10 mA of a 5 usec duration
PUBLIC USE47 #NXPFTF
How Use Case Requirements Relate to the Battery Capacity
• Shelf life
− This is the UNPOWERED mode of the NHS3100
− At that moment, the chip has a leakage of 30 nano-amp through its battery switch
This is independent of the self-leakage of the battery
• Temperature measurement (and logging)
− This is in the Active mode when the NHS3100 measures the temperature and stores it in memory
− For power reasons, it is better to cache the temperature values first in the EEPROM
Writing into Flash requires 3x more energy (is per page and with an erase of the sector)
• Logging period
− The NHS is in DeepPowerDown mode when the chip waits towards the next temperature measurement.
− This mode ends when an NFC field is applied or when a RTC event happens
− Realize that a temperature logger is almost always in this state
PUBLIC USE48 #NXPFTF
Power Calculation Sheet
Each 15 mins
PUBLIC USE49 #NXPFTF
Power Calculation Sheet
Each 10 mins
PUBLIC USE50 #NXPFTF
Power Calculation Sheet
Each min
PUBLIC USE51 #NXPFTF
What Are the Steps
• Define the requirements for the monitor
− Size the battery
• Design the firmware on the microcontroller
− Optimize for power
− Maximize the logging points
− Logging of the event points (eg. handover)
− Communicate with the smartphone APP
• Design the smartphone APP(s)
− Including the cloud services
PUBLIC USE52 #NXPFTF
LOGGING POINTS
PUBLIC USE53 #NXPFTF
NHS31XX Properties
• Temperature sensor
− With an 0.3 ºC absolute temperature accuracy between 0 and 40 ºC
− With an 0.5 ºC accuracy in the range -40..85 ºC
• Embedded Non-Volatile memory
− 32 kB Flash used for Data and Code
− 4 kB EEPROM
− Memory for Data depends on program size
Simple temperature logger requires +/- 8 kB Flash
PUBLIC USE54 #NXPFTF
Temperature Storage
• Depends on the logged distinct temperature values:
− Resolution of the logged temperature
This can be 0.1 ºC, 0.2 ºC, 0.5 ºC or even 1 ºC
This is not the sensor accuracy!
• Temperature Sensor returns e.g. 5.24 ºC. The real temperature is 5.24 +/- 0.3 ºC. We will store it as 5.2 ºC in a 0.1 ºC resolution.
− Range of the temperatures:
Examples:
• -40..85 ºC range of the NHS31XX
• -20..65 ºC range limited by the battery
• 0..10 ºC range limited by the use case: 2..8 ºC temperature in cold chain
• This will be expressed in a ‘bit size’ for a temperature value
• Size of a measurement point can be further reduced with compression techniques like delta temperature encoding or runtime encoding
PUBLIC USE55 #NXPFTF
Logged Points
24kB 20kB
0.1C 1251 11 17873 14895
0.2C 626 10 19661 16384
0.5C 251 8 24576 20480
0.1C 851 10 19661 16384
0.2C 526 10 19661 16384
0.5C 171 8 24576 20480
0.2C 51 6 32768 27307
0.1C 101 7 28087 23406
0.2C 31 5 39322 32768
0.1C 61 6 32768 27307
0..10C
2..8C
# Logged points
-40..85C
-20..65C
RangeLog
Resolution (*)
Bit size
Temp Value
Distinct
Temp Values
(*) Log Resolution is different from temperature sensor accuracy.
PUBLIC USE56 #NXPFTF
Zone Coding
• Biologicals and vaccines need to be stored in the fridge range: 2..8C
• NHS3100 could log the time periods in a number of zones
− Green: temperature between 2..8C
− Orange: temperature between 0..2C or 8..10C
− Red: temperature above 10C or below 0C
• This can be combined with alarm settings for error conditions
Alarm triggered if more than 2 hours above 10C or below 10C
PUBLIC USE57 #NXPFTF
Zone Coding
• Biologicals and vaccines need to be stored in the fridge range: 2..8C
• NHS3100 could log the time periods in a number of zones
− Green: temperature between 2..8C
− Orange: temperature between 0..2C or 8..10C
− Red: temperature above 10C or below 0C
• This can be combined with alarm settings for error conditions
Alarm triggered if more than 2 hours above 10C or below 10C
PUBLIC USE58 #NXPFTF
What Are the Steps
• Define the requirements for the monitor
− Size the battery
• Design the firmware on the microcontroller
− Optimize for power
− Maximize the logging points
− Logging of the event points (eg. handover)
− Communicate with the smartphone APP
• Design the smartphone APP(s)
− Including the cloud services
PUBLIC USE59 #NXPFTF
HANDOVER FLOW
(+ACCESS CONTROL)
PUBLIC USE60 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
PUBLIC USE61 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
Firmware and NFC configurator:
• Configuration of the label:• Alert settings
• Frequency
• Access control for data readout
• Maximum logging period
• Start of the temperature logging
• To avoid data tampering, the Flash pages are locked after writing
PUBLIC USE62 #NXPFTF
Access Control to the Data on the NHS3100
• Some users like to have a means to limit access to the logged information
− That could be done with a password
• Do not use a single password for all the NHS3100 solutions you produce!
− TOO EASY for hackers
PUBLIC USE63 #NXPFTF
Access Control to the Data on the NHS3100
• Normally, accessing all data is needed for forensic analysis
− At that moment, you like to send all info to the cloud, so you have network access
• Each NHS3100 has an unique identifier of 8 bytes
That can be used to create an unique password per NHS3100 chip
• Based on cryptographic technologies, like e.g. encoding with AES and your master password
− If the APP of the delivery agent is certified,
each times if the APP sends the UID to your cloud server, you can calculate and return the password
• At that moment, the APP will forward all the underlying data received from the NHS3100
PUBLIC USE64 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
Firmware and Delivery Agent APP:
• Readout of temperature status
• Delivery Agents accept the goods via his APP
• This transfer event is logged on the NHS3100 and in the cloud
• Label continues logging the temperature
PUBLIC USE65 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
Firmware:
• Continues logging the temperature
• Shows an alert via NFC when appropriate
PUBLIC USE66 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
Firmware, Delivery Agent APP and NFC phone recipient:
• Continues logging the temperature
• The firmware returns the alert level when asked by recipients’ NFC phone
• When the status is ok, the recipient accepts the goods using the Delivery Agent APP
• That event is logged to the tag and to the cloud
• In case of refusal, the DA-APP requests the password in the cloud,
obtains the data from the tag and transfer the data to the cloud
• I can via my cloud check when a temperature event happened
PUBLIC USE67 #NXPFTF
Flow and Roles
Packaging good
•Role: I
Transfer to courier
•Role: I and delivery agent
Goods transfer
•Role: delivery agent
Reception of goods
•Role: delivery agent and recipient and I
Further handling
Firmware and NFC phone recipient :
• Continues logging the temperature
• If the end of the logging period, the label will signal
• The recipient can check the good’s status
(inclusive the end of logging)
PUBLIC USE68 #NXPFTF
NFC
COMMUNICATION
PUBLIC USE69 #NXPFTF
NFC Communication Structure
• The SDK provides a communication library
− Both on the phone as on the NHS3100 side
− Messaging is based on NDEF messaging
• Examples can be found in the SDK as in the
source code of both the demonstration
firmware as Android APP
PUBLIC USE70 #NXPFTF
What Are the Steps
• Define the requirements for the monitor
− Size the battery
• Design the firmware on the microcontroller
− Optimize for power
− Maximize the logging points
− Logging of the event points (eg. handover)
− Communicate with the smartphone APP
• Design the smartphone APP(s)
− Including the cloud services
PUBLIC USE71 #NXPFTF
CREATE YOUR
TEMPERATURE
MONITOR
PUBLIC USE72 #NXPFTF
Block architecture
PUBLIC USE73 #NXPFTF
ANDROID APP
CLOUD SERVICES
PUBLIC USE74 #NXPFTF
Now We Are Outside the Comfort Zone of NXP
• The Android APP sources serve as example
− Can be used as starting point for your end-to-end system
We transfer the log data from the NHS3100 to the phone and visualize this
• You can forward this data to your cloud server
− Build analytics around this
− In a secure environment
• Can be part of your additional offerings
− For continuous quality improvement
− As a proof for claims versus insurers/sub-contractors
PUBLIC USE75 #NXPFTF
TAKEAWAYS
PUBLIC USE76 #NXPFTF
NHS3100
• A flexible solution for temperature monitoring
− Flows can be easily implemented in firmware
− Good-specific temperature profiles can be implemented in software
Stability profile for drugs, for blood (max 1 hour above 10C), for chemicals
• Enables item-level logging
− Integrated into your ERP systems
• Your APP and our NHS3100 chip form the portal to your end-customer
− Create your smart (package) solution
− E.g. for drugs, you can guide the end-customer to find the best storage place in the fridge
PUBLIC USE77 #NXPFTF
WE ENABLE
QUALITY CONTROL
OVER THE ENTIRE
LOGISTICS CHAIN
PUBLIC USE79 #NXPFTF
ATTRIBUTION STATEMENT
NXP, the NXP logo, NXP SECURE CONNECTIONS FOR A SMARTER WORLD, CoolFlux, EMBRACE, GREENCHIP, HITAG, I2C BUS, ICODE, JCOP, LIFE VIBES, MIFARE, MIFARE Classic, MIFARE
DESFire, MIFARE Plus, MIFARE FleX, MANTIS, MIFARE ULTRALIGHT, MIFARE4MOBILE, MIGLO, NTAG, ROADLINK, SMARTLX, SMARTMX, STARPLUG, TOPFET, TrenchMOS, UCODE, Freescale,
the Freescale logo, AltiVec, C 5, CodeTEST, CodeWarrior, ColdFire, ColdFire+, C Ware, the Energy Efficient Solutions logo, Kinetis, Layerscape, MagniV, mobileGT, PEG, PowerQUICC, Processor Expert,
QorIQ, QorIQ Qonverge, Ready Play, SafeAssure, the SafeAssure logo, StarCore, Symphony, VortiQa, Vybrid, Airfast, BeeKit, BeeStack, CoreNet, Flexis, MXC, Platform in a Package, QUICC Engine,
SMARTMOS, Tower, TurboLink, and UMEMS are trademarks of NXP B.V. All other product or service names are the property of their respective owners. ARM, AMBA, ARM Powered, Artisan, Cortex,
Jazelle, Keil, SecurCore, Thumb, TrustZone, and μVision are registered trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. ARM7, ARM9, ARM11, big.LITTLE, CoreLink,
CoreSight, DesignStart, Mali, mbed, NEON, POP, Sensinode, Socrates, ULINK and Versatile are trademarks of ARM Limited (or its subsidiaries) in the EU and/or elsewhere. All rights reserved. Oracle and
Java are registered trademarks of Oracle and/or its affiliates. The Power Architecture and Power.org word marks and the Power and Power.org logos and related marks are trademarks and service marks
licensed by Power.org. © 2015–2016 NXP B.V.