首页
学习
活动
专区
圈层
工具
发布
    • 综合排序
    • 最热优先
    • 最新优先
    时间不限
  • 电池分容老化测试系统功能说明书

    1.概述本电池分容老化测试系统面向锂电池化成、老化、分容全流程测试场景,集成电芯性能算法测算、全维度安全保护、多通道设备管控、AI实时异常诊断、工单追溯管理、能耗成本核算、可视化数据分析、多设备适配与MES 2.核心算法与性能测算功能2.1电池SOH与寿命预测精准SOH估算:基于充放电时序数据、容量衰减特征,实时测算电芯健康状态,适配全生命周期电芯测试场景。 2.2容量与微分特性分析电容量档位归档:自动采集电芯容量数据,按照预设档位规则完成容量分级、归档分类,适配量产分容定级需求。 8.测试工步与批量任务管理8.1可视化工步编辑器支持可视化自定义测试工步,内置恒流、恒压、静置、循环、阶梯、脉冲、老化、化成、分容等标准工步模块,支持自由组合编辑测试工况仿真波形点,适配各类电池测试工艺 、多硬件设备适配、智能任务调度、工单全流程追溯、可视化数据分析、MES系统对接、权限审计与报告导出,全面满足电池化成、老化、分容量产测试与品质管控需求。

    19010编辑于 2026-08-07
  • 基于AI驱动的锂电池分容老化智能测试平台

    标准工步测试系统可视化工步编辑器:恒流、恒压、静置、循环、阶梯、脉冲、老化、化成、分容工步模板保存、批量导入导出、配方版本管理多通道独立运行、互不干扰,支持16/32/64/128通道设备自定义阈值保护 标准化报表与导出自动生成:分容报告、化成报告、老化测试报告、抽检报告导出格式:Excel、PDF、CSV,可自定义企业模板良品/不良品自动统计、批次合格率、数据汇总5.实时采样与AI推理离线部署持续采样电压

    29110编辑于 2026-08-07
  • 电池生产总怕“踩坑”?这款分容老化测试系统,可能就是你的“避雷针”

    做电池的朋友都知道,化成、分容、老化这几个环节,看着是常规流程,其实最让人头大。 今天想跟大家聊聊我们这款电池分容老化测试系统。它不只是个测电压电流的机器,更像是一个给电池做“深度体检”的专家,外加一个精打细算的“管家”。1. 测电池太费钱?让它把电“赚”回来分容老化是出了名的“吃电大户”。但你可能不知道,放电测试时的能量其实是可以回收的。我们的系统联动了EMS能耗管理,能精准算出你回收了多少电、省了多少钱。 直接把系统里的能耗报表甩给他就行,每一分钱的去向都清清楚楚。3. 告别“两眼一抹黑”,电池健康一眼看穿很多时候,测完了只知道容量够不够,但电池到底能活多久?内阻变化趋势如何? 分容定级不再是简单的“排排坐”,而是精准的“优中选优”。4. 它是懂“安全”的,反应比人快多了安全是红线,谁也踩不起。

    17610编辑于 2026-08-12
  • 来自专栏算法修养

    HDU 3388 Coprime(容斥原理+二分)

    Sample Input 3 6 9 1 6 9 2 6 9 3 Sample Output Case 1: 1 Case 2: 5 Case 3: 7 这里有两个数n,m;这里用容斥原理同样可以求在 用二分去找n,上限直接设成1<<62#include <iostream> #include <string.h> #include <stdlib.h> #include <math.h> #include 0) m/=prime[i]; } } if(m>1) sprime[cnt++]=m; } LL Ex(LL n)//容斥原理

    90150发布于 2018-04-26
  • 来自专栏算法修养

    POJ 2773 Happy 2006(容斥原理+二分)

    Happy 2006 Time Limit: 3000MS Memory Limit: 65536K Total Submissions: 10827 Accepted: 3764 Description Two positive integers are said to be relatively prime to each other if the Great Common Divisor (GCD) is 1. For instance, 1, 3, 5, 7, 9..

    85670发布于 2018-04-26
  • 来自专栏Angular&服务

    mac 电脑控制电池充电百分比

    这条命令执行的时候会提示你输入密码,输入你的开机密码再回车即可(输入密码的时候光标是不会动的,其实已经输进去了)。

    1K30编辑于 2023-02-16
  • 来自专栏Apsara

    如何设计动态扩容缩容的分库分表方案?

    面试官:如何来设计动态扩容的分库分表方案? 面试官心理剖析: 这个问题主要是看看你们公司设计的分库分表设计方案怎么样的?你知不知道动态扩容的方案? 回答: 背景说明:如果你们公司之前已经做了分库分表,你们当时分了 4 个库,每个库 4 张表;公司业务发展的很好,现在的数据库已经开始吃力了,不能满足快速发展的业务量了,需要进行扩容。 3)动态扩容方案 比如你直接分 32 个库,每个库分 32 个表; 每个库的每秒写入并发是 2000,单表的数据量为 700 万; 每秒写并发:32 个库2000=64000 数据量:1024 个表7000000

    1.5K00发布于 2020-04-12
  • 来自专栏码上修行

    如何设计可以动态扩容缩容的分库分表方案?

    但是最好别这么玩儿,有点不太靠谱,因为既然分库分表就说明数据量实在是太大了,可能多达几亿条,甚至几十亿,你这么玩儿,可能会出问题。 从单库单表迁移到分库分表的时候,数据量并不是很大,单表最大也就两三千万。那么你写个工具,多弄几台机器并行跑,1小时数据就导完了。这没有问题。 谈分库分表的扩容,第一次分库分表,就一次性给他分个够,32 个库,1024 张表,可能对大部分的中小型互联网公司来说,已经可以支撑好几年了。 一个实践是利用 32 * 32 来分库分表,即分为 32 个库,每个库里一个表分为 32 张表。一共就是 1024 张表。 哪怕是要减少库的数量,也很简单,其实说白了就是按倍数缩容就可以了,然后修改一下路由规则。

    1.5K20发布于 2019-11-22
  • 来自专栏软件工程

    如何设计可以动态扩容缩容的分库分表方案?

    目前消息中心的量级还不是很大,大概每天200多W数据的样子,并发也就几十到两百,其实一两年内都不一定有并发的问题,按道理来说只要分表就可以了,但是凡是还是必须考虑长远点,目前还是需要考虑分一下库,那么分多少库呢 设计可以动态扩容缩容的分库分表方案其实就是对我们服务的发展做一定的评估,根据吞吐量来计算要求的数据库梳理(比如一个数据库服务器2000并发,我们预计达到1W就设计5个库),根据数据量大小计算表数据(比如一个表我们最多放

    1.6K10编辑于 2021-12-24
  • 来自专栏开元说说

    容灾系列(六)——数据存储容灾建设

    数据存储容灾建设主要从数据可靠性和业务稳定性两个维度阐述。这两者有哪些区别呢?

    5.2K73发布于 2021-11-18
  • 来自专栏腾讯云中间件专家服务

    客户容灾案例—zookeeper容灾迁移方案

    在至少有一个Leader存在的前提下,进行Zookeeper的在线增量、在线减量、在线迁移 在全过程中ZooKeeper不停止服务

    2.5K51发布于 2021-07-26
  • Go map缩容机制:原来这是“伪缩容”?

    不少开发者会误以为“删除元素就会释放内存”,实则Go map的缩容逻辑藏着特殊设计——它并没有真正意义上的“缩容”,只有针对溢出桶的“等量扩容”优化。 缩容的触发条件 Go map不会因为元素被大量删除、负载因子过低而主动缩小哈希表容量,其“缩容”仅在一种场景下触发:溢出桶数量过多。 当溢出桶数量达到阈值时,就会触发“缩容”逻辑。 这是“伪缩容”,而非真缩容 Go map的扩缩容统一由hashGrow函数处理,但缩容和扩容的核心区别在于是否改变哈希表总容量(即hmap.B的值): 扩容逻辑:当负载因子超过6.5(元素数>6.5×普通桶数 缩容的执行过程:渐进式迁移 和扩容一样,缩容的数据迁移也采用“渐进式”策略,避免一次性迁移大量数据导致性能抖动。

    37510编辑于 2026-01-27
  • 来自专栏开元说说

    容灾系列(三)——云网络容灾建设

    IDC时代,业务对网络容灾参与较少,主要依赖数据中心网络容灾建设程度;当到了云的时代,云服务商将底层网络能力产品化后,云上客户更多参与网络容灾建设,提升业务稳定性。 例如2019年3月,上海电信公网异常,云侧从故障发现到恢复用了2分钟。详见http://www.etudu.com/?id=67。 2)跨区或者跨地域云基础设施容灾能力。 通常云服务厂家数据中心建设均有容灾能力,这里建议还是选择大厂。 3)IDC到云上网络高可用建设。 混合云容灾模式,这里考虑到IDC和云上线路容灾情况,一般建议两条专线接入不同的POP点来进行容灾建设;同时建立VPN或者GRE公网逃生通道来紧急恢复业务。 image.png 3.2 混合云网络容灾 混合云网络容灾分为两个部分: 1)idc和云机房之间线路容灾,主要线路分为专线和VPN。

    6.4K93发布于 2021-08-09
  • 来自专栏小樱的经验随笔

    容斥原理

    容斥原理 对容斥原理的描述 容斥原理是一种重要的组合数学方法,可以让你求解任意大小的集合,或者计算复合事件的概率。 容斥原理的证明 我们要证明下面的等式: ? 对于实际问题的应用 容斥原理的理论需要通过例子才能很好的理解。 首先,我们用三个简单的例子来阐释这个理论。然后会讨论一些复杂问题,试看如何用容斥原理来解决它们。 所以,我们要运用容斥原理来解决。 我们可以用2^k的算法求出所有的pi组合,然后计算每种组合的pi乘积,通过容斥原理来对结果进行加减处理。 · 然后,利用容斥原理,求出2到n每个数的cnt[i]:在2到n中不与i互素的数的个数。 回想容斥原理的公式,它所求的集合是不会包含重复元素的。

    2.7K70发布于 2018-04-08
  • 来自专栏点滴科技资讯

    分拆特斯拉:电动汽车和电池行业是如何被颠覆的

    下载完整报告加入点滴科技资讯知识星球

    1.2K30编辑于 2023-03-01
  • 来自专栏联远智维

    电池安全监测

    年诺贝尔化学奖;然而,电池发生爆炸、鼓包的情况时有发生,大大降低了企业在公民心中的可信度,因此,电池的安全监测具有显著的意义,本文针对具体的工程问题(新能源汽车电池安全监测),依据课题组前期的技术积累, (电池具体结构等见附2),占用的空间极小);2、该传感器对外形(曲率)的变化十分敏感,在项目中能够确保良好的测试精度,具体的技术细节如下所示: a. 锂电池主要的材料构成:正极材料、负极材料、电解液、隔膜,调研可知,电池鼓包的原因主要包含:1、电池制造过程中电极涂层不均匀,生产工艺比较粗糙引起的;2、电池使用过程中过充电和过放电引起的;导致电池在使用过程中 附2、锂电池的加工工艺? 锂电池依据使用场景的不同,在外观上呈现片状和圆柱状两种外形;两种外形锂电池具体的封装流程如下图所示: 附3、隔膜材料是什么,能否采用传感器PI替代? ;于此同时,是否可以集成温度等传感器,在后端通过多源数据融合等相关算法,对电池的运行状态进行解算,确保电池的安全运行。

    2.3K20编辑于 2022-01-20
  • 来自专栏Html5知典

    【设备】电池状态

    概述 电池状态(Battery Status)API是通过navigator的battery属性来实现的,battery对象提供了有关系统电池级别的信息,还定义了一些当电池电量或状态发生变化时触发的事件 因此WEB应用程序可以监视电池的状况以做一些相应的处理,比如电量不足的时候把数据做个离线保存等等。 代码示例 浏览器支持检测 通过以下代码可以事先检测浏览器是否支持本API。 if(navigator.battery) { //支持此API } else { //不支持此API } 监视电池状态 Battery Status API 允许我们监听四个事件, 其中每一项都可以映射到 dischargingtimechange 当剩余时间直到电池完全放电变化时触发。 levelchange 当电池级别已更改时触发。

    99120发布于 2019-11-26
  • 来自专栏开元说说

    容灾系列(九)——异地数据冷备容灾建设

    2.3 数据库备份服务数据库备份服务拥有一套完整的数据备份和数据恢复解决方案,具备实时增量备份以及快速的数据恢复能力,同时具备异地容灾能力。

    11.1K164编辑于 2022-09-19
  • 来自专栏开元说说

    容灾系列(八)——同城数据冷备容灾建设

    为了让企业能更好用好云平台的数据安全能力,本文重点云平台数据备份冷备能力,以腾讯云为例,主要从以下两个维度介绍:同城数据冷备能解决企业什么问题,达到怎么样业务容灾效果? 同城冷备份方案同城数据冷备方案主要依赖于云平台能力备份能力,对现有业务架构没有任何改造,方案架构如下:图片该方案核心要点说明:数据备份:云侧数据库mysql和redis在控制台设置数据备份参数,数据备份存储在COS,具备地域级别容灾 指标详细说明容灾能力具备同地域(不同可用区)数据备份能力,不具备不同地域的能力。 3.容灾演练能力建设,增加平时运维成本以及自动化工具开发功能。

    8.7K113编辑于 2022-09-15
  • 来自专栏云计算文章

    容灾的架构分析和容灾选择策略

    1.传统容灾中心的架构 容灾半径是衡量容灾方案所能承受的灾难影响范围的指标。不同灾难的影响范围是不同的,而距离也会影响到容灾技术的选择。 容灾中心的架构按照源备端之间的距离,可分为本地容灾、同城双活、两地三中心。 1.1本地容灾 本地容灾一般指主机集群,当某台主机出现故障,不能正常工作时,其他的主机可以替代该主机,继续正常对外提供服务。 2.容灾级别与能力 容灾系统按保护级别可分为:数据级容灾、应用级容灾、业务级容灾。 4.云容灾级别和能力 参考传统容灾的级别划分,由于云容灾的基础设施采用了云平台,在云容灾的级别划分上,应用级和业务级的区别已经不大了,因此在这里将云容灾的容灾级别分为:数据级容灾、业务级容灾。 用户使用Zerto,用户可以得到可靠的,接近实时的服务器复制,而花费仅仅是SAN阵列式复制成本的一小部分。

    4.3K30编辑于 2022-04-29
领券