千家论坛_智能建筑与智能家居技术交流社区

标题: 谁家有好的井下考勤系统?大家讨论一下,井下考勤系统要起到一个什么作用?? [打印本页]

作者: zj2cl    时间: 2004-12-10 14:55
标题: 谁家有好的井下考勤系统?大家讨论一下,井下考勤系统要起到一个什么作用??
<P>有成熟和稳定系统的请给我一份资料,谢谢!我的Mmail:dapeng@Jndp.com qq:82112944</P>
<P>讨论:</P>
<P>随着我国矿难的一次次发生,井下管理成了一个热门的话题,我觉得我们智能卡行业,也应该为我们的矿井管理尽一份力量。</P>
<P>我觉得好的井下管理系统应该有以下几个功能:</P>
<P>1、能过远距离读卡,至少能在半米以上。</P>
<P>2、能够实时明显的提示显示井下有多少人,每个人在井下已待了多长时间。</P>
<P>3、应该完工上井而没有的人,超过一定时间系统应该对其进行声音和颜色方面的报警提示。</P>
<P>4、提前出井的人员也能够在系统上进行提示。</P>
<P>5、最好能够接一个大的屏幕,能够实时显示井下人员名单和已在井下带了多长时间。</P>
<P>这是我的考虑的应该具有的功能,那位还有好的建议请留下。</P>
<P>我们积极探讨一下。</P>
<P>---------------------------------------------------------------------------------------------------------------------------------------</P>
<P>济南大鹏信通科技有限公司</P>
<P><a href="http://www.jndp.com" target="_blank" >www.jndp.com</A></P>
作者: sonier    时间: 2004-12-10 17:06
这个想法值得支持,我觉得不错,应该大多数产品都可以实现!
作者: 凡海    时间: 2004-12-10 17:12
感觉布线是最大的困难
作者: zj2cl    时间: 2004-12-11 09:51
<DIV class=quote><B>以下是引用<I>凡海</I>在2004-12-10 17:12:00的发言:</B>
感觉布线是最大的困难</DIV>
<P>这个可以不在井下布线,是否可以在井口或下井的通道中安装读卡器,这样的话就不会有布线的问题。是不是那</P>
作者: zj2cl    时间: 2004-12-13 10:08
<P>谢谢搂主,把本贴加为精华!</P>
<P>但好像来讨论的人不多啊?欢迎高手来探讨!!</P>

[此贴子已经被作者于2004-12-13 10:15:11编辑过]


作者: sagmac    时间: 2004-12-13 17:02
<P>可以采用离线式的啊!</P>
作者: CityGrass    时间: 2004-12-15 19:03
<P>这个想法不错 , 但不应该在考勤系统里完成。</P><P>应该属于定位系统 ,建议做成定位系统 ,  随时坚测人员位置</P>
作者: Cindy_Gong    时间: 2004-12-15 21:38
好想法,支持
作者: davei    时间: 2004-12-16 10:56
<P>是考勤门禁系统,这方面有客户提过,跟消防一样,当起火后,总进去了多人,里面现有多少人,屏幕上实时显示,当每个人在里面有多少,进去到了时间的人要自动提示,跟网吧收费管理一样,如两个小时一到,屏幕上就会列出祥细明单,这个就是要实时的才行。布线难,可以通过无线。</P>
[此贴子已经被作者于2004-12-16 11:00:14编辑过]


作者: davei    时间: 2004-12-16 11:04
有个疑问,如果装了这个系统再发生事故,会再死人吗?我们起到的只是知道里面死了多少人,死了哪些人名单资料。不能防止死人。
作者: zj2cl    时间: 2004-12-21 12:17
<DIV class=quote><B>以下是引用<I>davei</I>在2004-12-16 11:04:00的发言:</B>
有个疑问,如果装了这个系统再发生事故,会再死人吗?我们起到的只是知道里面死了多少人,死了哪些人名单资料。不能防止死人。</DIV>
<P>对,如果事故死人我们这套系统是不能避免的,但我们能通过监控,增强矿井的管理,同时在一定程度上,也能降低矿难得发生率。</P>
作者: szxjd    时间: 2004-12-21 15:12
<P>可以用门禁的软件,记录人员的下井时间,在控制室里把下井最多待的时间写入事件,时间过了而没有打出门卡的,系统自动提示并报警通知控制台的人,再利用扩音或井下通讯通知人员等,总之,任何危险都写入事件,就能及时提示并报警。</P><P>以色列SYNEL公司出品的FALCOM软件,是全公开的事件写入,根据客户自己的要求,自己把事件写入,很不错的。</P>
作者: yvhkfniaqg    时间: 2004-12-23 09:36
布线的困难下,是否可以采用无线网络进行数据上传呢?采用AP等无线网络设备或许可不用布线。但现在无线网络许多不适合在井下用的,因为井下是弯曲的路,信号有所受阻!
作者: davei    时间: 2004-12-24 14:01
<P>创维煤矿系统也有做了的成功例子,通过认证,做安防的比较轻楚,具体资料太多,我只稍了解了一下。</P>
作者: zj2cl    时间: 2004-12-29 09:01
<DIV class=quote><B>以下是引用<I>davei</I>在2004-12-24 14:01:00的发言:</B>

