android 功耗分析方法和优化（1）
1、底电流调试（Rock Bottom Current Optimization）底电流在手机飞行模式下调试。每个平台的底电流数据可能不一样，具体可以参考release出来的Current Consumption Data文档或者release note。一般情况下的底电流参考数据上限是：
底电流在手机飞行模式下调试。每个平台的底电流数据可能不一样，具体可以参考release出来的Current Consumption Data文档或者release note。一般情况下的底电流参考数据上限是：
512M RAM < 1.5mA; 1G RAM < 2mA; 2G RAM < 2.6mA
1.1 校准RF保证RF的PA、Antenna switch、Tuner、APT、GPIO工作在正常状态
1.2 飞行模式开启飞行模式、关闭GPS、关闭自动旋转屏幕、关闭自动亮度调节、关闭其他特效效果设置
开启飞行模式，可以基本避免蓝牙、wifi、NFC、网络、FM等的一般影响；
关闭GPS，可以基本排除开启GPS对底电流的影响；
关闭自动旋转屏幕，可以基本排除sensor的影响；
关闭自动亮度调节，可以基本排除距离感应到的影响；
关闭其他特效效果设置，如指纹识别、黑屏手势、智能体感、手势隔空操作。。。。。。
1.3 使用perf_defconfig修改device/qcom//AndroidBoard.mk。如果KERNEL_DEFCONFIG := _defconfig，那么改成KERNEL_DEFCONFIG := -perf_defconfig
同时，kernel代码改用/kernel/arch/arm/configs/-perf_defconfig
是平台名称或者项目名称
1.4 移除debugging APKs/system/app/Logkit.apk/system/app/com.qualcomm.qlogcat.apk/system/xbin/qlogd1.5 把应用尽量删除
在设置-->应用，禁用正在运行的应用
1.6 去掉CPU占用高的进程adb shelltop
查看CPU占用，去掉在休眠模式下CPU占用大于0的进程。kill掉该进程，若kill不掉则rm掉相关应用。对于占用CPU高的kwork，需要查找驱动原因。
1.7 手动移除所有可以移除的外设手机连上安捷伦电源，手机开机，然后让手机进入待机状态。手动移除TP、LCM、前camera、后camera、sensor、SD卡、SIM卡等可以手动移除的外围器件，同时观察并记录底电流变化。
# mount -o rw,remount -t vfat /dev/block/bootdevice/by-name/modem # cd /firmware/image # rm wcnss.* # reboot
或者
#lsmod#rmmod WLAN
移除其他可以移除的芯片（sensor、NFC。。。）
1.8 移除驱动模块在kernel/arch/arm/configs/-perf_defconfig中把sensor、TP、LCM、camera等的驱动模块移除；
或者在对应驱动的Makefile里面，移除驱动代码
然后编译bootimage，烧入手机观察底电流变化
1.9 配置不用的GPIO将不用的GPIO置为输入、拉低；配置成SPI、I2C的GPIO，若不用，置为悬空
在boot_images/core/systemdrivers/tlmm/config/platform/TLMMChipset.xml，修改GPIO配置。该处配置GPIO的初始状态，驱动有可能会修改GPIO。
对比项目原理图与平台参考原理图，项目原理图中多出的NC GPIO要处理掉。
1.10 检查power相关的NV items需要跟CE确认。一般如下：
1027 = 01895 = 01892 = 01962 = 04679 = 164201 = 03851 = 03852 = 67157 = 169745 rxd_enable = 0WCDMA NV:NV3581 = 0NV3852 = 61.11 排查GPIO、LDO、总线
对比项目原理图与平台参考原理图，排查硬件不一样的GPIO、LDO、总线配置。
量测各GPIO、LDO、I2C在休眠时候的电压，需用万用表准确测量。
休眠时各路I2C GPIO的电压是多少v，用万用表准确测量。
如果条件允许，测量所有LDO在休眠前和休眠后的准确电压。
对于LDO，调试方法如下：
（1）adb shell关闭LDO
如关闭L3：
cd /sys/kernel/debug/regulator/8916_l3/echo 0 > enable
（2）LDO太多设备用到，不适合用adb shell来关。可以这样调试：
cat /sys/kernel/debug/regulator/8916_l6/consumersshell@msm8916_32:/sys/kernel/debug/regulator/8916_l6 $ cat consumers Device-Supply EN Min_uV Max_uV load_uA 0-000c-vio Y 1800000 1800000 0 0-0068-vi2c N 1800000 1800000 0 5-0038-vcc_i2c Y 1800000 1800000 0 1a98000.qcom,mdss_dsi-vddio N 1800000 1800000 100 1a98300.qcom,mdss_dsi_pll-vddio N 1800000 1800000 100 8916_l6 N 0 0 0
这样就可以看到是哪些设备请求了LDO6。然后 找到对应的代码，在休眠时关掉LDO，唤醒时再打开。
0-000c: 挂在I2C0上地址为0xc 5-0038: 挂在I2C0上地址为0x38
查看这两个设备的驱动代码是否有执行regulator_enable。
（3）通过寄存器地址关闭LDO
如LDO6的地址是0x14546，则关闭方法是：
# cd /sys/kernel/debug/spmi/spmi-0 # echo 0x14546 > address # echo 1 > count # cat data 可以读寄存器 # echo 0x00 > data 关LDO6
（4）关闭MPP
在休眠前关闭MPP1、MPP2、MPP3、MPP4
如PM8916的寄存器地址分别是0xA046、0xA146、0xA246、0xA346
在关闭前先cat data以查看原来的值。
GPIO状态读取的方法如下：
（1）GPIO dump
为了得到休眠时的GPIO状态，增加下面的打印:
rpm_proc/core/power/sleep/src/lpr_definition_uber.c#include "tlmm_hwio.h" void deep_sleep_enter(void) { uint64 sleep_duration; ... SWEVENT(SLEEP_DEEP_SLEEP_ENTER_COMPLETE, sleep_mode.deep_sleep_mode, sleep_duration); // For test { int num; int i=11; volatile uint32 cfg ,inout, val; num = 122; //8916 only. Need modify for 8974/8x10/8x26 etc. cfg = *(volatile uint32*)HWIO_TLMM_GPIO_CFGn_ADDR(i); //(0x61000000 + i * 0x1000) inout = *(volatile uint32*)HWIO_TLMM_GPIO_IN_OUTn_ADDR(i);//(0x61000004 + i * 0x1000) val = ((cfg << 16)&0xffff0000) | (inout&0xffff); SWEVENT(SLEEP_GPIO_DUMP, i, val); } mpm_sw_done(sleep_mode.deep_sleep_mode, sleep_duration); } while(FALSE); }
增加for test下面这一段代码。
然后再修改:
rpm_proc\core\power\sleep\build\SConscript if 'USES_QDSS_SWE' in env: QDSS_IMG = ['QDSS_EN_IMG'] events = [['SLEEP_DEEP_SLEEP_ENTER=320','deep sleep enter. (sleep mode: %d) (count: %d)'], ['SLEEP_DEEP_SLEEP_EXIT','deep sleep exit (sleep mode: %d)'], ['SLEEP_NO_DEEP_SLEEP','bail early from deep sleep. (sleep mode: %d) (reason: %d)'], ['SLEEP_RPM_HALT_ENTER','rpm halt enter'], ['SLEEP_RPM_HALT_EXIT','rpm halt exit'], ['SLEEP_MPM_INTS','pending mpm interrupts at wakeup: (interrupt_status_1 %d), (interrupt_status_2 %d)'], ['SLEEP_DEEP_SLEEP_ENTER_COMPLETE','deep sleep exit complete (sleep mode: %d)'], ['SLEEP_DEEP_SLEEP_EXIT_COMPLETE','deep sleep exit (sleep mode: %d)'], ['SLEEP_MPM_WAKEUP_TIME','mpm wake up time (wakeup time: 0x%0.8x%0.8x)'], ['SLEEP_GPIO_DUMP','gpio [%d] configuration is %d'],['SLEEP_EVENT_LAST=383','sleep last event placeholder']
增加SLEEP_GPIO_DUMP这一项。
编译烧写rpm.mbn。
让机器休眠，进入download，抓dump，然后将如下日志发给平台技术支持分析。
CODERAM.bin
MSGRAM.bin
DATARAM.bin
以及新编译出来的RPM_AAAAANAZR.elf。
在RPM可能不是很方便，也可以用busybox来读取寄存器，例如读GPIO11：
Physical Address for GPIO_CFG11 = 0x100B000 root@android:/data/busybox # ./busybox devmem 0x100B000 32 ./busybox devmem 0x100B000 32 0x00000203 GPIO_PULL = "11" PULL_UP FUNC_SEL = "0000" FUNCTION GPIO DRV_STRENGTH = "000" DRV_2_MA GPIO_OE = "1" Output Enable 1.12 rpm dump
抓rpm dump，然后把log提供给平台技术支持。
方法如下：
（1）ps_hold接地
在休眠状态下，接ps_hold到地少于200mS，机器会进入紧急下载状态，插入USB，QPST会自动得到memory dump，然后上传以下几个文件：
CODERAM.bin
MSGRAM.bin
DATARAM.bin
以及RPM_AAAAANAZR.elf（必须与机器的编译时间一致匹配的elf)
（2）改reset为download key
发这些命令改reset为download key:
# cd /sys/kernel/debug/spmi/spmi-0 # echo 0x844 > address # echo 4 > count # cat data 00840 -- -- -- -- 0F 07 04 00 # echo 0x00 0x00 0x01 0x00 > data # cat data 00840 -- -- -- -- 00 00 01 00 # echo 0x00 0x00 0x01 0x80 > data # cat data 00840 -- -- -- -- 00 00 01 80
然后长按下键，会进入download。之后抓取log方法同上。
如果进不了download，需要确认：
CONFIG_MSM_DLOAD_MODE=y
另外也有可能与nv 4399和905有关系。
1.13 检查rpm_stats检查rpm_stats是否进入vdd min或者xo/no shutdown。使用下面的命令检查rpm lower power mode count:
cat /sys/kernel/debug/rpm_stats
如果vmin的count是0，则表明设备从来没有进入vdd min；non-zero则说明设备进入过vdd_min。
RPM Mode: xosdcount:0time in last mode(msec):0time since last mode(sec):794actual last sleep(msec):0RPM Mode:vmincount:11time in last mode(msec):0time since last mode(sec):359actual last sleep(msec):1100001.14 使用Trace32
可以dump出来完整详细的gpio/clk/pmic信息，排除休眠时候的状态异常。
2、待机电流优化（Standby Current Optimization）2.1 通过adb log排查adb logcat -v time > YearMounthDayHourMinute_logcat.txt //main logadb logcat -v time -b events > YearMounthDayHourMinute_logcat_event.txt //event logadb logcat -v time -b radio > YearMounthDayHourMinute_logcat_radio.txt //radio logadb shell dmesg > YearMounthDayHourMinute_dmesg.txt //kernel log
可以采用功耗问题时间追踪表来精确追踪功耗异常。
可以使用如下命令来打开指定文件的kernel log（以qpnp-adc-tm.c和qpnp-adc-common.c为例）：
adb shell mount -t debugfs none /sys/kernel/debugadb shell "echo 8 > /proc/sys/kernel/printk" adb shell "echo 'file qpnp-adc-tm.c +p' > /sys/kernel/debug/dynamic_debug/control"adb shell "echo 'file qpnp-adc-common.c +p' > /sys/kernel/debug/dynamic_debug/control"adb shell "echo 8 > /proc/sys/kernel/printk"
为指定的函数开启log，以qpnpint_handle_irq为例：
adb shell "echo 'func qpnpint_handle_irq +p' > /sys/kernel/debug/dynamic_debug/control"
*#logkit#*调出logkit apk，可以保存logcat、dmesg、crash、QXDM、GPU log等日志信息到手机里面。
2.2 top通过top命令，可以查询到cpu占用较高的应用。如果一个应用一直在占用cpu，而此时并没有打开该应用，那么该应用很可能会导致待机异常。
adb shelltop
“该场景下CPU使用率”是User+System+IOW+IRQ
“模块相关的CPU占用率”是模块相关进程占用CPU使用率的总和
2.3 正在运行设置-->应用-->正在运行，可以看到正在运行的应用或者服务。禁止掉应用或者服务，观察待机电流变化。
2.4 wakeup debug mask调试wakeup问题，可以使能debug功能，然后抓取log。Log中会增加一些debug信息。
mount -t debugfs none /sys/kernel/debug echo 1 > /sys/kernel/debug/clk/debug_suspend echo 1 > /sys/module/msm_show_resume_irq/parameters/debug_mask echo 4 > /sys/module/wakelock/parameters/debug_mask echo 1 > /sys/module/lpm_levels/parameters/debug_mask echo 0x16 > /sys/module/smd/parameters/debug_mask 2.5 wakelock
1、wakeup_sources
kernel wakelock和userspace wakelock都有可能阻止系统睡眠。所有的wakeup_sources均保存在sys节点/sys/kernel/debug/wakeup_sources里面。
该文件包含了如下信息：
（1）the total amount of time a wakeup source has prevented suspend
（2）the amount of time a wakelock has been active since the last activation etc. The unit of time is milliseconds.
2、active_since
active_since值可以用来确认wakelock是否正在阻止休眠。如果该值不是零，那么这个wakelock正在工作并且阻止休眠。
3、获取wakeup_sources的命令
adb root 67754400adb remountadb shell cat /sys/kernel/debug/wakeup_sources > /data/wakeup_sources.txtadb pull /data/wakeup_sources.txt
获得wakeup_sources.txt以后，通过Excel打开，active_since不为0的项为wakeup source。以表2为例，msm_dwc3对应的active-since值481756>0，这意味着msm_dwc3驱动在阻止系统睡眠，下一步需要检查msm_dwc3驱动代码及相关log。
表格 2 Wakeup source opened in Excel
4、power:wakeup_source_activate and power:wakeup_source_deactivate events
当一个wakeup source被acquire或者release时候，power:wakeup_source_activate和power:wakeup_source_deactivate event将随即被写到trace buffer里面，这样可以记录wakeup source被driver使用的频率。
开启该功能的方法：
echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_eventThe power:wakeup_source_activate and power:wakeup_source_deactivate events are written to the trace buffer any time a wakeup source is acquired or released and it can provide information on how often a wakeup source is being used by a driver. To enable these events, you can enable following: echo "power:wakeup_source_activate power:wakeup_source_deactivate" > /sys/kernel/debug/tracing/set_event Once the above done, the traces will be present in /sys/kernel/debug/tracing/trace. 2.6 powertop
powertop用来看CPU的运行统计以协助调试power问题。powertop的用法如下：
powertop --hUsage: powertop [OPTION...]n -d, --dump read wakeups once and print list of top offendersn -t, --time=DOUBLE default time to gather data in secondsn -r, --reset Reset PM stats datan -h, --help Show this help messagen -v, --version Show version information and exit
获取powertop log的方法：
通过USB连接手机到电脑adb shell，然后执行如下命令：sleep 10 && /data/powertop [-r] -d -t 30 > /data/powertop.log &
拔掉USB线，等待10秒后开始功耗测试插上USBadb pull /data/powertop.log2.7 CPU freq log打开CPU freq change log：
mount -t debugfs none /sys/kernel/debug cd /sys/kernel/debug echo -n 'file acpuclock-8x60.c +p' > dynamic_debug/control echo -n 'file acpuclock-krait.c +p' > dynamic_debug/control
查看cpu freq stats:
cat /sys/devices/system/cpu/cpu0/cpufreq/stats cat /sys/devices/system/cpu/cpu1/cpufreq/stats cat /sys/devices/system/cpu/cpu2/cpufreq/stats cat /sys/devices/system/cpu/cpu3/cpufreq/stats
To lock cpu freg:
echo the same freq to following sys mode will lock cpu freq to the setting freq. /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq /sys/devices/system/cpu/cpu0/cpufreq/scaling_min_freq
To enable/disable specific freq for ACPU
ACPU freq table is defined in acpu_freq_tbl_* structure of specific platform. arch/arm/mach-msm/acpuclock-.c For 8974, it is defined in arch/arm/mach-msm/acpuclock-8974.c. the first column of following table used to enable/disable freq in the row: 1:enable, 0:disable static struct acpu_level acpu_freq_tbl_2p3g_pvs0[] __initdata = { { 1, { 300000, PLL_0, 0, 0 }, L2(0), 800000, 72 }, { 0, { 345600, HFPLL, 2, 36 }, L2(1), 800000, 83 }, { 1, { 422400, HFPLL, 2, 44 }, L2(2), 800000, 101 }, { 0, { 499200, HFPLL, 2, 52 }, L2(2), 805000, 120 }, { 0, { 576000, HFPLL, 1, 30 }, L2(3), 815000, 139 }, { 1, { 652800, HFPLL, 1, 34 }, L2(3), 825000, 159 }, { 1, { 729600, HFPLL, 1, 38 }, L2(4), 835000, 180 }, { 0, { 806400, HFPLL, 1, 42 }, L2(4), 845000, 200 }, { 1, { 883200, HFPLL, 1, 46 }, L2(4), 855000, 221 }, { 1, { 960000, HFPLL, 1, 50 }, L2(9), 865000, 242 }, { 1, { 1036800, HFPLL, 1, 54 }, L2(10), 875000, 264 }, { 0, { 1113600, HFPLL, 1, 58 }, L2(10), 890000, 287 }, { 1, { 1190400, HFPLL, 1, 62 }, L2(10), 900000, 308 }, … { 1, { 1958400, HFPLL, 1, 102 }, L2(19), 1040000, 565 }, { 0, { 2035200, HFPLL, 1, 106 }, L2(19), 1055000, 596 }, { 0, { 2112000, HFPLL, 1, 110 }, L2(19), 1070000, 627 }, { 0, { 2188800, HFPLL, 1, 114 }, L2(19), 1085000, 659 }, { 1, { 2265600, HFPLL, 1, 118 }, L2(19), 1100000, 691 }, { 0, { 0 } } }; 2.8 Hoplug cores
Core 0 can’t be hotplugged, Core 1/2/3 can be hotplugged,
To remove core :
echo 0 > /sys/devices/system/cpu/cpu1/online echo 0 > /sys/devices/system/cpu/cpu2/online echo 0 > /sys/devices/system/cpu/cpu3/online
To add back core:
echo 1 > /sys/devices/system/cpu/cpu1/onlineecho 1 > /sys/devices/system/cpu/cpu2/onlineecho 1 > /sys/devices/system/cpu/cpu3/online2.9 Scaling governor
To check scaling governor：
cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
To set new governor：
比如：
echo ondemand > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor2.10 Mpdecision
Use Mpdecison daemon to start/stop/enable debug with commands below:
Start mpdecison： start mpdecision n Stop mpdecison：stop mpdecisionEnable mpdecision debug ：start mpdecision --debug 2.11 Power feature enable/disable
Following sys node can be used to enable the lower resource,
echo 2 > /sys/module/lpm_resources/enable_low_power/l2 echo 1 > /sys/module/lpm_resources/enable_low_power/pxo echo 1 > /sys/module/lpm_resources/enable_low_power/vdd_dig echo 1 > /sys/module/lpm_resources/enable_low_power/vdd_mem echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/suspend_enabled echo 1 > /sys/module/pm_8x60/modes/cpu1/power_collapse/suspend_enabled echo 1 > /sys/module/pm_8x60/modes/cpu2/power_collapse/suspend_enabled echo 1 > /sys/module/pm_8x60/modes/cpu3/power_collapse/suspend_enabled echo 1 > /sys/module/pm_8x60/modes/cpu0/power_collapse/idle_enabled echo 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/suspend_enabledecho 1 > /sys/module/pm_8x60/modes/cpu1/standalone_power_collapse/suspend_enabledecho 1 > /sys/module/pm_8x60/modes/cpu2/standalone_power_collapse/suspend_enabled echo 1 > /sys/module/pm_8x60/modes/cpu3/standalone_power_collapse/suspend_enabledecho 1 > /sys/module/pm_8x60/modes/cpu0/standalone_power_collapse/idle_enabled echo 1 > /sys/module/pm_8x60/modes/cpu1/standalone_power_collapse/idle_enabled echo 1 > /sys/module/pm_8x60/modes/cpu2/standalone_power_collapse/idle_enabled echo 1 > /sys/module/pm_8x60/modes/cpu3/standalone_power_collapse/idle_enabled echo 0 to above sys node will disable related low power mode. 2.12 Check system alarm
get android alarms and statistics: adb dumpsys alarm > alarms.txt enable android debug message in logcat： setprop persist.alarm.debug 12.13 Kernel timer check
Sys node /proc/timer_stats can be used to check kernel timer stastics, customer can use following command to get timer statics in specific scenario:
echo 0 > /proc/timer_stats && sleep 10 && echo 1 > /proc/timer_stats && sleep 30 && cat /proc/timer_stats > /data/timer_stats &
OEMs need to provide file /data/timer_stats to salesforce case for check.
3、其他功耗项的优化3.1屏幕对功耗的影响屏幕亮度等级不同，功耗不同。亮度越低，功耗越低。调低屏幕默认背光亮度等级和屏幕最高亮度设置时候的背光亮度等级，可以优化手机整体功耗表现。
LCD背光等级的设备节点：
/sys/class/leds/lcd-backlight/brightness
默认背光等级和最高亮度背光等级需要同时考虑到用户体验和功耗表现，需要一起评估。
另外，调试LCD的fps帧率，也可以优化功耗。
3.2 CPU/GPU DVFSCPU/GPU的动态调频调压可以优化手机的功耗表现。该影响是整体性的，系统性的。
CPU降频主要通过两种方式实现，都可以达到降频的目标。
1、设置CPU工作在powersave模式。设置该模式后，CPU将一直工作在最低频率（300000hz）。此时手机最省电，但是有可能会出现手机运行变卡顿。
例如：将CPU0置为powersave模式，命令为：
echo "powersave" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
例如：将CPU1置为powersave模式，命令为：
echo "powersave" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor
ex780共有4个CPU（CPU0~CPU3），都可以这样处理
2、限制CPU最高频率，以限制CPU的运行频率上限
CPU（CPU0~CPU3）可以选择的频率值如下所列，即这些数值都可以用作CPU的频率上限。选择的频率上限可以根据实际场景需要来设置。在超级省电模式下，CPU工作的宗旨是：CPU工作频率低+运行不卡，两项都要保障。
CPU可以选择的频率：
300000 422400 652800 729600 883200 960000 1036800 1190400 1267200 1497600 1574400 1728000 1958400 2265600 2457600
例如：将CPU0的频率上限设置为960000
echo 960000 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
例如：将CPU0的频率上限设置为422400
echo 422400 > /sys/devices/system/cpu/cpu0/cpufreq/scaling_max_freq
GPU相关调试与CPU类似，设备节点路径/sys/devices/fdb00000.qcom,kgsl-3d0/kgsl/kgsl-3d0
3.3 CPU占用率应用对cpu的占有率，如果占有率过高，则该应用一般会导致功耗较大。
adb shelltop -m 6
adb shelltop -m 6 3.4 游戏功耗
可以从下面几个方面优化：
降低屏幕背光亮度等级；
采用CPU、GPU动态调频调压，并调低CPU、GPU频率下限；
采用thermal-engine.conf 。
3.5 Camera功耗偏大降低camera帧率；
降低屏幕背光亮度等级；
采用CPU、GPU动态调频调压，并调低CPU、GPU频率下限；
采用thermal-engine.conf 。
三相综合电量表在风力发电中的应用
虹润NHR-3300系列三相综合电量表在风力发电中的应用一、摘要
虹润NHR-3300系列三相综合电量表是依据DB37/ T557-2005行业标准开发的产品，它是一款用于低压配电系统的交流电量测量、显示、控制、分析的综合仪表。产品通过现场PT、CT变比取得数据经过内部整形电路转换成相应的数值，经过内部运算（电流、电压依次积分）取得所需要的交流需量，最终可实现交流电压、电流、频率、有功功率、无功功率、谐波含量、功率因数、有功、无功、视在电能工程值显示。目前虹润自主研发的虹润NHR-3300系列三相综合电量表在风力发电中主要应用于发动机组运行状态电量参数的监测。
二、产品的市场背景
风力作为一种绿色环保新兴能源一跃成为现代能源关注点，出于保护环境的考虑以及全球面临的能源短缺现状，风力发电在世界范围内得到了快速发展。随着风电行业的技术进步，风力发电成本逐步降低，在经济性上已经能够与核能发电、水力发电展开竞争。当前，我国面临电力短缺局面，在煤电占主导地位的我国电力行业，因环境承载力限制以及各种因素导致的煤炭短缺局面，煤电发展受到制约。风能这种干净的自然能源，没有常规能源（煤电，油电）与核电会造成环境污染的问题。我国风能资源丰富，风能利用得到了政府的政策支持，风力发电产业面临前所未有的发展机遇。
三、产品的主要技术原理
虹润NHR-3300系列三相综合电量表可外接电压、电流互感器的标准信号或直接接入电流5A、电压500V的交流信号，并通过专用DSP芯片定点处理，高速、高精度AD采集，多种接线方式可选，可同时测量单相电量系统、三相交流电流、三相交流电压、三相有功功率、三相无功功率、三相视在功率、三相功率因数、工频周波、三相有功电能、三相无功电能和三相总电能，并在型号上对每个功能做了明确的细分。输出功能可选模拟量输出、通讯输出和累积脉冲输出功能，配备RS232/485通讯接口，支持标准MODBUS RTU通讯协议，可组网实现数据的集中管理。
下面介绍一下主要参数的计算方法
◆ TRMS的算法
本产品所测试的参数均为真有效值（TRMS），依据数学公式1如下：
该测量原理适用于常见的各种工频信号的测试，通过AD采样可对包括正弦波、方波、三角波及各种异常波形进行分析。
◆ ∑的计算方法
∑的显示数值与线制有关，其数值算法如下表所示：
各线制合计参数计算方法
SYS3P3L3V3A3P4L线制方式3相3线2元件 3相3线3元件3相4线∑V（VA+VC）/2（VA+VB+VC）/3（VA+VB+VC）/3∑I （IA+IC）/2（IA+IB+IC）/3（IA+IB+IC）/3∑PPA+PCPA+PB+PCPA+PB+PC∑QQA+QCQA+QB+QCQA+QB+QC∑S
SA+SB+SC∑PF∑P/∑S
◆ 电量参数的校准方法
产品通过标准源输出交流电流、电压的真有校值、相位角度的偏差、有功功率等实现零点、满度校准，校准后写入EEPROM中保存。
◆ 三相电量综合集中显示仪表的在实际应用的接线方式
三相三线系统（3P3L 、无PT、CT）
三相三线系统（3P3L、2PT、2CT）
三相四线系统（3P4L、无PT、CT）
三相四线系统（3P4L、3PT、3CT）
备注：符号描述
符号描述符号描述
保险丝
保护接地
电压互感器
电流互感器
四、产品的应用
应用于风力发电的所有风电机组通过光纤以太网连接至主控室的上位机操作员站，实现整个风场的监控，上位机监控软件具有如下功能:
◆ 系统具有友好的控制界面。在编制监控软件时，充分考虑到风电场运行管理的要求，使用汉语菜单，操作简单，尽可能为风电场的管理提供方便。
◆ 系统显示各台机组的运行数据。如每台机组的瞬时发电功率、累计发电量、发电小时数、风轮及电机的转速和风速、风向等，将下位机的数据调入上位机并在显示器上显示，必要时还可以用曲线或图表的形式直观地显示出来。
◆ 系统显示各风电机组的运行状态，如开机、停车、调向、手/自动控制以及大/小发电机工作等情况，通过各风电机组的状态了解整个风电场的运行情况。
◆ 系统能够及时显示各机组运行过程中发生的故障。在显示故障时，能显示出故障的类型及发生时间，以便运行人员及时处理及消除故障，保证风电机组的安全和持续运行。
◆ 系统能够对风电机组实现集中控制。值班员在集中控制室内，只需对标明某种功能的相应键进行操作，就能对下位机进行改变设置状态和对其实施控制。如开机、停机和左右调向等。该操作同时具有权限管理，以保证整个风电场的运行安全。
◆ 系统管理。监控软件具有运行数据的定时打印和人工即时打印以及故障自动记录的功能，以便随时查看风电场运行状况的历史记录情况。
机组运行过程中进行监测的相关参数包括：
◆ 电网参数，包括电网三相电压、三相电流、电网频率、功率因数等。电压故障检测：电网电压闪变、过电压、低电压、电压跌落、相序故障、三相不对称等。
◆ 气象参数，包括风速、风向、环境温度等。
◆ 机组状态参数检测，包括：风轮转速、发电机转速、发电机线圈温度、发电机前后轴承温度、齿轮箱油温度、齿轮箱前后轴承温度、液压系统油温、油压、油位、机舱振动、电缆纽转、机舱温度等。
◆ 主要监测设备：虹润NHR-3300系列三相综合电量表
◆ 产品图示 :
主要负责监控机组运行的电量参数
产品图片 :
◆ 辅助设备：
温度传感器HR-WZP、HR-WRN、转速磁电传感器、转速表、数采模块、报警装置、虹润八回路闪报警仪等。
1、主要对电机绕组的定子温度、电机转速实现监控
2、根据各绕组的测温点输出声光报警
五、结束语
基于虹润坤瑞监控组态软件及电量集中控制仪而搭建的这个风电场各项监控、监测数据信息共享、交换、传输平台，能够满足国家电力系统二次防护要求。在进行远程数据采集和控制时，保证风电厂数据的实时性和可靠性。通过风能特性模型实时调整风能的最优性，能够为生产厂商提供优质监控解决方案，为祖国风电绿色能源事业保驾护航。
「科普」自研SoC行不行？Google Tensor测试与分析
因为上一代用骁龙 765G 的骚操作，在大家心目当中，Google Pixel 系列算是断更一代。而 Pixel 6 系列就不同了，有 Google 自研 SoC——Google Tensor（Tensor 是张量的意思，名字就很 AI，很ML）、追上时代的相机硬件，也有相对厚道的价格。
重回旗舰市场的计算摄影大佬，终于肯用现代的 CMOS 了！机圈立即奔走相告，直到国外用户拿到真机，Anandtech 放出 Google Tensor 的测试成绩和分析……
在不改变 Anandtech 原意的情况下，我们对这颗如此重要和有趣的 SoC 的内容进行整理和编译，原文
全自研还是魔改（半定制）？Google 表示 Google Tensor 是迈向新型工作负载探索之旅的起点，现有芯片方案无法实现他们说的目标。凭借多年来的机器学习研究经验，Google 把 Tensor 做成一款以机器学习作为差异化的 SoC，据说其让 Pixel 能实现很多独特的新功能。
关于 Google Tensor 的第一个争议是，它是全自研？还是魔改（半定制）？这里主要看你对 “自研” 的定义，Google 和三星看似密切的合作，模糊了传统的自研和半定制之间的界限。
在 Google 内部， Google Tensor 代号是 GS101，可能是 Google SoC 或 Google Silicon 的意思。而之前爆料说的 Whitechapel（白教堂），还没有任何证据表明其是真实存在的芯片。
而 Google Tensor 基本遵循三星 Exynos 的命名规则，其 ID 是“0x09845000”，拆解后能看到丝印是 S5P9845（编者：原文发布之初，认为 ID 对应 S5E9845，但经 TechInsights 拆解，确认是 S5P9845）。作为参考，三星 Exynos 2100 的 ID 是 S5E9840，Exynos 1080 是 S5E9815。
几年前就有报道说三星开始提供半定制的芯片服务，当时就有三星与思科、Google 的合作消息。ETNews 在 2020 年 8 月的文章中提到，三星会根据客户需求提供“定制”技术和功能，甚至从芯片设计阶段就开始提供。
三星不再是简单的芯片制造商，而是完全参与芯片设计，这都可以和 ASIC 设计服务相提并论了。但这是个很特殊的情况，毕竟三星不但有台积电那样的芯片代工业务，它也有自己的自研 SoC。
Google Tensor 和三星 Exynos 高度同源，除了大家常说的 CPU、GPU、NPU 等高级结构外，芯片中的基本结构很多都是同源的。虽然纸面上，三星、联发科、海思，甚至高通（只有CPU方面），用的都是 arm 的 Cortex CPU 和 Mali GPU 公版架构，但它们的底层架构还是非常不同的。
Google Tensor 使用的是三星 Exynos 的框架，不但有相同的时钟和电源管理架构，它们的存储控制器、外部接口的 PHY IP 等高级块，甚至连 ISP 和媒体编解码器等较大的 IP 功能块都很相似。有趣的是， Github 上已经有 GS101 的公开信息，可以 1:1 地比较它和 Exynos 的结构组成。
不过，虽然用了 Exynos 的基础模块和框架，但 SoC 的定义确实由 Google 控制，结构和 IP 块之间的连接设计上，Google Tensor 和三星 Exynos 都是不同的。
例如 Exynos 上，CPU 是用总线连起来的，而 Google Tensor 的 CPU 集群是被集成在一个更大的 CCI 里面。从外部看，可能是用了不同的总线设计，也可能是完全不同的 IP。另外，像内存控制器的连接方式，它们也是不太一样的。
狂野的性能规格
单看 CPU 就知道 Google Tensor 和大路货不一样，2x X1 + 2x A76 + 4x A55，这个“2+2+4”结构在三星 Exynos 9820 和 Exynos 990 都出现过。但当今 Android 旗舰 SoC 中， 1+3+4 才是绝对的主流。而且敢堆 2 颗 X1 的，仅 Google 一家。
理论上有两颗 X1 超大核，其 CPU 多核性能会比单颗 X1 的产品更强。而频率上，Google Tensor 的 X1 都是 2.8GHz，略低于骁龙 888 的 2.84GHz 和 Exynos 2100 的 2.91Hhz。此外，Google 还和骁龙888 一样给了 1MB L2 缓存，比 Exynos 2100 的 512KB 残血 X1 更猛。
大核（编者：你喜欢叫中核也行）这边，Google 选择了古早的 A76 架构，这是件很有争议性的事（2.25GHz，256KB 的 L2 缓存）。毕竟这并不合理，因为 A77 和 A78 的性能和能效比都更高。连 Anandtech 都没从 Google 那里得到明确的解释。
他们猜测可能是几年前设计芯片的时候，三星手上也没有更新的 IP 供 Google 选择。也可能是在超大核换成X1 的时候，没有时间连大核也一起换了。但 Google 应该不是特意选用 A76 的，因为从下面的测试可以发现，A76 真的是跟不上时代了。
小核这边，4 个 1.8GHz 的 A55。Google 选择了 128KB 的 L2 缓存，而不是三星 Exynos 自己用的 64KB，这让这个 CPU 更像骁龙888 了。但比较奇怪的是，Google 把集群的 L3 缓存频率和 A55 绑定，这会导致延迟和功耗问题。另外，这也和 Exynos 2100 的 L3 频率是不同的。
Google Tensor 的 GPU 是 Mali- G78 MP20，规模仅次于麒麟 9000 的 G78 MP24（编者：G78 的极限）。大家最开始以为 Google 会用低点的频率来提升能效比。但结果 Google 竟然把着色器频率推到 845MHz，把 tiler 和 L2 频率推到 996MHz，简直癫狂。另外，它也是第一个用上 G78 分离频率特性的产品。
作为参考，Exynos 2100 的 G78 MP14 也“只是” 854MHz，后者的峰值功耗已经很高了。结果 Google 增加 42% 的核心，却依然维持高频。因此它的峰值性能很让人期待，但峰值功耗也会很猛。而内存控制器似乎和 Exynos 2100 相同，支持 4x16bit 的 LPDDR5，理论带宽 51.2 GB/s。
它也用了 8MB 的系统缓存，但还不清楚是否用了和三星 Exynos 2100 一样的 IP，因为它们的架构和行为方式都不太一样。Google 大量使用 SLC 来提升 SoC 性能（包括他们自己的定制模块）。这个 SLC 允许自分区，将 SRAM 专门分给 SoC 上特定的 IP 块，使它们在不同用例下，能对全部或部分缓存进行独占访问。
ISP 与 TPU：谷歌的光辉大家说 SoC 集成的 ISP 时，经常把它们描述为单个 IP。但实际上，ISP 是不同的专业 IP 块的组合，每个 IP 块处理成像管线中的不同任务。而 Google Tensor 非常有趣，因为它将三星用在 Exynos 芯片上的一些片段整合到了一起，同时还将自己开发的定制模块整合到了流水线中 —— 正如 Google 在展示 SoC 时所说的那样。
成像系统部分和 Exynos 是一样的，如相位检测处理单元、反差对焦处理单元、图像缩放器、畸变校正处理块和纹理遮挡函数处理块等。比 Exynos 少的部分，可能是三星的一些图像后处理模块。
谷歌在 ISP 中加入自己的 3AA 模块（自动曝光，自动白平衡，自动对焦） ，以及一对自己的时域降噪 IP 模块（用于对齐和合并图像）。这些很可能就是谷歌所说的那些有助于加速图像处理的模块，这些是 Pixel 系列计算摄影的一部分，毋容置疑地地代表了图像处理流水线中非常重要的部分。
TPU 是让 Google Tensor 被称为 Tensor 的地方。Google 已经用自研 TPU 好几年了，在驱动层面，Google 把 Tensor 的 TPU 称作 Edge TPU（ 端侧边缘 TPU）。这是相当有趣的信号，因为它应该和 Google 2018年发布的 Edge TPU 有关，后者是 Google 为边缘推理而设计的 ASIC 芯片（官网 cloud.google.com/edge-tpu）。
当年的 Edge TPU 宣称在 2W 功耗下可以提供 4TOPS 的算力，但 Google 并未公布 Tensor 的 TPU 性能指标，但是在一些测试中可以看到它的最大功率是 5W 左右。因此如果它们确实是有关联的，考虑到这几年的制程和 IP 上的进步， Google Tensor 的 TPU 性能应该有明显提升了。
这个 TPU 是谷歌芯片团队的骄傲，它正在使用最新的机器学习处理架构，这个架构针对 Google 内部运行机器学习的方式进行过优化，并且表示它可以允许开发新的、独特的用例，这是 Google 做定制 SoC 的主要目标和出发点之一。在后面的测试中，这个 TPU 的性能指标确实也是令人印象深刻的。因为 TPU 的信息不多，我们只能基于它的驱动程序做简单猜测，它可能包含四核心的 Cortex-A32 CPU。
其他模块：基带与音视频解码器
在媒体编码器方面，Google Tensor 使用了三星的多功能编解码器（与 Exynos 系列同款），还有一个看起来像是用于 AV1 解码的自研 IP 块。这有点奇怪，因为三星的宣传中， Exynos 2100 是有 AV1 解码功能的，而且这个功能貌似也在内核驱动程序里面。但在 Galaxy S21 系列中，这个 AV1 解码功能从未在 Android 的层面实现过。
谷歌加入的这个专用的 AV1 解码器被他们称做 “ BigOcean”，它能让 Android 系统具备 AV1 硬解能力。但非常奇怪的是，它真的就只负责 AV1， 其他格式编解码还是由三星的 MFC 负责。
Google Tensor 的音频子系统也不同，Google 用自己设计的 IP 块代替了三星的低功耗音频解码子系统，它们可以在无需全部唤醒 SoC 的情况下进行低功耗的音频播放。我们认为这部分也是当协处理器用的，这也是 Google Tensor 和 Exynos 不同的地方。
Google 还用了一种称为 Emerald Hill 的硬件内存压缩器，对内存页面进行 LZ77 压缩加速，反过来也可以用来加速交换中的 ZRAM 的卸载过程。现在还不确定 Pixel 系列是否已经启用这个模块，但能确认在“ /sys/block/zram0/comp_algorithm”目录中有“lz77eh”。作为课外资料，三星早在 5 年前，就在 SoC 里集成了类似的硬件压缩 IP 模块。但出于某些原因，这些模块从未被启用过，也许是能效比并没有他们预想中的高。
图源PBKreviews
另外，Google 还用三星的 Exynos 基带，做出了第一台非高通的毫米波手机。Pixel 6 系列用的是三星的 Exynos 5123 基带（译者：为遵循国内的习惯，这里把调制解调器称为基带）。三星在 2019 年就提到自己的毫米波射频和天线模块，说 2020 年会出现在量产机上（不知道当时是否计划让 Pixel 6 在 2020 年上市）。Pixel 6 系列的峰值速度可以达到 3200Mbps，但很多测试中，它的网速只有高通产品的一半左右。
虽然是同一个基带，但它不是像 Exynos 2100 那样集成在 SoC 里，而是外挂的。可能是因为 Google Tensor 的 GPU 和 CPU 规模太大了，而且 TPU 的规模也是未知数。毕竟就算是把基带外挂出去，Google Tensor 的规模也是相当大了，即便是和对比 Exynos 2100 的情况下。
总的来看，Google 确实设计和定义了 Tensor ，同时有很多 Google 特有的设计，是整体的芯片上的差异化。但从更底层的角度看，Tensor 和 Exynos 有很多共通之处，用了很多三星特有的基础模块，因此叫它“半定制”或许会更合适。
实际性能表现：不尽如人意
测试中，Google Tensor 的 DRAM 延迟较高，还不如 Exynos 2100，和骁龙888 比就更差了。Google 改过了内存控制器，它会根据负载和内核的内存失速百分比来控制 MC 和 DRAM 速度，这部分是和三星不同的，其实际利用率也不如三星的内存控制器高。现在不知道是 CPU 的问题，还是整个 SoC 内部的问题，但这确切地影响了下面的测试。
它的 L3 延迟也相当高，比 Exynos 2100 和骁龙 888 高得多。Google 没有给 DSU 和 CPU L3 缓存设定特定的频率，而是把它和 A55 小核的频率关联。奇怪的是，即便 X1 或 A76 满载，A55 和 L3 却在低频 “摸鱼”。同样情况下 Exynos 2100 和骁龙 888 都是会提高 L3 频率的。
在系统缓存测试中，能看到 11-13MB 的延迟情况 (1 MB L2 + 4 MB L3 + 8 MB SLC) ，在正常的内存访问中，Tensor 也是比 Exynos 要慢的，可能和被改过的个别缓存管线有关。
因为 L3 和 A55 的频率捆绑，且频率高，所以 Google Tensor 的 A55 小核是几个 SoC 里 L3 延迟最低的，彷如没有异步时钟桥一般。
CPU 部分，Google Tensor 更像是骁龙 888，而不是 Exynos 2100。虽然 Google Tensor 的 L2 缓存是 Exynos 2100 的 2 倍，但频率低了 3.7%（110MhHz）。
Tensor 的弱点是内存延迟，导致 SPEC 测试中很多子项目都比 骁龙888 和 Exynos 2100 慢，但能耗却更高（CPU 在干等内存）。SPEC 总分上，Tensor 的表现比 Exynos 2100 略差，对比骁龙888 的落后幅度达到 12.2% ，由于跑完测试的时间更长，最终耗电还多了 13.8% 。折算回来，相对骁龙888 的差距应该是 1.4% 左右。
它也有和 Exynos 2100 一样的降频问题，只是相对没有那么严重。如果冷却得当，性能会高 5%-9% 左右（上图的测试结果是在 11 度的环境下得到的）。
可怜的 A76 大核，骁龙 888 的 A78 比它强 46%，还更省电，实际 IPC 差距在 34%，这倒符合两个构架之间的差距。如果真是为了省电，完全可以做个低频的 A78，但结果 Google 放了两颗频率又高、又耗电、性能还不行的 A76，只能推断 Google 是没得选，而不是有意而为之。
越接近右下角，能效比越低；越接近左上角，能效比越高 ↑
A55 小核这边也不行，性能只是比同频的骁龙 888 的 A55 高 11%（感谢 L3 和 SLC），但却几乎是 2 倍的功耗，俨然就是继承了 Exynos 高功耗 A55 的血统，能效比甚至比自己的 A76 大核还拉胯。看看联发科天玑 1200 的 A55，再看看 A14 的能效核心，这真是个残酷的世界。
Google Tensor 因为拉胯的 A76 性能表现，就算有 2 颗 X2 都无力回天，拖低了整体分数。X1 本身也比对手稍慢一些，大部分时间的能效比都和 Exynos 2100 的 X1 一致。但 A76 实在落后时代太多了（无论是性能还是能效比），而 A55 又继承三星低能效的传统，一言难尽就是了。
GPU 这边规模大，频率高，但 3DMark Wild Life 测试的峰值性能只比 Exynos 2100 高 21%。在 GFX Bench 的 Aztec 场景测试中，领先 Exynos 2100 14%，小幅领先骁龙888。虽然采用了分频设计，但貌似瓶颈在 GPU 的其他地方。
Tensor 的 GPU 峰值功率高达 9-10W，手机一跑就降频（一轮测试都没跑完啊……），拖低了整体功耗，所以才会有 7.28 W 的平均功耗。Pixel 6 系列没有热管，散热配置和机身结构更像是 iPhone，而不是猛堆散热的安卓旗舰。它跑起来时，左侧的 SoC 45 度，但右侧只有 30-33 度，散热确实是弱。
让人不解的是，今年这批 SoC 都设定了高得不切实际的 GPU 频率，一跑就降频。可能是为了应对突发的 GPU 负载？或者是其他什么原因？但无论怎么样，实际能效比是受累了。
而 Tensor 的功耗问题，外加 Pixel 6 Pro 虽然也是LTPO屏幕，但表现和三星旗舰明显不同，全屏激发亮度750nit，远低于 S21U 的 942 nit，实际正常基础功耗可能会更高。多种不利因素，最终让 Pixel 6 Pro 的续航并不好看，反倒是 90Hz 的 Pixel 6 续航表现还不错：
TPU：极强的推理性能这是 Google Tensor 挽回颜面的地方。MLPerf 测试中，Pixel 是在 NNAPI 跑的，其他厂商是各自的库，高通是 SNPE（最近优化了 MLPerf 1.1，提升了成绩）、三星是 EDEN，联发科是 Neuron，而苹果没有 coreML 加速，所以吃亏。
在图像分类、目标检测和图像分割工作负载中， Tensor 成绩低于高通，但强于三星。而在语言处理（MobileBERT 模型），Google Tensor 提供了骁龙 888 3 倍的性能，推理部分强得很。Google 在宣传里，确实也提到过实时转录、翻译等使用场景是其差异化所在。
还没发布的 GeekBench ML 测试，用是 TensorFlow 模型，代表的是 GPU 的机器学习性能。这时候 Google Tensor 就弱于 Exynos 2100。如果用 NNAPI 模型，此时是 CPU+GPU+NPU 的混合工作，Google Tensor 就可以大幅领先骁龙 888。
除了绝对性能，跑 AI 测试时，Pixel 6 Pro 的整机功耗和 Exynos 2100 的 Galaxy S21 Ultra 接近。单独进行推理任务时， Exynos 2100 的爆发功率达到 14W，骁龙 888 也有 12W。但因为 Google Tensor 的 AI 性能更高，所以最终能效比要更高一些。
不过 Google 还没有计划推出相关的 SDK 让开发者去更好地利用这颗强大的 TPU 。但再看看三星，它的 NPU 发布都 2 年了，现在都没有 SDK…… 现在 TPU 的强大性能，主要集中体现在官方 app 里，像是给摄像头加入更多的机器学习功能，以及各种翻译功能。
总结Google 表示，他们搞自研 SoC 的主要原因是现有的 SoC 在机器学习上的性能和能效比太低。而 Tensor 的机器学习性能和能效，被用来支撑新的用例和体验，例如我们在 Pixel 6 系列上看到的很多机器学习特性。像是实时转录、实时翻译和图像处理等算法，所有这些都是运行在 Tensor 的 TPU 上的。
虽然 Google 可能不想承认或者谈论，但 Google Tensor 确实就是和三星合作的产物，大部分都源自 Exynos，并继承了三星在能效比方面的弱点。CPU 被古老的 A76 拖后腿，规模庞大的 GPU 被散热拖后腿，但 TPU 确实表现很好，特别是自然语言处理方面，远远抛离所有竞品。
但总的来说，我们认为 Google 已经通过 Tensor 实现了最初的目标。我们不知道 Google 下一代的 SoC 会走什么样的路线，但我们很有兴趣等等看。