<P>创维煤矿系统也有做了的成功例子,通过认证,做安防的比较轻楚,具体资料太多,我只稍了解了一下。</P></DIV>
<P>有案例吗?是哪儿的公司??</P>
作者: cgcoco    时间: 2004-12-30 15:55
<P>我以前给客户做过类似的方案,需要注意的是</P><P>1、卡片的读写距离必须远,矿工不会自己跑到读卡机面前去刷卡的</P><P>2、有关设备,包括卡片、卡机等,必须通过国家级别的测试检验,大多是防爆之类的,这个是最重要的</P><P>3、系统本身并不复杂,所有的功能都在井上实现,井下不要去考虑</P>
作者: 银月骑士    时间: 2004-12-30 20:05
为什么我不能回复???
作者: 银月骑士    时间: 2004-12-30 20:11
<P>我觉得开发可以代替人在井下工作的智能机器更合适。</P><P>我们可以研发远程控制的采矿车和装载车来代替我们到井下工作,而我们只需要在地面上进行视频监控就可以了;</P><P>减免事故发生最好就是没有人在事故现场。</P>
作者: zj2cl    时间: 2005-1-12 13:59
<DIV class=quote><B>以下是引用<I>银月骑士</I>在2004-12-30 20:11:00的发言:</B>

<P>我觉得开发可以代替人在井下工作的智能机器更合适。</P>
<P>我们可以研发远程控制的采矿车和装载车来代替我们到井下工作,而我们只需要在地面上进行视频监控就可以了;</P>
<P>减免事故发生最好就是没有人在事故现场。</P></DIV>
<P>呵呵,大哥,现在又这么好的技术吗</P>
作者: 银月骑士    时间: 2005-1-12 14:21
<P>说到底,还是智能控制的问题。</P><P>我有这样的想法:现有的机器智能控制技术已经基本可以应用在工业生产中,但对于过于复杂的工作环境,还是不能自动</P><P>处理。针对井下采矿这种复杂的环境,必须加以人为干涉和人为辅助控制。在井下工作的机器加上照明灯和视频监视器,人工根据环境的实际情况对机器进行引导工作 </P>
作者: szxjd    时间: 2005-1-14 09:57
<P>这样死的人更多,1.线路是有点的,井下的环境黑容易产生危险吧;</P><P>2.用无线的,那技术要比军工的还厉害,井下的深度怕连雷达都探不到吧;</P>
作者: 杨龙    时间: 2005-1-17 17:02
<P>用无线的技术不就可以了吗!</P><P>0755-82971288 </P><P>杨生</P>
作者: davei    时间: 2005-1-17 17:58
<P>不用行不行。</P>
作者: 齐安智能    时间: 2005-1-26 15:46
最好带有定位系统能知道井下人员的大体位置,便于营救
作者: 南京国冉科技    时间: 2005-4-23 22:21
大家好&lt;南京国冉科技大型一卡通系统集成商欢迎大家合作,13245812358     QQ237742249
作者: zj2cl    时间: 2005-5-18 09:18
<P>大家没有好一点的煤矿考勤系统了吗?1、数据一定要是实时传输的!2、能够实时的显示井下有多少人!3、能够长距离读卡</P>
作者: zksoftware    时间: 2005-5-24 17:21
<P>其实满足以上的条件很简单。当然还需要有防爆的认证。产品很多啦</P>
作者: mtexpo    时间: 2005-5-24 18:10
<P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><FONT size=3>1.</FONT>      </FONT><FONT size=3>长距离<FONT face="Times New Roman">reader  </FONT>没有问题!可以<FONT face="Times New Roman">90~130cm</FONT></FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><FONT size=3>2.</FONT>      <FONT size=3>rs485 or TCP/IP</FONT></FONT><FONT size=3>没有问题!</FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><FONT size=3>3.</FONT>      <FONT size=3>TAG </FONT></FONT><FONT size=3>封于头盔中没有问题!</FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><FONT size=3>4.</FONT>      </FONT><FONT size=3>数据接收<FONT face="Times New Roman"> </FONT>没有问题</FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT face="Times New Roman"><FONT size=3>5.</FONT>      </FONT><FONT size=3>应用软件<FONT face="Times New Roman"> </FONT>请配合应用另外开发</FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT size=3></FONT> </P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT size=3><a href="mailtmtexpo@yahoo.com" target="_blank" >mtexpo@yahoo.com</A></FONT></P><P 0cm 0cm 0pt 18pt; TEXT-INDENT: -18pt; mso-list: l0 level1 lfo1; tab-stops: list 18.0pt"><FONT size=3></FONT> </P>
作者: 游魂    时间: 2005-5-26 18:38
楼主的IDEA不错,受教了,继续关注中
作者: zj2cl    时间: 2005-5-27 13:41
<P>通过了解现在市面上主要有两种做法:</P><P>1、采用1m左右的读卡器,主要做考勤和进出井口管理使用,目的是用来纪录每个员工的下井时间和出井时间以及再井下的总时间。这样的系统类似于普通的考勤机,当然不需要工人刷卡,在1。30米内自己感应读卡。还有上面拿个兄弟说的读卡头要符合防爆标准。</P><P>2、采用超远距离读卡器(微波技术),采用有源射频卡,这种读卡器读卡距离很远有的能到几十米,这样的系统装在井下一是可以考勤,实现上面的功能,二还可以给矿工定位,出现事故便于营救。当然这样的系统要求很高,而且造价也很高。</P>
作者: llqandy    时间: 2005-5-27 17:48
<P>我在2003年,考虑将3维GIS和刷卡系统集合起来,实现在虚拟井道中的,矿工的考勤与分布(指在一些节点后)。这个想法和当地的矿物局交换了意见,终究是难度大,没有实施。</P><P>不过我认为是一个研究方面</P><P>刘立权</P><P>安徽银安智能科技有限公司</P><P>0551-2880119</P>




欢迎光临 千家论坛_智能建筑与智能家居技术交流社区 (http://bbs.qianjia.com/) Powered by Discuz! X3.2