Introduction WildFire A Scalable SMP Solution

Arm Thermal/Power Managementfrom software perspectiveAgendaPlatform OverviewIntelligent Power Allocation (IPA) Energy Awareness Scheduling (EAS)Cortex-A CPU software▪Trusted Firmware▪Manages CPU boot▪Handles runtime service calls from OSPM, DVFS▪UEFI/Uboot▪Linux/Android OS▪GPU & Media subsystems managed via user space & kernel drivers▪Secure TEE (Trusted Execution Environment)Arm Hardware OverviewGIC-500Memory System LP DDRMediaDRAMVideo V500Display DP500CoreLink CCITZC-400big.LITTLECortex-M3MMU-500NIC-400Cortex-A72Cortex-A53MMU-500SCPMali-T880GPUNIC-400PeripheralsOnchip ROMOnchip SRAMSimplified hardware blocks for Arm typical mobile subsystem•Emphasising where software components runCortex-M System Control software▪SCP Firmware▪Boots from secure ROM ▪Manages system bring up ▪Responds to runtime power / frequency change requests ▪Thermal managementNVICArm Software OverviewOpenEmbedded LinuxAArch64(AArch32) SupportAndroidAArch64(AArch32)SupportMali User Space DriverIntegrationLinux KernelLSK IntegrationDevice Drivers including Mali KernelAdvanced Scheduling(HMP or EAS)Advanced Thermal Managment (IPA)AP FirmwareUEFIBoot Manager ExampleDevice DriversTrusted Boot Firmware Trusted Board Boot Test S-EL1 PayloadExample SMC & InterruptHandlingAP Boot ROMTrusted Board BootEL3 Runtime FirmwareSMCCCPSCIWorld Switch LibraryS-EL1 Payload DispatchSCP FirmwareSCP Runtime FirmwareSystem Control & Power Interface (SCMI)SCP Boot ROMBoot ProtocolPlatform Boot InitializationSystem and PowerControl FirmwareIPA/EAS HierarchySCP RuntimeFirmware System Control & Management Interface(SCMI)Message HandlingUnit(MHU)Linux KernelEL3 Runtime firmware Test Secure-EL1 PayloadIntelligent Power Allocation (IPA)Energy Aware Scheduling (EAS)CPUFreq CPUIdle Hotplug ManagementPower State Coordination Interface(PSCI)Example PSCI SMCHandlingCPU ON/OFFGet Thermal SensorReadingsGet StatisticsSet Dynamic Voltageand Frequency ScalingSet CSS Power State(Secure Channel)CPU SuspendStatisticsSystem Control and Management Interface (SCMI)SCMI is a set of OS-independent software interfaces that are used in system managementSystem Management and Control Interface (SCMI)OSPlatform ControllerExternal DeviceDevice PerformanceDevice PowerACPI/DTPSCIArm Trusted FirmwareAP PowerAP PerformanceDevice PowerSensorPower Protocol PerfProtocol Clock Protocol Sensor ProtocolPower Protocol Power Protocol MailboxPower Protocol Power Protocol Other TransportIntelligent Power AllocationIPA OverviewIPA Software StructureIPA BenefitUnity the Chase:T/˚CEnlighten T ransporter: T/˚CEnergy Awareness SchedulingScheduling policy determines task placement•Affect performance and energy consumption.Mainline Linux policy is ‘work preserving’:•Considers only maximizing throughput•DVFS and idle-states controlled by independent policy governorsDesigned for SMP•Not energy-awareOS task scheduling –throughput policyCapacityUtilization0123Max capacity Waking task?CPU cluster 01Current capacityLinux v5.0 adopted EAS in Feb 2019!EAS policy•Pick CPU with sufficient spare capacity and smallest energy impactRequirement•Tracking of task utilization •Platform energy modelSupports all topologies, including SMP and big.LITTLE Question ：•Waking task is better to be placed on which CPU?OS task scheduling –energy-aware policyCapacityUtilization0123Max capacity bigWaking task?CPU clusterLITTLEbigCurrent capacityMax capacity littleModel data tables for all power and frequency domains in the system•The system power is decomposed into power contributions for each cluster, and clusters are decomposed into cores and cluster resources (L2, SCU,…)•The core power is a function of its utilization (busy vs idle), the frequency when busy, and which idle-state entered when idleDecomposable energy modelCore 0Core 1Cluster (L2, SCU, …)GGGVGGCCore 2Core 3Cluster (L2, SCU, …)GGGV GGCG GC VVoltage regulatorPower Gate Power DomainClock Source Clock GateWaking task can be placed on either CPU1 or CPU3•Based on the Power/Performance curve, placing on CPU1appears to be a better choice •These kinds of trade-offs would be difficult to get right without an energy model –Had the little curve been more steep towards the end –Had there been more sibling coresthe energy impact on the sibling cores might have justified putting the task on the big CPU (1) insteadAn example -estimating energy impactCompute capacity (Performance)CapacityUtilization0123Max capacity bigWaking task ?CPUclusterLITTLEbigCurrent capacityMax capacitylittle Placing the task on CPU1:P-state change forCPU0 and CPU1Placing the task on CPU3:No P-state changes.CPU 0, 1CPU 2, 3LITTLE CPUbig CPU PowerActivity Monitor Unit (AMU)cp15cp15cp15SoCCore XCore Y Core ZOSPM AMUOSPM AMUOSPM AMUSystem InterConnectSCP(Power Control)BMCCPUfreq & DVFSmemory-mappedIntroduced as a optional Armv8.4-A architecture extension•For power-performance managementFree-running read-only event counters •Application SW and power controller FW as clients Example applications•Performance monitoring (ACPI CPPC)•CPU utilization, progress and indicative power measures•Scalability estimation for frequency allocation under a power or thermal constraintHikey960 Little Cluster pstatesHikey960 Single Core Power/Performance Curve。

CORTEX XDRHunt down and stop stealthy attacks by unifying network, endpoint, and cloud dataBreak Down Silos to Simplify Your InvestigationsSecurity teams often lack the visibility and automation required to stop attacks. Siloed tools like endpoint detection and response (EDR) and network traffic analysis (NTA) collect large amounts of data, but they also force analysts to pivot from console to console to verify threats, increasing complexity and slowing down investigations. Faced with a shortage of cybersecurity professionals, teams must simplify their operations, or they will struggle to investigate and stop attacks.Quickly Detect, Investigate, and Respond to ThreatsCortex XDR™ is the world’s first detection and response app that natively inte -grates network, endpoint and cloud data to stop sophisticated attacks. Leveraging behavioral analytics, it identifies unknown and highly evasive threats targeting your network. Machine learning and AI models uncover threats from any source, including managed and unmanaged devices.Cortex XDR speeds alert triage and incident response by providing a complete picture of each threat and revealing the root cause automatically. By stitching different types of data together and simplifying investigations, Cortex XDR reduces the time and experience required at every stage of security operations, from triage to threat hunting. Tight integration with enforcement points lets you respond to threats quickly as well as apply the knowledge gained from investiga -tions to detect similar attacks in the future.Protect Against Known and Unknown Threats with TrapsGreat security starts with ironclad prevention. Traps™ for endpoint protection and response, included with Cortex XDR, uses multiple methods of prevention to safeguard endpoints from malware, ransomware, and exploits. T ogether, Traps and Cortex XDR deliver consistent prevention, detection, and response across all your digital assets. Native integration with cloud-based threat intelligence ensures prevention is coordinated across your network, endpoint, and cloud security products.Business Benefits• Automatically uncoverstealthy attacks: Continuously detect threats with machine learning, behavioral analytics, and custom detection rules.• Stop alert fatigue and a ttrition: Validate security alerts in seconds, improving analyst productivity and morale by reducing the backlog.• Reduce mean time to identify (MTTI): Combine precise attack detection with rapid alert triage to drastically cut dwell time.• Reduce mean time to contain (MTTC): Investigate anda ccurately respond to external attacks and insider threats, without years of experience.• Increase ROI from current investments with Cortex: Solve all your security needs through an ecosystem of trust -ed apps, while using existing infrastructure as sensors and enforcement points.Key Capabilities Gain Complete VisibilityCorrelate network, endpoint, and cloud data to streamline detection and response. Cortex XDR saves hours of manual analysis by automatically correlating data collected from your network, endpoints, and cloud assets. It stitches disparate data types together within Cortex Data Lake, a scalable and efficient cloud-based data store, to accurately detect attacks and simplify investigations.Automate Attack Detection with AIFind stealthy threats with behavioral analytics. Cortex XDR automatically pinpoints active attacks, allowing your team to triage and contain threats before the damage is done. Using machine learning, Cortex XDR continuously profiles user and devicebehavior to detect anomalous activity indicative of attacks. By examining rich data built expressly for analytics, Cortex XDR can detect attacks such as credential theft and tunneled DNS threats, which are nearly impossible to identify from standard threat logs or high-level network flow data. Automated detection works all day, every day, providing you peace of mind.Hunt Threats with Powerful Search ToolsUncover hidden malware, targeted attacks, and insider threats. Your security team can search, schedule, and save queries to identify hard-to-find threats. Flexible searching capabilities let your analysts hunt threats and search for indicators of com -promise (IoCs) without learning a new query language. By incorporating threat intelligence from Palo Alto Networks with acomplete set of network, endpoint, and cloud data, your team can catch malware, external threats, and internal attacks whether the incidents are in progress or occurred in the past.Instantly Investigate EventsAutomatically reveal the root cause of every alert. With Cortex XDR, your analysts can analyze alerts from any source with a single click, streamlining investigations. Cortex XDR automatically reveals the root cause, reputation, and sequence of events associated with each alert, lowering the experience needed for accurate validation. A forensic timeline of all attack activity pro -vides actionable detail for incident investigations, allowing analysts to determine the scope, damage, and next steps in seconds.Coordinate Response Across Enforcement PointsStop threats with fast and accurate remediation. Cortex XDR lets your security team instantly contain network, endpoint, and cloud threats from one console. Your analysts can quickly stop the spread of malware, restrict network activity to and from devices, and update threat prevention lists like bad domains through tight integration with enforcement points. With CortexXDR, you can swiftly shut down advanced attacks while gaining more value from your existing investments.Figure 1: Cortex XDR triage and investigation viewGet Industry-Leading Endpoint ProtectionUse a single agent for endpoint threat prevention and data collection. Your Cortex XDR subscription includes Traps agents, o ffering you the best endpoint protection available. T raps lets you stop known and unknown malware, exploits, and ransomware by blocking malicious behavior and techniques. Integrated, cloud-based malware analysis with Palo Alto Networks WildFire®malware prevention service improves accuracy and coverage. The T raps agent records all endpoint activity, forwards it to Cortex Data Lake for analysis, and orchestrates response.Ease Deployment with Cloud DeliveryGet started in minutes. The cloud-based Cortex XDR app offers simple, zero-touch deployment, eliminating the need to deploy new on-premises log collectors or sensors. It uses your existing Palo Alto Networks products as sensors and enforcement points, reducing the number of products you need to manage. If you’re a new customer, you only need to deploy one type of sensor, such as Next-Generation Firewalls or T raps, to detect and stop threats with Cortex XDR. Cortex XDR is built on Cortex, the industry’s only open AI-based continuous SOC platform. It delivers new levels of simplicity in security operations and significantly improved security outcomes through automation and unprecedented accuracy.Cloud Data CenterFigure 2: Analysis of data from any source for detection and responseOperational BenefitsAchieve visibility across network, endpoint, and cloud data: Collect and correlate network, endpoint, and cloud data at scale for use in detection, triage, investigation, response, and hunting.Automatically detect sophisticated attacks 24/7: Use always-on machine learning and custom rules to detect advanced persistent threats and other sophisticated attacks.Eliminate the alert backlog: Simplify investigations with automated root cause analysis and timeline views, lowering the skill required to evaluate and analyze alerts.Drastically reduce false positive alerts: Apply knowledge from every investigation to refine behavioral detection rules and speed future analysis, decreasing noise and risk.Increase SOC productivity: Streamline operational processes to a single console by consolidating alert triage, investigation, and response across your network, endpoint, and cloud environments.3000 Tannery WaySanta Clara, CA 95054 Main: +1.408.753.4000 Sales: +1.866.320.4788© 2019 Palo Alto Networks, Inc. Palo Alto Networks is a registered trademark of Palo Alto Networks. A list of our trademarks can be found at https:///company/trademarks.html. All other marks mentioned herein may be trademarks of their respective companies.Remediate without business impact: Shut down attacks with surgical precision while avoiding user or system downtime. Eliminate advanced threats: Protect your network against malicious insiders, policy violations, external threats, ransom-ware, fileless and memory-only attacks, and advanced zero-day malware.Supercharge your security team: Disrupt every stage of an attack by detecting IoCs, anomalous behavior, and maliciouspatterns of activity.Operating System SupportTraps supports multiple endpoints across Windows®, macOS®, and Linux operating systems. For a complete list of system requirements and supported operating systems, please visit the Traps Compatibility Matrix.Cortex XDR Pathfinder minimum requirements: 2 CPU cores, 8 GB RAM, 128 GB thin-provisioned storage, VMware ESXi™ V5.1 or higher, or Microsoft Hyper-V® 6.3.96 or higher hypervisor.Cortex XDR licensing includes:• Cortex XDR – Analytics app• Cortex XDR – Investigation and Response app• Traps endpoint protection and response• Cortex XDR – Pathfinder endpoint analysis service (agentless alternative to Traps)。

◎Micky 山火，是一种发生在野外难以控制的火情，它突发性强、破坏性大、扑救极为困难。

一起阅读下文了解山火吧。

山 火Wildfires Wildfires are powerful and dangerous fires. They’re a big1)threat to people and the environment. Causes of wildfiresWildfires happen for many reasons. When it’s dry and hot, plants can catch fire easily, especially with strong winds. Lightning hitting the ground or plants can also start wild fires. Except for the natural factors, people can cause wild fires too, like when they throw away cigarettes carelessly or leave 2)campfires burning.Hazards of wildfiresWildfires have caused harm to humans and the natural environment. Firstly, they destroy lots of plants and animal homes, 3)upsetting the balance of nature. Secondly, they also make lots of smoke and bad gases,Spotlight/聚光灯which make the air dirty and can make people sick. Otherwise, theycan hurt or even kill people and damage their things, causing bigproblems for communities.Mitigation measures of wildfiresWe need to take action to prevent wildfires and reduce the damage they cause. Taking better care of plants, cleaning up thingsthat can catch fire easily, and making firebreaks are important. Wealso need to teach people about wildfire risks and improve howwe watch for fires and respond to them quickly to stop them fromgetting worse.Notable wildfire incidentsAustralian bushfires: From 2019 to 2020, Australia had big bushfires that hurt lots of people and damaged lots of property.Millions of 4)hectares of land were burned, with billions of animalskilled and thousands of people forced to leave their homes.California wildfires: In 2018, California had bad wildfires, with one in Paradise being one of the deadliest in US history. Eighty-five people died, and tens of thousands lost their homes.Amazon rainforest fires in Brazil: In 2019, fires in山火，是一种强大而危险的火灾，对人类和环境造成严重的威胁。

JVM for a Heterogeneous Shared Memory SystemDeQing Chen,Chunqiang Tang,Sandhya Dwarkadas,and Michael L.ScottComputer Science Department,University of Rochester AbstractInterWeave is a middleware system that supports the shar-ing of strongly typed data structures across heterogeneouslanguages and machine architectures.Java presents spe-cial challenges for InterWeave,including write detection,data translation,and the interface with the garbage col-lector.In this paper,we discuss our implementation ofJ-InterWeave,a JVM based on the Kaffe virtual machineand on our locally developed InterWeave client software.J-InterWeave uses bytecode instrumentation to detectwrites to shared objects,and leverages Kaffe’s class ob-jects to generate type information for correct transla-tion between the local object format and the machine-independent InterWeave wire format.Experiments in-dicate that our bytecode instrumentation imposes lessthan2%performance cost in Kaffe interpretation mode,and less than10%overhead in JIT mode.Moreover,J-InterWeave’s translation between local and wire format ismore than8times as fast as the implementation of ob-ject serialization in Sun JDK1.3.1for double arrays.Toillustrate theflexibility and efficiency of J-InterWeave inpractice,we discuss its use for remote visualization andsteering of a stellar dynamics simulation system writtenin C.1IntroductionMany recent projects have sought to support distributedshared memory in Java[3,16,24,32,38,41].Manyof these projects seek to enhance Java’s usefulness forlarge-scale parallel programs,and thus to compete withmore traditional languages such as C and Fortran in thearea of scientific computing.All assume that applicationcode will be written entirely in Java.Many—particularlythose based on existing software distributed shared mem-ory(S-DSM)systems—assume that all code will run oninstances of a common JVM.has yet to displace Fortran for scientific computing sug-gests that Java will be unlikely to do so soon.Even for systems written entirely in Java,it is appealing to be able to share objects across heterogeneous JVMs. This is possible,of course,using RMI and object serial-ization,but the resulting performance is poor[6].The ability to share state across different languages and heterogeneous platforms can also help build scalable dis-tributed services in general.Previous research on var-ious RPC(remote procedure call)systems[21,29]in-dicate that caching at the client side is an efficient way to improve service scalability.However,in those sys-tems,caching is mostly implemented in an ad-hoc man-ner,lacking a generalized translation semantics and co-herence model.Our on-going research project,InterWeave[9,37],aims to facilitate state sharing among distributed programs written in multiple languages(Java among them)and run-ning on heterogeneous machine architectures.InterWeave applications share strongly-typed data structures located in InterWeave segments.Data in a segment is defined using a machine and platform-independent interface de-scription language(IDL),and can be mapped into the ap-plication’s local memory assuming proper InterWeave li-brary calls.Once mapped,the data can be accessed as ordinary local objects.In this paper,we focus on the implementation of In-terWeave support in a Java Virtual Machine.We call our system J-InterWeave.The implementation is based on an existing implementation of InterWeave for C,and on the Kaffe virtual machine,version1.0.6[27].Our decision to implement InterWeave support directly in the JVM clearly reduces the generality of our work.A more portable approach would implement InterWeave support for segment management and wire-format trans-lation in Java libraries.This portability would come,how-ever,at what we consider an unacceptable price in perfor-mance.Because InterWeave employs a clearly defined internal wire format and communication protocol,it is at least possible in principle for support to be incorporated into other JVMs.We review related work in Java distributed shared state in Section2and provide a brief overview of the Inter-Weave system in Section3.A more detailed description is available elsewhere[8,37].Section4describes the J-InterWeave implementation.Section5presents the results of performance experiments,and describes the use of J-InterWeave for remote visualization and steering.Sec-tion6summarizes our results and suggests topics for fu-ture research.2Related WorkMany recent projects have sought to provide distributed data sharing in Java,either by building customized JVMs[2,3,24,38,41];by using pure Java implementa-tions(some of them with compiler support)[10,16,32]; or by using Java RMI[7,10,15,28].However,in all of these projects,sharing is limited to Java applications. To communicate with applications on heterogeneous plat-forms,today’s Java programmers can use network sock-ets,files,or RPC-like systems such as CORBA[39].What they lack is a general solution for distributed shared state. Breg and Polychronopoulos[6]have developed an al-ternative object serialization implementation in native code,which they show to be as much as eight times faster than the standard implementation.The direct compari-son between their results and ours is difficult.Our exper-iments suggest that J-Interweave is at least equally fast in the worst case scenario,in which an entire object is mod-ified.In cases where only part of an object is modified, InterWeave’s translation cost and communication band-width scale down proportionally,and can be expected to produce a significant performance advantage.Jaguar[40]modifies the JVM’s JIT(just-in-time com-piler)to map certain bytecode sequences directly to na-tive machine codes and shows that such bytecode rewrit-ing can improve the performance of object serialization. However the benefit is limited to certain types of objects and comes with an increasing price for accessing object fields.MOSS[12]facilitates the monitoring and steering of scientific applications with a CORBA-based distributed object system.InterWeave instead allows an application and its steerer to share their common state directly,and in-tegrates that sharing with the more tightly coupled sharing available in SMP clusters.Platform and language heterogeneity can be supported on virtual machine-based systems such as Sun JVM[23] and [25].The Common Language Run-time[20](CLR)under framework promises sup-port for multi-language application development.In com-parison to CLR,InterWeave’s goal is relatively modest: we map strongly typed state across languages.CLR seeks to map all high-level language features to a common type system and intermediate language,which in turn implies more semantic compromises for specific languages than are required with InterWeave.The transfer of abstract data structures wasfirst pro-posed by Herlihy and Liskov[17].Shasta[31]rewrites bi-nary code with instrumentation for access checks forfine-grained S-DSM.Midway[4]relies on compiler support to instrument writes to shared data items,much as we do in the J-InterWeave JVM.Various software shared memory systems[4,19,30]have been designed to explicitly asso-ciate synchronization operations with the shared data they protect in order to reduce coherence costs.Mermaid[42] and Agora[5]support data sharing across heterogeneous platforms,but only for restricted data types.3InterWeave OverviewIn this section,we provide a brief introduction to the design and implementation of InterWeave.A more de-tailed description can be found in an earlier paper[8]. For programs written in C,InterWeave is currently avail-able on a variety of Unix platforms and on Windows NT. J-InterWeave is a compatible implementation of the In-terWeave programming model,built on the Kaffe JVM. J-InterWeave allows a Java program to share data across heterogeneous architectures,and with programs in C and Fortran.The InterWeave programming model assumes a dis-tributed collection of servers and clients.Servers maintain persistent copies of InterWeave segments,and coordinate sharing of those segments by clients.To avail themselves of this support,clients must be linked with a special In-terWeave library,which serves to map a cached copy of needed segments into local memory.The servers are the same regardless of the programming language used by clients,but the client libraries may be different for differ-ent programming languages.In this paper we will focus on the client side.In the subsections below we describe the application programming interface for InterWeave programs written in Java.3.1Data Allocation and AddressingThe unit of sharing in InterWeave is a self-descriptive data segment within which programs allocate strongly typed blocks of memory.A block is a contiguous section of memory allocated in a segment.Every segment is specified by an Internet URL and managed by an InterWeave server running at the host indi-cated in the URL.Different segments may be managed by different servers.The blocks within a segment are num-bered and optionally named.By concatenating the seg-ment URL with a block number/name and offset(delim-ited by pound signs),we obtain a machine-independent pointer(MIP):“/path#block#offset”. To create and initialize a segment in Java,one can ex-ecute the following calls,each of which is elaborated on below or in the following subsections:IWSegment seg=new IWSegment(url);seg.wl_acquire();MyType myobj=new MyType(seg,blkname);myobj.field=......seg.wl_release();In Java,an InterWeave segment is captured as an IWSegment object.Assuming appropriate access rights, the new operation of the IWSegment object communi-cates with the appropriate server to initialize an empty segment.Blocks are allocated and modified after acquir-ing a write lock on the segment,described in more detail in Section3.3.The IWSegment object returned can be passed to the constructor of a particular block class to al-locate a block of that particular type in the segment. Once a segment is initialized,a process can convert be-tween the MIP of a particular data item in the segment and its local pointer by using mip ptr and ptr mip where appropriate.It should be emphasized that mip ptr is primar-ily a bootstrapping mechanism.Once a process has one pointer into a data structure(e.g.the root pointer in a lat-tice structure),any data reachable from that pointer can be directly accessed in the same way as local data,even if embedded pointers refer to data in other segments.In-terWeave’s pointer-swizzling and data-conversion mech-anisms ensure that such pointers will be valid local ma-chine addresses or references.It remains the program-mer’s responsibility to ensure that segments are accessed only under the protection of reader-writer locks.3.2HeterogeneityTo accommodate a variety of machine architectures,In-terWeave requires the programmer to use a language-and machine-independent notation(specifically,Sun’s XDR[36])to describe the data types inside an InterWeave segment.The InterWeave XDR compiler then translates this notation into type declarations and descriptors appro-priate to a particular programming language.When pro-gramming in C,the InterWeave XDR compiler generates twofiles:a.hfile containing type declarations and a.c file containing type descriptors.For Java,we generate a set of Java class declarationfiles.The type declarations generated by the XDR compiler are used by the programmer when writing the application. The type descriptors allow the InterWeave library to un-derstand the structure of types and to translate correctly between local and wire-format representations.The lo-cal representation is whatever the compiler normally em-ploys.In C,it takes the form of a pre-initialized data struc-ture;in Java,it is a class object.3.2.1Type Descriptors for JavaA special challenge in implementing Java for InterWeave is that the InterWeave XDR compiler needs to gener-ate correct type descriptors and ensure a one-to-one cor-respondence between the generated Java classes and C structures.In many cases mappings are straight forward: an XDR struct is mapped to a class in Java and a struct in C,primitivefields to primitivefields both in Java andC,pointersfields to object references in Java and pointers in C,and primitive arrays to primitive arrays. However,certain“semantics gaps”between Java and C force us to make some compromises.For example,a C pointer can point to any place inside a data block;while Java prohibits such liberties for any object reference. Thus,in our current design,we make the following compromises:An InterWeave block of a single primitive data item is translated into the corresponding wrapped class for the primitive type in Java(such as Integer,Float, etc.).Embedded structfields in an XDR struct definition areflattened out in Java and mapped asfields in its parent class.In C,they are translated naturally into embeddedfields.Array types are mapped into a wrapped IWObject(including the IWacquire,wl acquire, and rlpublic class IWSegment{public IWSegment(String URL,Boolean iscreate);public native staticint RegisterClass(Class type);public native staticObject mip_to_ptr(String mip);public native staticString ptr_to_mip(IWObject Ob-ject obj);......public native int wl_acquire();public native int wl_release();public native int rl_acquire();public native int rl_release();......}Figure2:IWSegment Class4.1.1JNI Library for IWSegment ClassThe native library for the IWSegment class serves as an intermediary between Kaffe and the C InterWeave library. Programmer-visible objects that reside within the IWSeg-ment library are managed in such a way that they look like ordinary Java objects.As in any JNI implementation,each native method has a corresponding C function that implements its function-ality.Most of these C functions simply translate their pa-rameters into C format and call corresponding functions in the C InterWeave API.However,the creation of an In-terWeave object and the method RegisterClass need special explanation.Mapping Blocks to Java Objects Like ordinary Java objects,InterWeave objects in Java are created by“new”operators.In Kaffe,the“new”operator is implemented directly by the bytecode execution engine.We modi-fied this implementation to call an internal function new-Block in the JNI library and newBlock calls the Inter-Weave C library to allocate an InterWeave block from the segment heap instead of the Kaffe object heap.Before returning the allocated block back to the“new”operator, newBlock initializes the block to be manipulated cor-rectly by Kaffe.In Kaffe,each Java object allocated from the Kaffe heap has an object header.This header contains a pointer to the object class and a pointer to its own monitor.Since C InterWeave already assumes that every block has a header (it makes no assumption about the contiguity of separate blocks),we put the Kaffe header at the beginning of what C InterWeave considers the body of the block.A correctly initialized J-InterWeave object is shown in Figure3.Figure3:Block structure in J-InterWeaveAfter returning from newBlock,the Kaffe engine calls the class constructor and executes any user cus-tomized operations.Java Class to C Type Descriptor Before any use of a class in a J-InterWeave segment,including the creation of an InterWeave object of the type,the class object must befirst registered with RegisterClass.Register-Class uses the reflection mechanism provided by the Java runtime system to determine the following informa-tion needed to generate the C type descriptor and passes it to the registration function in the C library.1.type of the block,whether it is a structure,array orpointer.2.total size of the block.3.for structures,the number offields,eachfield’s off-set in the structure,and a pointer to eachfield’s type descriptor.4.for arrays,the number of elements and a pointer tothe element’s type descriptor.5.for pointers,a type descriptor for the pointed-to data.The registered class objects and their corresponding C type descriptors are placed in a hashtable.The new-Block later uses this hashtable to convert a class object into the C type descriptor.The type descriptor is required by the C library to allocate an InterWeave block so that it has the information to translate back and forth between local and wire format(see Section3).4.2KaffeJ-InterWeave requires modifications to the byte code in-terpreter and the JIT compiler to implementfine-grained write detection via instrumentation.It also requires changes to the garbage collector to ensure that InterWeave blocks are not accidentally collected.Figure4:Extended Kaffe object header forfine-grained write detection4.2.1Write DetectionTo support diff-based transmission of InterWeave segment updates,we must identify changes made to InterWeave objects over a given span of time.The current C ver-sion of InterWeave,like most S-DSM systems,uses vir-tual memory traps to identify modified pages,for which it creates pristine copies(twins)that can be compared with the working copy later in order to create a diff.J-InterWeave could use this same technique,but only on machines that implement virtual memory.To enable our code to run on handheld and embedded devices,we pursue an alternative approach,in which we instrument the interpretation of store bytecodes in the JVM and JIT. In our implementation,only writes to InterWeave block objects need be monitored.In each Kaffe header,there is a pointer to the object method dispatch table.On most architectures,pointers are aligned on a word boundary so that the least significant bit is always zero.Thus,we use this bit as theflag for InterWeave objects.We also place two32-bit words just before the Kaffe object header,as shown in Figure4.The second word—modification status—records which parts of the object have been modified.A block’s body is logically divided into32parts,each of which corresponds to one bit in the modification status word.Thefirst extended word is pre-computed when initializing an object.It is the shift value used by the instrumented store bytecode code to quickly determine which bit in the modification status word to set(in other words,the granularity of the write detection).These two words are only needed for In-terWeave blocks,and cause no extra overhead for normal Kaffe objects.4.2.2Garbage CollectionLike distributedfile systems and databases(and unlike systems such as PerDiS[13])InterWeave requires man-ual deletion of data;there is no garbage collection.More-over the semantics of InterWeave segments ensure that an object reference(pointer)in an InterWeave object(block) can never point to a non-InterWeave object.As a result, InterWeave objects should never prevent the collection of unreachable Java objects.To prevent Kaffe from acci-dentally collecting InterWeave memory,we modify the garbage collector to traverse only the Kaffe heap.4.3InterWeave C libraryThe InterWeave C library needs little in the way of changes to be used by J-InterWeave.When an existing segment is mapped into local memory and its blocks are translated from wire format to local format,the library must call functions in the IWSegment native library to initialize the Kaffe object header for each block.When generating a description of modified data in the write lock release operation,the library must inspect the modifi-cation bits in Kaffe headers,rather than creating diffs from the pristine and working copies of the segment’s pages.4.4DiscussionAs Java is supposed to be“Write Once,Run Anywhere”, our design choice of implementing InterWeave support at the virtual machine level can pose the concern of the portability of Java InterWeave applications.Our current implementation requires direct JVM support for the fol-lowing requirements:1.Mapping from InterWeave type descriptors to Javaobject classes.2.Managing local segments and the translation be-tween InterWeave wire format and local Java objects.3.Supporting efficient write detection for objects in In-terWeave segments.We can use class reflection mechanisms along with pure Java libraries for InterWeave memory management and wire-format translation to meet thefirst two require-ments and implement J-InterWeave totally in pure Java. Write detection could be solved using bytecode rewrit-ing techniques as reported in BIT[22],but the resulting system would most likely incur significantly higher over-heads than our current implementation.We didn’t do this mainly because we wanted to leverage the existing C ver-sion of the code and pursue better performance.In J-InterWeave,accesses to mapped InterWeave blocks(objects)by different Java threads on a single VM need to be correctly synchronized via Java object monitors and appropriate InterWeave locks.Since J-InterWeave is not an S-DSM system for Java virtual machines,the Java memory model(JMM)[26]poses no particular problems. 5Performance EvaluationIn this section,we present performance results for the J-InterWeave implementation.All experiments employ a J-InterWeave client running on a1.7GHz Pentium-4Linux machine with768MB of RAM.In experiments involving20406080100120_201_co mp r e s s _202_j e s s _205_ra y t r a c e _209_db _213_j a va c _222_m p e g a u d i o _227_m t r t _228_j a c kJVM98 BenchmarksT i m e (s e c .)Figure 5:Overhead of write-detect instrumentation in Kaffe’s interpreter mode01234567_201_c o mp r e s s _202_j e s s _205_r a y t r a c e _209_d b _213_j a v a c _222_m p e g a u d i o _227_m t r t _228_j a c k JVM98 Benchmarks T i m e (s e c .)Figure 6:Overhead of write-detect instrumentation inKaffe’s JIT3modedata sharing,the InterWeave segment server is running on a 400MHz Sun Ultra-5workstation.5.1Cost of write detectionWe have used SPEC JVM98[33]to quantify the perfor-mance overhead of write detection via bytecode instru-mentation.Specifically,we compare the performance of benchmarks from JVM98(medium configuration)run-ning on top of the unmodified Kaffe system to the per-formance obtained when all objects are treated as if they resided in an InterWeave segment.The results appear in Figures 5and 6.Overall,the performance loss is small.In Kaffe’s inter-preter mode there is less than 2%performance degrada-tion;in JIT3mode,the performance loss is about 9.1%.The difference can be explained by the fact that in inter-preter mode,the per-bytecode execution time is already quite high,so extra checking time has much less impact than it does in JIT3mode.The Kaffe JIT3compiler does not incorporate more re-cent and sophisticated technologies to optimize the gener-ated code,such as those employed in IBM Jalepeno [35]and Jackal [38]to eliminate redundant object referenceand array boundary checks.By applying similar tech-niques in J-InterWeave to eliminate redundant instrumen-tation,we believe that the overhead could be further re-duced.5.2Translation costAs described in Sections 3,a J-InterWeave application must acquire a lock on a segment before reading or writ-ing it.The acquire operation will,if necessary,ob-tain a new version of the segment from the InterWeaveserver,and translate it from wire format into local Kaffeobject format.Similarly,after modifying an InterWeavesegment,a J-InterWeave application must invoke a write lock release operation,which translates modified por-tions of objects into wire format and sends the changes back to the server.From a high level point of view this translation re-sembles object serialization ,widely used to create per-sistent copies of objects,and to exchange objects between Java applications on heterogeneous machines.In this sub-section,we compare the performance of J-InterWeave’stranslation mechanism to that of object serialization in Sun’s JDK v.1.3.1.We compare against the Sun im-plementation because it is significantly faster than Kaffe v.1.0.6,and because Kaffe was unable to successfully se-rialize large arrays in our experiments.We first compare the cost of translating a large array of primitive double variables in both systems.Under Sun JDK we create a Java program to serialize double arrays into byte arrays and to de-serialize the byte arrays backagain.We measure the time for the serialization and de-serialization.Under J-InterWeave we create a programthat allocates double arrays of the same size,releases (un-maps)the segment,and exits.We measure the releasetime and subtract the time spent on communication with the server.We then run a program that acquires (maps)the segment,and measure the time to translate the byte arrays back into doubles in Kaffe.Results are shown in Figure 7,for arrays ranging in size from 25000to 250000elements.Overall,J-InterWeave is about twenty-three times faster than JDK 1.3.1in serialization,and 8times faster in dese-rialization.5.3Bandwidth reduction To evaluate the impact of InterWeave’s diff-based wire format,which transmits an encoding of only those bytes that have changed since the previous communication,we modify the previous experiment to modify between 10and 100%of a 200,000element double array.Results appear in Figures 8and 9.The former indicates translation time,the latter bytes transmitted.20406080100120140250005000075000100000125000150000175000200000225000250000Size of double array (in elements)T i m e (m s e c .)Figure 7:Comparison of double array translation betweenSun JDK 1.3.1and J-InterWeave102030405060708090100100908070605040302010Percentage of changesT i m e (m s e c .)Figure 8:Time needed to translate a partly modified dou-ble arrayIt is clear from the graph that as we reduce the per-centage of the array that is modified,both the translationtime and the required communication bandwidth go down by linear amounts.By comparison,object serialization is oblivious to the fraction of the data that has changed.5.4J-InterWeave Applications In this section,we describe the Astroflow application,developed by colleagues in the department of Physics andAstronomy,and modified by our group to take advan-tage of InterWeave’s ability to share data across hetero-geneous platforms.Other applications completed or cur-rently in development include interactive and incremental data mining,a distributed calendar system,and a multi-player game.Due to space limitations,we do not present these here.The Astroflow [11][14]application is a visualization tool for a hydrodynamics simulation actively used in the astrophysics domain.It is written in Java,but employs data from a series of binary files that are generated sepa-rately by a computational fluid dynamics simulation sys-00.20.40.60.811.21.41.61.8100908070605040302010Percentage of changesT r a n s mi s s i o n s i z e (M B )Figure 9:Bandwidth needed to transmit a partly modified double array2040608010012014012416Number of CPUsT i m e (s e c .)Figure 10:Simulator performance using InterWeave in-stead of file I/Otem.The simulator,in our case,is written in C,and runs on a cluster of 4AlphaServer 41005/600nodes under the Cashmere [34]S-DSM system.(Cashmere is a two-level system,exploiting hardware shared memory within SMP nodes and software shared memory among nodes.InterWeave provides a third level of sharing,based on dis-tributed versioned segments.We elaborate on this three-level structure in previous papers [8].)J-InterWeave makes it easy to connect the Astroflow vi-sualization front end directly to the simulator,to create an interactive system for visualization and steering.The ar-chitecture of the system is illustrated in Figure 1(page 1).Astroflow and the simulator share a segment with one header block specifying general configuration parameters and six arrays of doubles.The changes required to the two existing programs are small and limited.We wrote an XDR specification to describe the data structures we are sharing and replaced the original file operations with shared segment operations.No special care is re-quired to support multiple visualization clients or to con-trol the frequency of updates.While the simulation data。

BurnetWilliamsonTravis BlancoHaysCaldwell BastropTexasAnalysis TrilogyTemporal indicators Spatial indicators Human indicators Potential for IgnitionPotential forCombustibility/Propagation Potential Rami cation1. Current & HistoricalClimate Data2. Current & Historical FireOccurrences Data3. Current & HistoricalEmergency Calls DataPrecipitation/drought eventsLightning strikesWind speed & direction1. Exhisting Fuel &Topographic DataFuel typesSlope, Elevations, Aspect2. Fire SuppressionCapabilityInitial dispatch locationsSpatial morphologyEmergency response timeFire containmentDry hydrantsPopulation centersUrban interfaceCritical infrastructureEvacuation potential1. Exhisting Data onStructure/InfrastructureTools for wildfire prediction and mitigation By Ahmed Abukhater, Esri Global Industry Manager for Community DevelopmentWildfires are one of the most notoriously de-structive and devastating natural hazards inthe United States.Planners and policy makers need toolsthat enable them to assign land uses andidentify community assets to avoid wildfirehazards in the communities most suscepti-ble to natural and man-made disasters. GIScan provide these effective planning toolsand insights to prepare for natural and man-made disasters and mitigate their impact.Both policy makers and the community atlarge can plan for pre- and postdisaster re-sponse and mitigation efforts.Numerous wildfire methodologies pri-marily focus on predicting where fire is mostlikely to occur based on historic data andspatial characteristics of the environment.What’s missing is knowledge of the impact ofwildfire on vulnerable populations and criti-cal infrastructure. To that end, predictingfire hazards by modeling areas that are most vulnerable to fire and measuring the impact on the community’s assets and human and physical resources is both important and warranted to mitigate wildfire hazards and associated costs and fatalities.Improving emergency response in areasmost susceptible to frequent fires—basedon data interpolation and prior delineationof these areas—can help save lives and pre-cious resources. Given the importance offorest-urban interface fire prediction andmitigation, this article describes how toconduct a community risk assessment froma planning point of view and proposes a GIS-based multiple-criteria evaluation (MCE)framework for analyzing, predicting, and ul-timately mitigating the impact of wildfires.Assessing Wildfire ImpactThis article references a study for develop-ing a systematic methodology for assess-ment of wildfire impact on a community’scritical assets, including human capital andinfrastructure assets. In particular, thisstudy conducted spatial modeling and rep-resentation of wildfire hazard analysis andspatiotemporal interpolation of communi-ties at risk; developed a standardized plan-ning support system (PSS) for methodologyof GIS-based regional molding of WildfireSusceptibility Index (WFSI) for planningand policy making; identified areas at riskand vulnerable communities; and providedbetter assessment tools and capabilities forfuture land-use planning and policy making.The study area was Travis County, Texas.With nearly a million residents, the countyencompasses the cities of Austin, Jonestown,and Round Rock. It includes major popula-tion, business, and educational hubs such asthe University of Texas at Austin.GIS-Based Community Risk AssessmentThe study area was Travis County, Texas.The analysis trilogy: factors used for the analysisFeaturesGeospatial Methods and AnalysesThis analysis is composed of three key indi-cators: temporal, spatial, and human. These represent the potential for ignition, fire com-bustibility, and propagation (or how fast the fire spreads) and possible ramifications for the community. The analysis captures not only the risk and probability of wildfires but also the magnitude of impact on the community.The potential for ignition is measured by the temporal indicators including current and historical climate data about precipita-tion, drought events, lightning strikes, wind speed and direction, current and historical fire occurrence data, and current and his-torical emergency calls data.The potential for fire combustibility and propagation is measured by a set of spatial indicators including existing fuel and topo-graphic data (such as fuel types, slope, eleva-tion, and aspect) and fire suppression capa-bility (such as initial dispatch locations and spatial morphology data about emergency response time, fire containment, and dry hydrants).The potential ramifications for the com-munity are measured by existing data on population centers, urban interface, critical infrastructure, and evacuation potential. A community survey was conducted, and several meetings with the local community were held to collaboratively determine the importance of each of these indicators in the analysis. The relative importance for these factors was represented by the weights as-signed to them.This analysis trilogy translates into aA conceptual model for the Wildfire Susceptibility Index (WFSI) methodologyFirenado potential ElevationSlopeAspect(wind direction)FuelDEMDEMDEMVegetativecoverageFirepropagationFireirruptionFirepropagationFireirruptionVery low (1): 93-170mLow (2): 170-230mModerate (3): 230-290mHigh (4): 290-350mVery high (5): 350-483mVery low (1): 0-5%Low (2): 5-15%Modera te (3): 15-30%High (4): 30-45%Very hig h (5): 45-133%Very low (1): N, atLow (2): NE, NWModerate (3): E, WHigh (4): SE, SWVery high (5): S- Very low- Fire containment: creating naturaland arti cial re breaks (such asrivers and highways)- Dumping water from the skyVery low (1):FBPS 97, 98, 99Low (2): FBPS 96Moderate (3): FBPS 10, 11, 12High (4): FBPS 6, 7, 8, and 9Very high (5): FBPS 1, 2, 3, 4, 5Improving structural re safety:- Using re resistant materials- Exits clearly marked- Entrances ate not blocked byany ammable materials- Access for a large re truck- Reducing vegetationencroachment around buildingsVery low (1): < 5 minLow (2): 5-8 minModerate (3): 8-10 minHigh (4): 10-15 minVery high (5): > 15 minEarly warning system:- Local of cials issue burn bans- Issuance of red ag warnings- Reverse 911 calls for residents(alerting to evacuate)FireirruptionRoad accessand initialdispatchlocationsResponse timeFire spread& damageExamples of contributing factors GIS layers used for the analysis conceptual diagram that includes risk analy- sis, hazard analysis, and potential ramifica-tions to create a fire propensity index, fire behavior/spatial diffusion index, and sensi-tive areas contingency valuation index. Each of these three pillars is inclusive of several factors and layers.Wildfire can cause a blazing inferno with a potential of speed ranging from 30 to 40 miles per hour, which causes the fire to spread rapidly, creating “firenado” potential. Weather conditions, surface fuel, and topography, among other factors, can contribute to this situation.For Travis County, Texas, weather condi-tions were characterized as a severe drought pattern. The area has experienced drought for the past 10 years. The area has low pre-cipitation and currently receives only 50 to 60 percent of its normal precipitation.With regard to surface fuel, Travis County has high forest density and canopy cover with crown fire potential. West Austin is densely covered with trees and brush, highly flammable because of the severe drought conditions.West Austin also has steeply sloping hills and canyons, and high wind speed and elevation are also factors. O ther fac-tors to consider include high fire ignition risk related to transportation and historic wildfire occurrences and the area’s high population density. The area’s poor egressFeatures is related to the transportation networkand urban morphology. The area also haslow fire suppression capacity owing to thelocations and levels of coverage provided bynearby fire departments.Each factor was represented by a separatelayer that was created, extracted, or derivedfrom other data sources or a combination ofsources. The table on page 26 shows a fewexamples of these contributing factors asso-ciated with a risk statement, derivative data,contributing factors, trigger event, valuationmethodology (how these factors are catego-rized in the analysis), and response strategy.Analysis ResultsGIS was used to create and extract datalayers to represent each factor listed in theconceptual diagram and conduct spatialanalysis to derive density, propensity, andproximity maps. These maps were consoli-dated and combined into the six categorymaps, which were juxtaposed and overlaid(after assigning weights reflecting the com-munity’s priorities) to produce the final maprepresenting the WFSI.The final map shows areas threatened by extreme and very high potential for wildfire breakouts in red and orange. Areas in north Travis County and west Austin are identi-fied as high-risk areas because of the cur-rent drought conditions, dense forest and canopy cover, flammable vegetation, and steep slopes. In addition, these area have concentrations of population and critical infrastructure combined with relative lack of resources and fire suppression capacity. Representing this information in a three-dimensional diagram helps furnish a better understanding of the level of risk and magni-tude of impact on communities affected by potential wildfire.ConclusionThis article describes a methodology for con-ducting community risk assessment for wild-fire hazard on a regional scale and provides evidence of the value of using GIS in data management and organization and plan-ning analysis. It is imperative for emergency respondents on one hand and planners and policy makers on the other to take advantage of this type of analysis. GIS helps model areas that are most vulnerable to wildfire. GIS analysis results, the Wildfire Susceptibility IndexKnowing where fire incidence is mostlikely will help emergency services respondin a timely manner to mitigate the impactof fire. Knowing which populations are atrisk, communities can determine whereto allocate resources most effectively tosave money and human lives. Planners canalso use this analysis to inform future landuse policies and guide decisions regardingfuture growth areas. The results can also bedisseminated to inform future land-use suit-ability analysis and conflict maps to avoidfuture expansion in those areas identified ashigh-risk areas for wildfire hazard. This spa-tial knowledge is critical for land-use policyand decision making.GIS is an invaluable tool for conductingthis analysis to produce actionable knowl-edge and intelligence. By integrating data,geoprocessing tools, ModelBuilder, andvisualization tools, the impact of humanactivities on the natural and built environ-ment can be evaluated. State-of-the-art GISvisualization and analytic tools help officialsunderstand and analyze the spatial andtemporal characteristics of wildfire.For More InformationAhmed Abukhater, PhD, GISPEsri Global Industry Manager forCommunity Development*******************About the AuthorDr. Ahmed Abukhater leads Esri’s globalmarketing strategies in planning and eco-nomic development. In his role as Esri’scommunity development industry manager,he works to advance the industry agendathrough his vision of enterprise GIS, smartgrowth, business attraction, and economicgardening and revitalization. Abukhaterholds a doctorate in community and re-gional planning from the University of Texasat Austin; a master’s degree in urban andregional planning from the University ofIllinois at Urbana, Champaign; and a bach-elor’s degree in architectural engineering.He has authored numerous publications,served on many governing and advisoryboards, and received more than 20 prestig-ious awards for his work.Process and Decision Workflow (GIS Model Workflow Chart)。

Pro|Engineer Wildfire 3.0 入门到精通教程事前准备，此教程配合Pro/ENGINEER Wildfire 3.0 使用。

继续前，请确保您已安装了Pro/ENGINEER Wildfire 3.0。

如果Pro/ENGINEER 在运行中，请立即退出。

您需要创建特殊的Pro/ENGINEER 启动命令，并为该教程安装Pro/ENGINEER 模型文件。

下载模型文件。

将压缩文件保存到桌面。

如果运行的是Pro/ENGINEER Wildfire 3.0 的商业许可，请单击此处。

如果运行的是Pro/ENGINEER Wildfire 3.0 的教育（试用）许可，请单击此处。

将该压缩文件解压缩到硬盘。

建议使用普通的驱动器盘符（例如，C:\），本教程使用此驱动器盘符。

浏览到此压缩文件创建的文件夹。

例如：C:\users\student\Intro_WF3_Tutorial。

假设您已安装了Pro/ENGINEER Wildfire 3.0，从“开始”菜单定位快捷键。

右键单击快捷键并选取“复制”(Copy)。

右键单击您的桌面并选取“粘贴快捷方式”(Paste Shortcut)。

右键单击刚刚粘贴的快捷键并选取“属性”(Properties)。

输入（或粘贴）指向Intro_WF3_Tutorial的完整路径。

例如：C:\users\student\Intro_WF3_Tutorial。

使用刚刚配置的快捷键启动Pro/ENGINEER Wildfire 3.0。

单击下一页继续，使用教程单击每页顶部或底部的上一页或下一页可浏览教程。

请仔细阅读每一页的全部内容，并在进行下一步前执行给定的步骤。

在某些情况下，在继续之前您可能需要在教程页面上…向下滚动‟。

您可通过每个页面上的主页图标返回到起始页面。

您可使用主页中所提供的链接来跳至某一个练习。

在此教程中您会看到多种图标。

信息在多数练习开始的时候提供。

提示将始终可用。

NAMEsmp_phy_control − invoke PHY CONTROL SMP functionSYNOPSISsmp_phy_control[−−attached=ADN][−−expected=EX][−−help][−−hex][−−interface=PARAMS] [−−max=MA][−−min=MI][−−op=OP][−−phy=ID][−−pptv=TI][−−raw][−−sa=SAS_ADDR] [−−verbose][−−version]SMP_DEVICE[,N]DESCRIPTIONSends a SAS Management Protocol (SMP) PHY CONTROL request function to a SMP target. The SMP target is identified by the SMP_DEVICE and the SAS_ADDR.Depending on the interface, the SAS_ADDR may be deduced from the SMP_DEVICE.With one interface there is one SMP_DEVICE per machine so the SMP_DEVICE,N syntax is needed to differentiate between HBAs if there are multiple present.The PHY CONTROL function is used to change the state of a phy within a SMP target. SMP targets are typically SAS expanders which have multiple phys. Certain operation values (e.g. ’lr’ (link reset) and ’hr’(hard reset)) change the state of the attached phy. Sending such operation values to the phy in the SMP tar-get that is attached to the originator (i.e. the SMP initiator) may lead to a bad response.Invoking this utility with no arguments (other than SMP_DEVICE which might be in an environment vari-able and−−sa=SAS_ADDR which might be in an environment variable or not needed) is harmless. In other words a phy’s state is only changed when either−−max=MA,−−min=MI,−−op=OP or−−pptv=TI is given with a non default value.OPTIONSMandatory arguments to long options are mandatory for short options as well.−a,−−attached=ADNspecifies the attached device name (ADN). The default value is 0 .The ADN is in decimal but islikely to be a SAS address which is typically shown in hexadecimal. To specify a number in hex-adecimal either prefix it with ’0x’ or put a trailing ’h’ on it.−E,−−expected=EXset the ’expected expander change count’ field in the SMP request.The value EX is from 0 to65535 inclusive with 0 being the default value. When EX is greater than zero then if the valuedoesn’t match the expander change count of the SMP target (i.e. the expander) when the requestarrives then the target ignores the request and sets a function result of "invalid expander changecount" in the response.−h,−−helpoutput the usage message then exit.−H,−−hexoutput the response in hexadecimal.−I,−−interface=PARAMSinterface specific parameters. In this case "interface" refers to the path through the operating sys-tem to the SMP initiator.See the smp_utils man page for more information.−M,−−max=MApermits the programmed maximum physical link rate to be changed on the gven phy. Permittedvalues are: 0 −> no change, 8 −> 1.5 Gbps, 9 −> 3 Gbps, 10 −> 6 Gbps. Default value is 0.−m,−−min=MIpermits the programmed minimum physical link rate to be changed on the given phy.Permittedvalues are: 0 −> no change, 8 −> 1.5 Gbps, 9 −> 3 Gbps, 10 −> 6 Gbps. Default value is 0.−o,−−op=OPspecifies the operation to be performed on the given phy.The OP argument can be either numericor a string. If a number is given, it is put into the ’phy operation’ field of the request. Allowablestrings are abbreviations of which only the first two characters need to match. The supportedstrings are: ’nop’ (no operation), ’lr’ (link reset), ’hr’ (hard reset), ’dis’ (disable phy), ’cel’ (clearerror log), ’ca’ (clear affiliation), ’tspss’ (transmit SATA port selection signal), ’citnl’ (clear STPI_T nexus loss (bit)), and ’sadn’ (set attached device name).The default value is 0 (no operation).−p,−−phy=IDphy identifier.ID is a value between 0 and 127. Default is 0.−P,−−pptv=TIpartial pathway timeout value. The units are microseconds and the permitted values are between 0and 15 inclusive.7microseconds is recommended by sas2r07.−r,−−rawsend the response to stdout in binary.All error messages are sent to stderr.−s,−−sa=SAS_ADDRspecifies the SAS address of the SMP target device. Typically this is an expander.This option maynot be needed if the SMP_DEVICE has the target’s SAS address within it. The SAS_ADDR is indecimal but most SAS addresses are shown in hexadecimal. To giv e a number in hexadecimaleither prefix it with ’0x’ or put a trailing ’h’ on it.−v,−−verboseincrease the verbosity of the output. Can be used multiple times−V,−−versionprint the version string and then exit.CONFORMING TOThe SMP PHY CONTROL function was introduced in SAS-1 .AUTHORSWritten by Douglas Gilbert.REPORTING BUGSReport bugs to <dgilbert at interlog dot com>.COPYRIGHTCopyright © 2006−2008 Douglas GilbertThis software is distributed under a FreeBSD license. There is NO warranty; not even for MER-CHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.SEE ALSOsmp_utils, smp_discover(smp_utils)。

The inputs have the following priorities: 1. XLR 2. sACN 3. Art-NetAs long as XLR is received, sACN and Art-Net are deactivated.While sACN or Art-Net are received, DMX is also output on the XLR connector.Die Eingänge haben die nachstehende Rangfolge: 1. XLR 2. sACN 3. Art-NetSolange XLR anliegt, sind sACN und Art-Net deaktiviert.Während sACN oder Art-Net anliegen, wird auch DMX über den XLR-Anschluss ausgegeben.Gli ingressi hanno la seguente priorità: 1. XLR 2. sACN 3. Art-NetFintanto che vengono ricevuti dati XLR, sACN e Art-Net sono disattivati.Mentre vengono ricevuti dati sACN o Art-Net, vengono trasmessi anche dati DMX sul connettore XLR.SAFETY INFORMATIONBefore you operate this unit read the manual carefully. Always make sure to include the manual if you pass/ rent/ sell the unit to another user. Please use your own caution when operating.This product is for professional use only. It is not for household use.• Do not operate the unit in areas of high temperature conditions or under direct sunlight. It can cause abnormal function or damage the product.• Always use a suitable safety wire when mounting the unit overhead.• Connect the safety wire only to the intended safety mount.• Always follow local safety requirements.• Do not place in fire or heat.• Do not use the unit if it is damaged.• Avoid bumping or plunging, it may cause fire or explosion.• It is recommended to charge at a temperature between 15°C and 35°C.Warning: In extreme cases, abuse or misuse of standard/ rechargeable batteries can lead to:• Explosion• Fire development• Heat generation or smoke and gas development.• Do not open the product housing.• Do not apply power if the unit is damaged.• Do not submerge the unit into any liquid.•Caution, risk of electric shock.The DataLink shall be installed near a socket-outlet which must be easily accessible.Warning: risk of electric shock - Do not open device.• The exterior surfaces of the unit can become hot, up to 70°C (158°F) during normal operation.• Ensure that accidental physical contact with the device is im-possible.• lnstall only in ventilated locations.• Do not cover the device.• Allow all units to cool before touching.INTRODUCTION / INTENDED USEThe DataLink is required to send wired DMX, Art-Net and sACN data to Hyperion Tubes. In addition it is also useful for Titan Tubes and Helios Tubes if no Titan PowerBox is available or to add an additional DMX universe to the Titan PowerBox. It does not have a built-in power supply but requires one Titan or Hyperion PSU (sold seperatly) per tube, so up to 4 tubes can be connected with 4 power supplies. From the 4 DC OUT sockets power and data can both run over special cables so only one ca-ble is needed to connect a Hyperion/ Titan/ Helios Tube to the DataLink. The DataLink can be used standing or hanging. For this purpose, the de-vice is equipped with 4 M5 threads and 2 1/4” - 16 UNC threads to easily attach appropriate mounting accessories.The DataLink can be used indoors and has an IP20 rating.Do not shake the device. Avoid brute force when installing or operating the device.When choosing the installation spot, please make sure that the device is not exposed to extreme heat or dust. Avoid direct sunlight for a longer period of time.Never use the device during thunderstorms connected to the power mains. Overvoltage could destroy the device. Always disconnect the device during thunderstorms.Make sure that the area below the installation place is blocked when rigging, derigging or servicing the fixture.Always fix the fixture with an appropriate safety wire.Operate the device only after having become familiarized with its functions.Please consider that unauthorized modifications on the device are not allowed due to safety reasons! If this device is operated in any way different from what is described in this manual, the device may suffer damages and the warranty may be void.The disclaimer includes all damages, liability or injury resulting from failure to follow the instructions in this manual.Furthermore, any other operation may lead to dangers like short circuit, burns, electric shock, crash etc. This device is not for household use and is not suitable for permanent installation.CONTENT / LIEFERUMFANG / ENTITÀ DELLA FORNITURA1.: DataLink (FP3-DTL)2.: User manual/ Benutzerhandbuch / Manuale utenteCLEANING AND MAINTAININGCaution: Liquids entering the housing of the device can cause a short circuit and damage the electronics. Do not use anycleaning agents or solvents. Only clean using a soft damp cloth.MANUFACTURER DECLARATIONHereby, Astera LED T echnology GmbH declares that the type of Control Interface FP3-DTL DataLink complies with Directive 2014/35 / EU. The full text of the EU Declaration of Conformity is available at the following Internet address: https:///hyperion/Astera LED T echnology GmbH declares that this equipment has been tested and found to comply with the limits for a Class B digital device, pursuant to part 15 of the FCC rules. These limits are designed to provide reasonable protection against harmful interference in a residential installation. This equip-ment may cause harmful interference to radio communications if not installed and used in accordance with the instructions. However, there is no guarantee that interference will not occur in a particular installation. If this equipment does cause harmful interference to radio or television reception, which can be determined by turning the equipment off and on, the user is encouraged to try to correct the interference by one or more of the following measures:• Reorient or relocate the receiving antenna.• Increase the separation between the equipment and receiver.• Connect the equipment into an outlet on a circuit different from that to which the receiver is connected.• Consult the dealer or an experienced radio/TV technician for help.FCC Caution:• Any changes or modifications not expressly approved by the partyresponsible for compliance could void the user‘s authority to operate this equipment.This device complies with Part 15 of the FCC Rules. Operation is subject to the following two conditions:(1) This device may not cause harmful interference, and(2) This device must accept any interference received, including interference that may cause undesired operation.--- English ------ Deutsch ------ Italiano ---2. Data Input / Dateneingang / Ingresso datiSECONDARY SAFETY MOUNTINGThe DataLink must always besecured by a safety wire when used in a hanging position. If the primary suspension fails, the device must not fall more than 20cm.Use M5 threads for safety wire. Please check the safetyregulations inyour region.Astera LED Technology GmbH Stahlgruberring 36 81829 Munich Germany*******************|DISPOSAL• Don‘t throw the unit into the garbage at the end of its lifetime.• Make sure that disposal is carried out in accordance with local ordinances and/or regulations to prevent pollution of the environment!• The packaging is recyclable and can be disposed.ORDER CODE: FP3-DTLMANUAL VERSION: 1.1DATE OF ISSUE: 04.21.20223. Status LED & control button / Status-LED und Steuerungs-taste / LED di stato e pulsante di controlloThe DataLink has a status LED next to the Ethernet socket. If the status LED is constantly on, this indicates that no DMX data is being received. If the status LED blinks slowly, this indicates that the DataLink receives DMX.The indicator LED can light up in different colors to indicate which data source is being received:Der DataLink verfügt über eine Status-LED neben derEthernet-Buchse. Die konstant leuchtende Status-LED zeigt an, dass keine DMX-Daten empfangen werden. Blinkt die Status-LED langsam, empfängt der DataLink DMX.Die Anzeige-LED leuchtet in verschiedenen Farben auf, um die jeweils empfangene Datenquelle darzustellen:DataLink è dotato di un LED di stato accanto alla presa Ethernet. Se il LED di stato è acceso fisso, significa che non è in corso la ricezione di dati DMX. Se il LED di stato lampeggia lentamente, significa che DataLink riceve dati DMX.La spia LED può accendersi in colori diversi per indicare la fonte dati che viene ricevuta:● Blue / Blau / BluArt-Net DHCP ● Magenta / Magenta / Magenta Art-Net 2.X address● Green / Grün / VerdeArt-Net 10.X address ● Y ellow / Gelb / GiallosACN ● Cyan / Cyan / CianoXLR There is a button next to the indicator LED. A single press on thebutton cycles between the different IP settings for Art-Net: DHCP, 2.x and 10.x. While sACN or Art-Net are received, DMX is also output on the XLR connector.Neben der Anzeige-LED befindet sich eine T aste. Mit einemeinmaligen Drücken der T aste wechseln Sie zwischen den verschiedenen IP-Einstellungen für Art-Net: DHCP, 2.x und 10.x. Während sACN oder Art-Net anliegen, wird auch DMX über den XLR-Anschluss ausgegeben.Accanto alla spia LED è presente un pulsante. Una singola pressione sul pulsante consente di alternare le diverse impostazioni IP per Art-Net: DHCP, 2.x e 10.x. Mentre vengono ricevuti dati sACN o Art-Net, vengono trasmessi anche dati DMX sul connettore XLR.USAGE / VERWENDUNG / UTILIZZOThe DataLink is required to establish a wired DMX connection to Hyperion Tubes. It does not have a built-in power supply but requires one Titan or Hyperion PSU (sold seperatly) per tube. That way power and DMX data can be connected to Astera Lights via Astera’s power/datacombination cable (FP1-PWB-CAB-5/10/15) (sold separately), allowing the lights to be wired for a longer show or permanent installation.The DataLink contains 5-pin XLR IN and OUT sockets so that several DataLinks can be daisy chained. In addition, data can also be applied to the DataLink via its RJ45 Ethernet socket which accepts Art-Net DHCP, 2.X and 10.X as well as sACN. Its operation is explained in the next chapter. The DataLink has 4 DC/Data OUT sockets to wire 4 Helios/ Titan/ Hyperion Tubes via power/data combination cables (sold separately).Der DataLink wird benötigt, um eine drahtgebundene DMX-Verbin-dung zu Hyperion Tubes herzustellen. Er verfügt nicht über ein eingebau-tes Netzteil, sondern benötigt ein Titan- oder Hyperion-Netzteil (gesondert erhältlich) pro Röhre. Dadurch können Strom und DMX-Daten über Asteras Strom-/Daten-Kombikabel (FP1-PWB-CAB-5/10/15) (gesondert erhältlich) an die Astera Leuchten angeschlossen werden, sodass die Leuchten für eine längere Show oder eine feste Installation verkabelt werden können.Der DataLink enthält-5-polige XLR IN- und OUT-Buchsen, so dass mehrere DataLinks in Reihe geschaltet werden können. Darüber hinaus kann die PowerBox über die RJ45-Ethernet-Buchse mit Daten aus Art-Net DHCP, 2.X und 10.X sowie sACN versorgt werden. Die Bedienung wird im nach-folgenden Abschnitt erläutert.Der DataLink verfügt über vier DC/Data-OUT-Buchsen für die Verkabelung von vier Helios/Titan/Hyperion Tubes über Strom-/Daten-Kombikabel (ge-sondert erhältlich).DataLink è necessario per stabilire una connessione DMX cablata ai tubi Hyperion. Non è dotato di alimentazione integrata, ma richiede una PSU Titan o Hyperion (in vendita separatamente) per tubo. In questo modo è possibile collegare alimentazione e dati DMX alle luci Astera attraverso un cavo combinato alimentazione/dati di Astera (FP1-PWB-CAB-5/10/15) (in vendita separatamente), cosa che consente di collegare le luci per un evento più lungo o per un'installazione permanente.DataLink contiene prese di ingresso e uscita XLR a 5 pin per il collega-mento in daisy chain di più DataLink. È inoltre possibile applicare dati a DataLink tramite la sua presa Ethernet RJ45, che accetta Art-Net DHCP, 2.X, 10.X e sACN. Il procedimento verrà spiegato nel prossimo capitolo. DataLink è dotato di 4 prese di uscita dati/CC che consentono di collegare 4 tubi Helios/Titan/Hyperion attraverso cavi combinati alimentazione/dati (in vendita separatamente).1. DC- and DMX-Wiring / Gleichspannungs- und DMX-Verkabelung / Cablaggio CC e DMXUsers Manual Benutzerhandbuch Manuale utenteEnglish Deutsch ItalianoPRODUCT OVERVIEW / PRODUKTÜBERSICHT / PANORAMICA DEL PRODOTTOIsometric view / Isometrische Ansicht / Vista isometrica: 4. Reset & Update Firmware / Reset und Firmware-Update / Reset e aggiornamento del firmwareY ou can enter the reset mode anytime by holding down the power button for 8s.The controller can be reset to restore the universe ID to 1 again.Also, during each reset the controller tries to download a software update from the Internet. To be successful, it must be connected to a LAN which has an Internet access. Be sure that the DataLink is in Art-Net DHCP mode: blue LED is on.The reset is done like this:Hold the button down → LED blinks blue → hold still → stops blue blinking after 4 seconds.When the LED turns red, indicating the reset has been successful. Re-lease the button. The DataLink returns to Art-Net 2.x again if no update was found.If an update was found, the LED flashes green/blue until the update has been installed.Sie können jederzeit in den Reset-Modus wechseln, indem Sie die Einschalttaste acht Sekunden lang gedrückt halten.Der Controller kann zurückgesetzt werden, um die Universums-ID wieder auf 1 zu setzen.Bei jedem Reset versucht der Controller außerdem, ein Software-Up-date aus dem Internet herunterzuladen. Voraussetzung dafür ist der Anschluss an ein LAN mit Internetzugang. Der DataLink muss sich im Art-Net-DHCP-Modus befinden: die blaue LED leuchtet.Das Reset wird folgendermaßen durchgeführt:Taste gedrückt halten → LED blinkt blau → gedrückt halten → blaues Blinken hört nach vier Sekunden auf.Die rot leuchtende LED zeigt an, dass das Reset erfolgreich war. Lassen Sie die Taste los. Der DataLink schaltet wieder auf Art-Net 2.x zurück, wenn kein Update gefunden wurde.Wurde ein Update gefunden, blinkt die LED grün/blau, bis dieses instal-liert ist.È possibile accedere in qualsiasi momento alla modalità di reset tenendo premuto il pulsante di alimentazione per 8 secondi.È possibile resettare il controller per ripristinare l'ID universo di nuovo su 1.Inoltre, durante ogni reset il controller cerca di scaricare un aggiorna-mento software da Internet. Perché l'operazione abbia successo è neces-sario essere collegati a una LAN con accesso a Internet. Accertarsi che DataLink si trovi in modalità Art-Net DHCP: il LED blu è acceso.Il reset viene effettuato nel seguente modo:Tenere premuto il pulsante → Il LED lampeggia in blu → continuare a tene-re premuto il pulsante → il lampeggio blu si arresta dopo 4 secondi.Il reset è completo quando il LED diventa rosso. Rilasciare il pulsante. DataLink torna di nuovo ad Art-Net 2.x se non sono stati trovati aggior-namenti.Nel caso in cui venga trovato un aggiornamento, il LED lampeggia in verde/blu fino a che l'aggiornamento non viene installato.When the DataLink is in normal mode (i.e. not blinking, no reset/update ongoing) a long press (4 seconds)* enters the universe ID setting mode. In this mode the indicator LED blinks blue and shows the universe ID. For example; if the universe ID is 8, the LED blinks blue for 8 times then it stops for 2 seconds, this sequence is looped. A single short press increases the universe ID. As the maximum ID is 16 in this mode, a single short press sets to 1 if the universe ID is 16. During the universe ID setting mode a long press (4 seconds) goes back to normal mode.* Be aware that 8 seconds long press enters the reset mode and restores the universe ID to 1 again!Befindet sich der DataLink im Normalmodus (d. h. er blinkt nicht, es findet kein Reset bzw. Update statt), wird durch langes Drücken (vier Sekunden)* der Modus zur Einstellung der Universums-ID aktiviert. In diesem Modus blinkt die Anzeige-LED blau und zeigt die Universums-ID an. Ist beispielsweise die Universums-ID auf 8 eingestellt, blinkt die LED achtmal blau und stoppt dann für zwei Sekunden, wobei sich diese Abfolge in einer Schleife laufend wiederholt. Ein einziger kurzer Tastendruck erhöht die Universums-ID. In diesem Modus ist 16 diehöchste ID, so dass ein einziger weiterer kurzer Tastendruck die ID auf 1 setzt, wenn die Universums-ID zuvor auf 16 stand. Ein langer Druck (vier Sekunden) führt aus dem Einstellungsmodus der Universums-ID zurück in den Normalmodus.* Beachten Sie, dass ein langer Tastendruck von acht Sekunden den Reset-Modus aktiviert und die Universums-ID wieder auf 1 zurücksetzt!Quando DataLink si trova in modalità normale (ovvero non lampeggia o non è in corso un reset/aggiornamento) una pressione lunga(4 secondi)* consente di accedere alla modalità di impostazione dell'ID universo. In questa modalità la spia LED lampeggia in blu e indica l'ID universo. Ad esempio, se l'ID universo è 8, il LED lampeggia in blu per 8 volte, quindi si arresta per 2 secondi; la sequenza viene ripetuta. Una singola pressione breve incrementa l'ID universo. Poiché l'ID massimo è 16 in questa modalità, se l'ID universo è 16 una singola pressione breve lo imposta su 1. Durante la modalità di impostazione dell'ID universo una pressione lunga (4 secondi) consente di tornare alla modalità normale.* Attenzione: una pressione lunga di 8 secondi comporta l'accesso alla modalità di reset e il ripristino dell'ID universo di nuovo su 1!5. Change universe ID manually / Universums-ID manuell ändern / Modifica manuale dell'ID universoSPECIFICATIONS - TECHNICAL DATAOrder Code FP3-DTL DC Input 4 x 24VDC, max. 4ADC Output 4 x 24 VDCOutput Connectors 4 x DC Barrel (5.5 mm / 2.1 mm)Data Input XLR-DMX; ART-Net (1 Universe);sACN (1 Universe)Data Output DMX via DC sockets Data sockets 5-pin XLR in/out; RJ45 inputIP Rating IP20Dimensions 267 mm x 69 mm x 64 mm /10.5” x 2.7” x 2.5”Weight0.5 kg / 1.10 lbs Housing MaterialAluminiumThe DataLink has 4 M5 threads and 2 1/4” - 16 UNC threads to easily attach appropriate mounting accessories.When hanging, always secure with a safety wire. Therefore one of the threads can be used to attach a safety eyebolt (FP1-EBLT) (sold sepa-rately). Make sure the DataLink cannot drop more than 20cm if primary mounting fails.Der DataLink verfügt über vier Gewinde M5 und zwei Gewinde 1/4”-16 UNC zur einfachen Befestigung von geeignetem Montagezubehör.Beim Aufhängen immer mit einem Sicherungsseil sichern. Folglich kann eines der Gewinde zum Anbringen einer Sicherungs-Ringschraube (FP1-EBLT) verwendet werden (gesondert erhältlich). Stellen Sie sicher, dass der DataLink nicht mehr als 20 cm frei fallen kann, wenn die primäre Befestigung versagt.DataLink è dotato di 4 filettature M5 e di 2 filettature UNC da 1/4"-16 per il facile fissaggio degli accessori di montaggio appropriati.Se viene appeso, deve essere sempre fissato con un cavo di sicurezza. Di conseguenza una delle filettature può essere utilizzata per fissare ungolfare di sicurezza (FP1-EBLT) (in vendita separatamente). Accertarsi che DataLink non possa cadere per più di 20 cm in caso di cedimento del supporto principale.6. Rigging / Montage / InstallazioneEspañol Francais Chinese中文Manual del usuario Manuel d’utilisation用户手册INFORMAZIONI DI SICUREZZALeggere attentamente il manuale prima di azionare l'unità. Accertarsi sempre di includere il manuale se si presta/noleggia/vende l'unità a un altro utente. Prestare attenzione durante l'uso.Il prodotto è destinato esclusivamente all'uso professionale. Non è adatto all'uso domestico.• Non utilizzare l'unità in aree caratterizzate da temperature elevate o sotto la luce del sole diretta. Sussiste il rischio di funzionamento anomalo o danneggiamento del prodotto.• Utilizzare sempre un cavo di sicurezza adeguato quando si monta l'unità sospendendola.• Collegare il cavo di sicurezza solo al supporto di sicurezza designato.• Seguire sempre le normative locali in materia di sicurezza.• Non metterla nel fuoco né esporla al calore.• Non utilizzare l'unità se è danneggiata.• Evitare di farla urtare contro altri oggetti o farla cadere in quan-to potrebbe provocare un incendio o un'esplosione.• Si consiglia di ricaricare la batteria a una temperatura compre-sa tra 15 °C e 35 °C.Avvertenza: in casi estremi, abuso o uso improprio di batterie standard/ricaricabili, sussiste il rischio di:• Esplosione• Sviluppo di incendi• Generazione di calore o sviluppo di fumo e gas• Non aprire l'alloggiamento del prodotto.• Non accendere l'unità se è danneggiata.• Non immergere l'unità in liquidi.• Attenzione, rischio di scossa elettrica.DataLink deve essere installato vicino alla presa di corrente, che deve essere facilmente accessibile.Attenzione: pericolo di scossa elettrica - Non aprire il dispositivo.• Durante il normale funzionamento le superfici esterne dell'unità possono diventare molto calde, fino a 70 °C.• Accertarsi che il contatto fisico accidentale con il dispositivo sia impossibile.• Installare solo in luoghi ventilati.• Non coprire il dispositivo.• Lasciare sempre raffreddare tutte le unità prima di toccarle.INTRODUZIONE/USO PREVISTODataLink è necessario per l'invio di dati DMX, Art-Net e sACN cablati ai tubi Hyperion. Inoltre è anche utile per i tubi Titan e i tubi Helios se non è disponibile una Titan PowerBox o per aggiungere un ulteriore universo DMX a Titan PowerBox. Non è dotato di alimentazione integrata, ma richiede una PSU Titan o Hyperion (in vendita separatamente) per tubo, per cui è possibile collegare fino a 4 tubi con 4 alimentazioni. Dallequattro prese DC OUT, alimentazione e dati possono viaggiare entrambi su cavi speciali; in questo modo è necessario un solo cavo per collegare un tubo Hyperion/Titan/Helios a DataLink.DataLink può essere utilizzato su un supporto o appeso. A tale scopo, il dispositivo è dotato di 4 filettature M5 e 2 filettature UNC da 1/4"-16 per il facile fissaggio degli accessori di montaggio appropriati.DataLink può essere utilizzato in interni e ha un grado di protezione IP20.Non scuotere il dispositivo. Evitare di esercitare una forza eccessiva durante l'installazione o il funzionamento del dispositivo.Quando si sceglie il luogo di installazione, accertarsi che il dispositivo non sia esposto a polvere o calore estremo. Evitare la luce diretta del sole per periodi di tempo prolungati.Durante i temporali non utilizzare mai il dispositivo collegatoall'alimentazione di rete. La sovratensione può distruggere il dispositivo. Scollegare sempre il dispositivo durante i temporali.Accertarsi che l'area sotto il luogo di installazione sia bloccata durante l'installazione, la disinstallazione o la manutenzione dell'apparecchio.Fissare sempre l'apparecchio con un cavo di sicurezza appropriato.Azionare il dispositivo solo dopo avere acquisito familiarità con le sue funzioni.Tenere presente che le modifiche non autorizzate sul dispositivo non sono consentite per motivi di sicurezza! Se il dispositivo verrà azionato in modo diverso da quello descritto in questo manuale, potrebbe riportare danni e la garanzia verrebbe invalidata.Il disclaimer include tutti i danni, la responsabilità o le lesioni derivanti dall'inosservanza delle istruzioni contenute in questo manuale. Qualsiasi altro funzionamento può inoltre comportare pericoli come cortocircuiti, ustioni, scosse elettriche, urti, ecc. Questo dispositivo non è adatto all'uso domestico né per l'installazione fissa.PULIZIA E MANUTENZIONEAvvertenza: l'ingresso di liquidi nell'alloggiamento deldispositivo può provocare un cortocircuito e danneggiare i componenti elettronici. Non utilizzare detergenti o solventi. Pulire esclusivamente utilizzando un panno morbido inumidito.DICHIARAZIONE DEL PRODUTTOREAstera LED Technology GmbH dichiara che il tipo di interfaccia dicontrollo FP3-DTL DataLink è conforme alla direttiva 2014/35/UE. Il testo completo della dichiarazione di conformità UE è disponibile all'indirizzo https:///hyperion/Astera LED Technology GmbH dichiara che questa apparecchiatura è stata testata e ritenuta conforme ai limiti per un dispositivo digitale di classe B, come specificato nella parte 15 delle normative FCC. Tali limiti sono studiati per fornire una protezione ragionevole rispetto alle interferenze dannose in un'installazione domestica. Se l'apparecchiatura non viene installata e utilizzata in conformità con le istruzioni, può causare interferenze dannose alle comunicazioni radio. Tuttavia, non vi è garanzia che non si verifichino interferenze in un'installazione particolare. Sel'apparecchiatura causa interferenze alla ricezione radiotelevisiva, verifica-bili accendendola e spegnendola, si consiglia all'utente di correggere le interferenze in uno dei seguenti modi:• Riorientare o posizionare altrove l'antenna di ricezione. • Aumentare la distanza tra l'apparecchiatura e il ricevitore.• Collegare l'apparecchiatura a una presa su un circuito diverso da quello a cui è connesso il ricevitore.• Contattare il rivenditore o un tecnico radiotelevisivo qualificato per assistenza.Avvertenza FCC:• Qualsiasi modifica o alterazione non espressamente approvata dalla parte responsabile della conformità può invalidare l'autorità dell'utente a utilizzare l'apparecchiatura.Questo dispositivo è conforme alla parte 15 delle normative FCC. Il funzio-namento è soggetto alle due condizioni seguenti:(1) il dispositivo non deve causare interferenze dannose e(2) il dispositivo deve tollerare le interferenze ricevute, incluse le interfe-renze che possano causare un funzionamento indesiderato.MONTAGGIO DI SICUREZZA SECONDARIODataLink deve essere sem-pre fissato con un cavo di sicurezza se viene utilizzato appeso. In caso di cedimento della sospensione principale, il dispositivo non deve cade-re per più di 20 cm.Utilizzare filettature M5 per il cavodi sicurezza. Controllare le normative di sicurezza dellapropria regione.SMALTIMENTO• Non smaltire l'unità insieme ai rifiuti domestici normali al termine della sua vita utile.• Accertarsi di smaltirla conformemente alle normative e/o ai regolamenti locali per evitare di inquinare l'ambiente!• L 'imballaggio è riciclabile e può essere smaltito.SPECIFICHE - DATI TECNICICodice per l'ordinazione FP3-DTL Ingresso CC 4 x 24 VCC, max 4 AUscita CC 4 x 24 VCC Connettori uscita 4 connettori cilindrici CC(5,5 mm/2,1 mm)Ingresso dati XLR-DMX; ART-Net (1 universo);sACN (1 universo)Uscita dati DMX tramite prese CC Prese datiIngresso/Uscita XLR 5 pin; ingressoRJ45Grado di protezione IP IP20Dimensioni 267 mm x 69 mm x 64 mm /10,5” x 2,7” x 2,5”Peso0,5 kg Materiale alloggiamentoAlluminioSICHERHEITSHINWEISELesen Sie das Handbuch sorgfältig durch, bevor Sie das Gerät in Betrieb nehmen. Geben Sie das Handbuch immer mit, wenn Sie das Gerät an einen anderen Benutzer weitergeben, vermieten oder verkaufen. Gehen Sie bei der Bedienung bitte mit der gebotenen Vorsicht vor.Dieses Produkt ist nur für den professionellen Gebrauch bestimmt. Es ist nicht für den Hausgebrauch bestimmt.• Betreiben Sie das Gerät nicht in Bereichen mit hohen Tempe-raturen oder unter direkter Sonneneinstrahlung. Dies kann zu Fehlverhalten oder Schäden am Gerät führen.• Verwenden Sie immer ein geeignetes Sicherungsseil, wenn Sie die Einheit über Kopfhöhe montieren.• Befestigen Sie das Sicherungsseil nur an der vorgesehenen Sicherungshalterung.• Beachten Sie stets die örtlichen Sicherheitsvorschriften.• Nicht in offenes Feuer oder Hitze bringen.• Verwenden und laden Sie die Einheit nicht, wenn sie beschä-digt ist.• Vermeiden Sie Stöße oder Stürze, da dies zu einem Brand oder einer Explosion führen kann.• Die empfohlene Ladetemperatur liegt zwischen 15 °C und 35 °C.Warnhinweis: Missbrauch oder Fehlgebrauch von Standardbatterien bzw. Akkus führt im Extremfall zu folgenden Auswirkungen:• Explosion• Brandentwicklung• Wärmeentwicklung oder Rauch- und Gasentwicklung.• Das Gehäuse darf nicht geöffnet werden.• S chließen Sie die Einheit nicht an das Stromnetz an, wenn sie beschädigt ist.• Tauchen Sie die Einheit nicht in Flüssigkeiten ein.• Vorsicht, Gefahr eines Stromschlags.Der DataLink muss in der Nähe einer leicht zugänglichen Steck-dose installiert werden.Warnhinweis: Gefahr eines elektrischen Schlages - Gerät nicht öffnen.• Die Außenflächen der Leuchte können bei normalem Betrieb bis zu 70 °C heiß werden.• Stellen Sie sicher, dass ein versehentlicher Körperkontakt mit dem Gerät ausgeschlossen ist.• Nur an belüfteten Orten einsetzen.• Decken Sie das Gerät nicht ab.• Lassen Sie alle Einheiten abkühlen, bevor Sie sie berühren.EINFÜHRUNG / BESTIMMUNGSGEMÄSSER GEBRAUCHDer DataLink wird benötigt, um kabelgebundene DMX-, Art-Net- und sACN-Daten an Hyperion Tubes zu übertragen. Des Weiteren ist er auch für Titan Tubes und Helios Tubes nützlich, wenn keine Titan PowerBox vorhanden ist oder um ein zusätzliches DMX-Universum zur Titan PowerBox hinzuzufügen. Er hat kein eingebautes Netzteil, sondern benötigt ein Titan- oder Hyperion-Netzteil (gesondert erhältlich) pro Röhre, so dass bis zu vier Röhren mit vier Netzteilen angeschlossen werden können. Von den vier DC-OUT-Buchsen können sowohl Strom als auch Daten über Spezialkabel geführt werden, so dass nur ein Kabel erforderlich ist, um ein Hyperion/Titan/Helios Tube mit dem DataLink zu verbinden.Der DataLink kann sowohl stehend als auch hängend verwendet werden. Der DataLink verfügt dazu über vier Gewinde M5 und zwei Gewinde 1/4”-16 UNC zur einfachen Befestigung von geeignetem Montagezube-hör.Der DataLink kann im Innenbereich eingesetzt werden und entspricht Schutzart IP20.Das Gerät nicht schütteln. Vermeiden Sie jegliche Gewaltanwendung bei der Installation oder Bedienung des Geräts.Achten Sie bei der Wahl des Einsatzortes darauf, dass das Gerät weder extremer Hitze noch Staub ausgesetzt wird. Vermeiden Sie direkte Sonneneinstrahlung über einen längeren Zeitraum.Verwenden Sie das Gerät niemals am Stromnetz während eines Gewitters. Durch Überspannung kann das Gerät zerstört werden.Trennen Sie das Gerät während eines Gewitters immer vom Stromnetz.Achten Sie darauf, dass der Bereich unterhalb des Einbauortes beim Auf- und Abbau sowie bei der Wartung des Gerätes gesperrt ist.Sichern Sie die Vorrichtung immer mit einem geeigneten Sicherungsseil.Bedienen Sie das Gerät erst, nachdem Sie sich mit seinen Funktionen vertraut gemacht haben.Beachten Sie unbedingt, dass unbefugte Änderungen am Gerät aus Sicherheitsgründen nicht zulässig sind! Falls das Gerät abweichend von der in diesem Handbuch beschriebenen Art und Weise betrieben wird, sind Schäden daran möglich und die Garantie erlischt.Der Haftungsausschluss schließt alle Schäden, Haftungen oderVerletzungen ein, die sich aus der Nichtbeachtung der Anweisungen in diesem Handbuch ergeben.Ferner kann jeder andere Betrieb zu Gefahren wie Kurzschluss,Verbrennungen, Stromschlag, Absturz usw. führen. Dieses Gerät ist nicht für den Hausgebrauch und nicht für die Festinstallation geeignet.REINIGUNG UND PFLEGEVorsicht: In das Gerätegehäuse eindringende Flüssigkeiten können einen Kurzschluss verursachen und die Elektronik beschädigen. Verwenden Sie keine Reinigungs- oderLösungsmittel. Nur mit einem weichen, feuchten Tuch reinigen.SEKUNDÄRSICHERUNGDer DataLink muss bei hängendem Einsatz immer mit einem Sicherungsseil gesichert werden. Wenn die primäre Aufhängung versagt, darf das Gerät nicht mehr als 20 cm frei fallen.Verwenden Sie die Gewinde M5 für das Sicherungsseil. Beachten Sie bitte die Sicher-heitsvorschriften in Ihrer Region.ENTSORGUNG• Werfen Sie die Einheit am Ende ihrer Produktlebensdauer nicht in den Müll.• Achten Sie darauf, dass die Entsorgung gemäß den örtlichen Verordnungen bzw. Vorschriften erfolgt, um eine Verschmut-zung der Umwelt zu vermeiden!• Die Verpackung ist wiederverwertbar und kann entsorgt werden.HERSTELLERERKLÄRUNGHiermit erklärt die Astera LED Technology GmbH, dass der Typ der Steue-rungsschnittstelle FP3-DTL DataLink der Richtlinie 2014/35/EU entspricht. Der vollständige Text der EU-Konformitätserklärung ist unter folgender Internetadresse abrufbar: https:///hyperion.Astera LED Technology GmbH erklärt, dass dieses Gerät getestet wurde und die Grenzwerte für ein digitales Gerät der Klasse B gemäß Teil 15 der FCC-Vorschriften einhält. Diese Grenzwerte sind so ausgelegt, dass sie einen angemessenen Schutz gegen schädliche Störungen in einer Wohn-umgebung bieten. Wenn das Gerät nicht in Übereinstimmung mit den An-weisungen installiert und verwendet wird, kann es schädliche Störungen des Funkverkehrs verursachen. Allerdings gibt es keine Garantie dafür, dass bei bestimmten Installationen keine Störungen auftreten können. Wenn diese Anlage Störungen des Radio- oder Fernsehempfangs ver-ursacht, was durch Ein- und Ausschalten der Anlage festgestellt werden kann, sollte der Benutzer versuchen, die Störungen durch eine oder mehrere der folgenden Maßnahmen zu beheben:• Richten Sie die Empfangsantenne neu aus oder verlegen Sie sie. • Vergrößern Sie den Abstand zwischen Anlage und Empfänger.• Schließen Sie das Gerät an eine Steckdose an, die nicht mit dem Strom-kreis verbunden ist, an dem der Empfänger angeschlossen ist.• Wenden Sie sich an den Händler oder einen erfahrenen Radio- oder Fernsehtechniker und fragen Sie ihn um Rat.FCC-Warnhinweis:• Jegliche Änderungen oder Umbauten, die nicht ausdrücklich von der für die Einhaltung der Vorschriften verantwortlichen Stelle genehmigt wurden, können dazu führen, dass der Benutzer die Berechtigung zum Betrieb dieser Anlage verliert.Dieses Gerät erfüllt die Anforderungen von Teil 15 der FCC-Vorschriften. Der Betrieb unterliegt den folgenden zwei Bedingungen:(1) Dieses Gerät darf keine schädlichen Störungen verursachen, und (2) dieses Gerät muss alle empfangenen Störsignale annehmen, ein-schließlich solcher, die einen unerwünschten Betrieb verursachen können.SPEZIFIKATIONEN - TECHNISCHE DATENBestellcodeFP3-DTL Gleichspannungs-Eingang 4 x 24 V, max. 4 AGleichspannungsausgang 4 x 24 VAusgangsanschlüsse 4 x DC Barrel (5,5 mm/2,1 mm)Dateneingang XLR-DMX; ART-Net (1 Universum);sACN (1 Universum)Datenausgang DMX via DC-Buchsen Datenbuchsen 5-pin XLR IN/OUT; RJ45-EingangIP-Schutzart IP20Abmessungen 267 mm x 69 mm x 64 mm /10,5” x 2,7” x 2,5”Gewicht 0,5 kg GehäusematerialAluminium。

a r X i v :h e p -e x /0601021v 1 13 J a n 2006Limits on different Majoron decay modes of 100Mo and 82Se for neutrinoless double betadecays in the NEMO-3experimentR.Arnold j ,C.Augier h ,J.Baker e ,A.S.Barabash 1)g ,V.Brudanin c ,A.J.Caffrey e ,E.Caurier j ,V.Egorov c ,K.Errahmane h ,A.I.Etienvre h ,J.L.Guyonnet j ,F.Hubert a ,Ph.Hubert a ,C.Jollet j ,S.Jullian h ,S.King n ,O.Kochetov c ,S.Konovalov g ,V.Kovalenko c ,lanne h ,F.Leccia a ,C.Longuemare b ,G.Lutter a ,Ch.Marquet j ,F.Mauger b ,F.Nowacki j ,H.Ohsumi m F.Piquemal a ,J-L.Reyss d ,R.Saakyan n ,X.Sarazin h ,Yu.Shitov c ,L.Simard h ,F.ˇSimkovic o ,A.Smolnikov c ,I.ˇStekl k ,J.Suhonen f ,C.S.Sutton i ,G.Szklarz h ,V.Timkin c ,J.Thomas n ,V.Tretyak c ,V.Umatov g ,L.V´a la k ,I.Vanyushin g ,V.Vasilyev g ,V.Vorobel ℓ,Ts.Vylov ca CENBG,IN2P3-CNRS et Universit´e de Bordeaux,33170Gradignan,France b LPC,IN2P3-CNRS et Universit´e de Caen,14032Caen,France c JINR,141980Dubna,Russia d CFR,CNRS,91190Gif sur Yvette,France e INL,Idaho Falls,ID 83415,U.S.A.f JYV ¨ASKYL ¨A University,40351Jyv¨a skyl¨a ,Finlandg ITEP,117259Moscow,Russia h LAL,IN2P3-CNRS et Universit´e Paris-Sud,91405Orsay,Francei MHC,South Hadley,Massachusetts 01075,U.S.A.j IReS,IN2P3-CNRS et Universit´e Louis Pasteur,67037Strasbourg,France.k IEAP,Czech Technical University,CZ-12800Prague,Czech Republic.ℓCharlesUniversity,Prague,Czech Republic.m SAGA University,Saga,Saga 840-8502,Japan n UniversityCollege London,London,UK o FMFI,Comenius University,SK-84248Bratislava,SlovakiaNEMO Collaboration1IntroductionSpontaneous violation of global(B-L)symmetry in gauge theories leads to the existence of a massless Goldstone boson,the Majoron.The Majoron,if it exists,could play an important role in Cosmology[1,2,3]and Astrophysics [4,5,6,7].At the beginning of the1980’s,the singlet[8],doublet[9]and triplet [10]Majoron models were developed.All these models resulted in the neutri-noless double beta decay with the emission of a Majoron(A,Z)→(A,Z+2)+2e−+χ0(1) However,the interaction of the triplet(or doublet)Majorons with the Z0 boson would give a contribution to the width of the Z0decay,which corre-sponds to two(or1/2)additional massless neutrino types(see for example [11,12,13]).LEP data gives2.994±0.012neutrino types[14],thus the triplet and some doublet Majorons are excluded.On the other hand the singlet”see-saw”Majoron[8]is extremely weakly coupled with neutrinos.Nevertheless, in reference[15]it is proposed that a small gauge coupling constant(which determines the Majoron coupling to the Z0boson)does not eliminate the pos-sibility of a large Yukawa coupling of Majoron to neutrinos.Thus,the singlet or dominantly singlet Majorons can still contribute to neutrinoless2βdecay [15,16].Another possibility for neutrinoless2β-decay with Majoron emission arises in supersymmetric models with R-parity violation[16,17].Mohapatra and Takasugi[17]proposed that there could be2βχ0χ0-decay with the emission of two Majorons:(A,Z)→(A,Z+2)+2e−+2χ0(2) In the1990’s several new”Majoron”models were suggested.The term”Ma-joron”here denotes massless or light bosons with a coupling to neutrinos.In these models the”Majoron”can carry a lepton charge,but cannot be a Gold-stone boson[19].Additionally there can be decays with the emission of two ”Majorons”[20].In the models with a vector”Majoron”,the Majoron is the longitudinal component of the massive gauge boson emitted in2βdecay[21]. All these new objects are called Majorons for simplicity.The possibility for 2βdecay with the emission of one or two Majorons was discussed also in the framework of the SU(3)L⊗SU(1)N electroweak model[18].Recently a new”economical”model for neutrino mass was proposed in the context of the brane-bulk scenarios for particle physics.In this model the standard global B-L symmetry is broken spontaneously by a gauge singletHiggsfield in the bulk.This leads to a bulk singlet Majoron whose Kaluza-Klein excitations may make it visible in neutrinoless double beta decay[22]. In Table1there are10Majoron models presented(following[20,21,22,23]), which are considered in this paper.It is divided into two sections,one for lepton number violating(I)and one for lepton number conserving models (II).The last line corresponds to the bulk majoron model.The table also shows whether the corresponding2βdecay is accompanied by the emission of one or two Majorons.The next three entries list the main features of the models:the third column lists whether the Majoron is a Goldstone boson or not(or a gauge boson in the case of vector Majorons,type IIF,or a bulkfield Majoron).In column four the leptonic charge L is given.Columnfive gives the”spectral index”n of the summed energy of the emitted electrons,which is defined by the phase space of the emitted particles,G∼(Qββ−T)n.Here Qββis the energy released in the decay and T the energy of the two electrons. The energy spectra of different modes of2β2ν(n=5),2βχ0(n=1,2and3) and2βχ0χ0(n=3and7)decays are presented in Fig1.The different shapes can be used to distinguish the different Majoron decay modes from each other and2β-decay with the emission of two neutrinos.In the last column of Table1 the nuclear matrix elements(NME)are listed.Attempts to observe2βdecay with Majoron emission have been carried out for the past20years.Consequently there now exist strong limits on the”ordi-nary”Majoron with the”standard”electron energy spectrum shape(n=1), see Table2.Sufficiently less information exists for”non-ordinary”Majoron models.The most carefully studied”non-ordinary”models are being investi-gated in[39]for76Ge,and in[40]for100Mo,116Cd,82Se and96Zr(see also [34]for116Cd).In this paper a systematic search for2β-decays with different Majoron types is described for100Mo and82Se,using the experimental data obtained with the NEMO-3detector.Thefirst results from NEMO-3were published in[41,42,43]. 2NEMO-3detectorA schematic of the NEMO-3detector is shown in(Fig.2).The main goal of the NEMO-3experiment is to study neutrinoless double beta decay of different isotopes(100Mo,82Se etc.)with a sensitivity of up to∼1025y,which corresponds to a sensitivity to the effective Majorana neutrino mass at the level of∼(0.1−0.3)eV[44].The planned sensitivity to double beta decay with Majoron emission is∼1023y(the sensitivity to the coupling constant of the Majoron to the neutrino<g ee>is∼n·10−5).In addition,one of the goalsis a precise study of2β2νdecay for a number of nuclei(100Mo,82Se,116Cd, 150Nd,130Te,96Zr and48Ca)with high statistics to study all characteristics of the decay.NEMO-3is a tracking detector,which in contrast to76Ge experiments[45,46], detects not only the total energy deposition but also the path and energy of the individual electrons.This also provides a unique opportunity to monitor and reject the background.Since June2002NEMO-3has been running in the Fr´e jus Underground Laboratory(France)located at a depth of4800m w.e. The detector has a cylindrical shape and consists of20identical sectors(see Fig2).A thin(∼30-60mg/cm2)source foil placed in the center of the detector contains2βdecaying nuclei and has a total area of20m2and a weight of about 10kg.In particular,it includes7.1kg of enriched Mo(average enrichment98%, the total mass of100Mo is6.914kg)and0.96kg of Se(enrichment97%,the total mass of82Se is0.932kg).To investigate the external background the part of the source are made of very pure natural material(TeO2-767g and Cu-621g).The contamination of the sources with radioactive impurities was obtained from measurements using low-background HPGe-detectors.The basic detection principles are the following:the energy of electrons is measured by plastic scintillators coupled to PMTs(1940individual counters), while the tracks are reconstructed from the information obtained from the Geiger cells(6180cells).The tracking volume of the detector isfilled with a mixture consisting of95%He,4%alcohol,1%Ar and0.15%water at slightly above atmospheric pressure.In addition,a magneticfield of25Gauss parallel to the detector axis is created by a solenoid surrounding the detector.The magneticfield is used to identify electron-positron pairs and to suppress the background associated with these events.The main characteristics of the detector’s performance are the following:the energy resolution of the scintillation counters lies in the interval of14-17% (FWHM for1MeV electrons);the time resolution is250ps for an electron en-ergy of1MeV;the reconstruction accuracy of a2e−vertex is approximately 1cm.The characteristics of the detector are determined in special calibra-tion measurements with radioactive sources.The energy calibration is carried out using207Bi sources(conversion electrons with energies0.482and0.976 MeV)and90Sr(the end-point of theβspectrum is2.283MeV).The vertex reconstruction accuracy for2e−events are determined by measurements with 207Bi,while the timing properties were determined in measurements with60Co (twoγs emitted simultaneously),207Bi(two electrons emitted simultaneously) and neutron sources(providing high energy electrons crossing the detector volume).The detector is surrounded by passive shielding made of20cm of steel,30cmof water in tanks around the detector and wood and paraffin at the top and bottom of the detector.The level of radioactive impurities in the construction materials of the detector and of the passive shielding was measured with low-background HPGe detectors.A full description of the detector and its characteristics can be found in[47]. 3Experimental data3.1100MoIn this paper,the analysis of8023hours of NEMO3data is presented.2e events with a common vertex inside the source were selected.An electron was defined as a track between the source foil and afired counter with the energy deposited being greater than200keV.The track curvature had to be consistent with a negatively charged particle;the time-of-flight measurement had to be consistent with the hypothesis of the two electrons leaving the source from a common vertex simultaneously.In order to suppress the214Bi background,which is followed by the214Poα-decay,it was required that there were no delayed Geiger cell hits(with a delay of up to700µs)close to the event vertex or the electron track.A typical2e-event is shown in Fig3.Fig4(top)shows the2β2νexperimental energy spectrum and result of Monte Carlo(MC)simulations for100Mo.The total number of useful events(after background subtraction)is∼158000.The signal-to-background ratio is40:1, while,for energies above1MeV it is100:1.This means that the background is negligibly small.The detection efficiencies which included the selection cuts were estimated for the single state dominance mechanism[48,49]by MC sim-ulations.The detection efficiency calculated by MC was4.41%.Correspond-ingly,the following results were obtained for the100Mo half-life:T1/2=[7.41±0.02(stat)±0.43(syst)]·1018y3.282SeThe same8023h of data were analyzed.The experimental energy spectrum and result of MC simulations of2β2νevents for82Se are shown in Fig4 (bottom).The total number of useful events after the background subtractionwas∼2020.The signal-to-background ratio was about4:1.The detection efficiency was calculated by Monte Carlo to be4.46%.The82Se half-life value obtained is:T1/2=[9.6±0.24(stat)+0.67−0.59(syst)]·1019y.This value is in agreement with the previous measurement made with the NEMO-2detector[50].4Analysis of the Experimental DataThe experimental data for100Mo and82Se are shown in Fig.4.One can see that experimental data are in a good agreement with the MC simulations. Exception is a low energy part of the100Mo spectrum(0.4-0.8MeV),where the experimental points are systematically higher than the MC simulations. It can be associated with some physical effect(Majoron decay with n=7or second-forbidden corrections contribution[51],for example)or with our not ideal knowledge of the response function of the detector.To be conservative now we prefer to be in framework of the last assumption.The detection efficiencies for the decays depend on the energy of the electrons and were calculated for the two nuclei,for all the Majoron modes(spectral indices n=1,2,3and7)and for the double beta-decay(n=5)by a Monte-Carlo simulation with the GEANT3.21code.If the Majoron modes are considered as existing decay channels similar to 2β2ν,then the data contains the sum of two processes,2β2νdecay and the decay withχ0emission.Therefore it is not possible to know the expected number of2β2νdecays and so a limit must be set on the decays with Majoron emission by analyzing the deviation in the shape of the energy distribution of the experimental data in comparison with calculated spectrum for2β2νdecay.This can be done with a maximum likelihood analysis.The experimental spectrum was treated as a histogram.One then needs to take into account that the distribution of the events in each bin is a Poisson one and independent of the others.Thus,one constructs the likelihood function as:L(Nβ,Nχ)=n2i=n1e−(Nβηβi+Nχηχi+N bgr i)where n1and n2are the bin numbers of the energy interval,N exp i is the number of experimental events in the i-th bin,N bgr i is the expected number of background events,andηβi andηχi are the Monte-Carlo simulated efficiencies of2β2νand Majoron decays in the i-th bin.Finally,Nβand Nχ0are the average numbers of decays for2β2νand Majoran decay respectively,and are considered as free parameters.Tofind the confidence level for the upper limit on the mean number of decays with Majoron emission(Nχup)the likelihood function(3)has to be normalized and then integrated over all possible values of Nβand Nχfrom0to Nχup:CL(Nχup)=NχupdNχ∞dNβL(Nβ,Nχ)The summary of the best limits on the coupling constant of the Majoron to neutrinos for ordinary Majorons with n=1are presented in Table2.One of the problems is the uncertainty in the Nuclear Matrix Element(NME)calculations which lead to a dispersion of the g ee value.In the3rd column,limits obtained using QRPA(different models)NME from[27,28,29]are presented.Exceptions are48Ca where Shell Model calculations have been used[24,25]and150Nd for which NME values were taken from[26]where a Pseudo-SU(3)model taking into account the deformation of the150Nd nuclei was applied and from[27]were calculations in the framework of QRPA were done(though such an approach is not really correct for deformed nuclei).In the4th column of Table2,limits using the NME from[30]are shown where the RQRPA model was used.In this recent work the suppression effect of higher order terms of the nucleon current have been taken into account and the g pp values were extracted from2β2νexperiments.The authors analyzed practically all the previous QRPA and RQRPA calculations and concluded that their last calculations give the most reliable and accurate values for NME †.If this is indeed the correct approach to the determination of g pp then the best present limit is obtained from our measurements with82Se and100Mo: g ee <(1.2−1.9)·10−4and g ee <(1.6−1.8)·10−4respectively.If,however, the former approach is taken,and the NME values from[27,28,29]are used,the best limit is obtained from the measurement of100Mo: g ee <(0.4−0.7)·10−4. One can see from the Table2that new the approach leads to more conservative limits on the g ee coupling constant for all nuclei.All limits in Table2were obtained using phase space factors calculated in[54]. These values are∼20%lower than values obtained from[27]and the limits are therefore conservative and could be a further10%more sensitive.To summarize briefly all the experimental results and taking into account uncertainties in NME calculations,the conservative limit on g ee from double beta decay experiments(”ordinary”Majoron)is at the level<2·10−4.It is interesting to note that the Majoron-neutrino coupling constant in the range 4·10−7< g ee <0.2·10−4is excluded by the observation of SN1987A[4,7]. This means that the possible range2·10−5< g ee <2·10−4is still allowed in contrast to conclusions from[4,7]where an overly optimistic limit(<3·10−5) from double beta decay experiments was used.For”non-ordinary”Majoron models,our new limits on g ee are a few times better than reported in[39,40,34].Analysis of the results documented above shows that the best limits on the coupling constant for decays with Majoron emission(n=3)were obtained in the measurement of100Mo and for n=7in the measurement of82Se.For the decay with n=2limit on string scale M can be established at the level of M>1TeV(see[22]).6ConclusionImproved limits on different Majoron decay modes of100Mo and82Se have been obtained.The most stringent limits on the Majoron to neutrino coupling constants have been established.Data collection is continuing and the sen-sitivity of the NEMO3experiment will be increased in the nextfive years. In particular,we hope to improve our knowledge of detector response func-tion and clarify the situation with the low energy portion of100Mo spectrum. Of course,a much better sensitivity(∼10−5for”ordinary”Majoron)will be reached in the next generation double beta decay experiments(see,for example,review[53]).AcknowledgementThe authors would like to thank the Modane Underground Laboratory stafffor their technical assistance in running the experiment.Portions of this work were supported by a grant from INTAS(no03051-3431),a NATO grant(PST CLG 980022)and grant from Grant Agency of the Czech Republic(202/05/P239).————————————————————–References[1]V.Berezinsky and J.W.F.Valle,Phys.Lett.B318(1993)360.[2] A.D.Dolgov and F.Takahashi,Nucl.Phys.B688(2004)189.[3] D.Kazanas et al.,Phys.Rev.D70(2004)033015.[4]K.Kachelriess,R.Tomas and J.W.F.Valle,Phys.Rev.D62(2000)023004.[5]R.Tomas,H.Pas and J.W.F.Valle,Phys.Rev.D64(2001)095005.[6]S.Hannestad,P.Keranen and F.Sannino,Phys.Rev.D66(2002)045002.[7]Y.Farzan,Phys,Rev.D67(2003)073015.[8]Y.Chikashige,R.N.Mohapatra,R.D.Peccei,Phys.Rev.Lett.45(1980)1926;Phys.Lett.B98(1981)265.[9] C.Aulakh,R.Mohapatra,Phys.Lett.B119(1982)136.[10]G.Gelmini,M.Roncadelli,Phys.Lett.B99(1981)1411.[11]H.M.Georgi,S.L.Glashow,S.Nussinov,Nucl.Phys.B193(1981)297.[12]V.Barger et al.,Phys.Rev.D26(1982)218.[13]N.G.Deshpande,Proc.Conf.on Neutrino Masses and NeutrinoAstrophysics,ed.V.Barger et al.,(Singapore:World Scientific),1987,p.78.[14] C.Caso et al.(Particle Data Group),European Physical Journal C3(1998)1.[15]Z.G.Berezhiani,A.Yu.Smirnov,J.W.F.Valle,Phys.Lett.B291(1992)99.[16]R.N.Mohapatra,P.B.Pal.Massive Neutrinos in Physics andAstrophysics,(Singapore:World Scientific),1991.[17]R.N.Mohapatra,E.Takasugi,Phys.Lett.B211(1988)192.[18]J.C.Montero,C.A.de S.Pires and V.Pleitez,Phys.Rev.D64(2001)096001.[19] C.P.Burgess,J.M.Cline,Phys.Lett.B298(1993)141;Phys.Rev.D49(1994)5925.[20]P.Bamert,C.P.Burgess,R.N.Mohapatra,Nucl.Phys.B449(1995)25.[21] C.D.Carone,Phys.Lett.B308(1993)85.[22]R.N.Mohapatra,A.Perez-Lorenzana and C.A.de S.Pires,Phys.Lett.B491(2000)143.[23]M.Hirsch et al.,Phys.Lett.B372(1996)8.[24]J.Retamosa,E.Caurier and F.Nowacki,Phys.Rev.C51(1995)371.[25] E.Caurier et al.,Nucl.Phys.A654(1999)973c.[26]J.G.Hirsch,O.Castanos and P.O.Hess,Nucl.Phys.A582(1995)124.[27] F.Simkovic et al.,Phys.Rev.C60(1999)055502.[28]S.Stoica and H.V.Klapdor-Kleingrothaus,Nucl.Phys.A694(2001)269.[29]O.Civitarese and J.Suhonen,Nucl.Phys.A729(2003)867.[30]V.A.Rodin et al.,nucl-th/0503063.[31] A.S.Barabash,Phys.Lett.B216(1989)257.[32]H.V.Klapdor-Kleingrothaus et al.,Eur.Phys.J.A12(2001)147.[33]R.Arnold et al.,Nucl.Phys.A658(1999)299.[34] F.A.Danevich,Phys.Rev.C68(2003)035501.[35]O.K.Manuel,J.Phys.G17(1991)221.[36] C.Arnaboldi et al.,Phys.Lett.B557(2003)167.[37]R.Luescher et al.,Phys.Lett.B434(1998)407.[38] A.De Silva,M.K.Moe,M.A.Nelson,M.A.Vient,Phys.Rev.C56(1997)2451[39]M.Gunther et al.,Phys.Rev.D54(1996)3641;J.Helmig et al.,in:Proc.Int.Worksh.“Bouble beta decay and Related TOpics”,WorldScientific,1996,p.130.[40]R.Arnold et al.,Nucl.Phys.A678,(2000)141.[41]R.Arnold et al.,JETP Lett.80,(2004)377[42] A.Barabassh et NEMO collaboration,Nucl.Phys.B(Proc.Suppl.)138,(2005)207[43]X.Sarazin et NEMO collaboration,Nucl.Phys.B(Proc.Suppl.)143,(2005)221[44]NEMO-3Proposal,LAL preprint94-29(1994).[45]H.V.Klapdor-Kleingrothaus et al.,Eur.Phys.J.A12,(2001)147[46] C.E.Aalseth et al.,Phys.Rev.D65(2002)092007.[47]R.Arnold et al.,Nucl.Instr.Meth.A536,(2005)79.[48] F.Simkovic,P.Domin and S.Semenov,J.Phys.G27(2001)2233.[49]P.Domin et al.,et al.,Nucl.Phys.A753(2005)337.[50]R.Arnold et al.,Nucl.Phys.A636(1998)209.[51] C.Barbero et al.,Phys.Lett.B445(1999)249.[52]K.Fushimi et al.,Phys.Lett.B531(2002)190.[53] A.S.Barabash,Phys.At.Nucl.67(2004)438.[54]J.Suhonen and O.Civitarese,Phys.Rep.300(1998)123.[55] C.Barbero et al.,Phys.Lett.B392(1997)419.50100150200250050010001500200025003000 Energy, KeVd N /d EFig.1.Energy spectra of different modes of 2β2ν(n =5),2βχ0(n =1,2and 3)and 2βχ0χ0(n =3and 7)decays of100Mo.lator;3–low radioactivity PMT;4–tracking chamber.x8+X8Fig.3.A view of a reconstructed2e event in NEMO-3.The sum energy of the electrons is2024keV;the energies of the electrons in the pair are961keV and1063 keV.Mo-1001000200030004000500060007000E1+E2, keVE v e n t s / 51k e VSe-820255075100125150175200225E1+E2, keVE v e n t s / 99 k e VFig.4.The 2e events (points -experiment;solid lines -Monte Carlo simulations for 2β2νdecay)for100Moand82Se.Table1Different Majoron models according to[20,23].The mode IIF and”bulk“correspond to the model[21]and[22]respectively.IB2βχ0no01M F−M GTIC2βχ0yes01M F−M GTID2βχ0χ0no03M Fω2−M GTω2IE2βχ0χ0yes03M Fω2−M GTω2IIB2βχ0no-21M F−M GTIIC2βχ0yes-23M CRIID2βχ0χ0no-13M Fω2−M GTω2IIE2βχ0χ0yes-17M Fω2−M GTω2IIF2βχ0gauge boson-23M CRSummary of the best results on the2βχ0decay with n=1.All limits are presented at the90%CL.The dispersion of g ee values is due to uncertainties in the NME calculation.The NME from the following works were used,3rd column:48Ca-[24,25],150Nd-[27,26],and others-[27,28,29];4th column:[30].48Ca>7.2·1020[31]<1276Ge>6.4·1022[32]<(1.2−3.0)<(1.9−2.3)82Se>1.5·1022<(0.66−1.4)<(1.2−1.9)(this work)96Zr>3.5·1020[33]<(3.6−10)<(35−378)100Mo>2.7·1022<(0.4−0.7)<(1.7−1.8)(this work)116Cd>8·1021[34]<(1.0−2.0)<(2.8−3.3)128Te>2·1024(geochemical)[35]<(0.7−1.6)<(1.9−2.4)130Te>3.1·1021[36]<(1.5−4.1)<(4.7−5.7)136Xe>7.2·1021[37]<(1.0−7.4)<(5.1−6.6)150Ne>2.8·1020[38]<(2.5−5.5)<(3.8−4.8)Limits on T1/2at90%CL for decays with Majoron emission,estimated with like-lihood function.100Mo82Se>5.8·1021[52]>2.4·1021[40] n=2>1.7·1022>6.0·10211.6·1020[40]6.3·1020[40]n=7>7·1019>5.0·1020The QRPA nuclear matrix elements for100Mo and82Se.82Se 2.63-5.60[27,28,29]0.14-0.44[39,55]10−3[39]100Mo 2.97-5.37[27,28,29]0.16-0.44[39,55]10−3[39]Phase-space integrals(G[y−1])for different nuclei and models of decay(from[54] for n=1and from[39]for n=3,7.)82Se4.84·10−163.49·10−181.01·10−177.73·10−17100Mo8.23·10−167.28·10−181.85·10−171.54·10−16Limits on the Majoron coupling constant g ee at the90%CL for100Mo and82Se.IB2βχ01(0.66−1.7)·10−4(0.4−1.8)·10−4IC2βχ01(0.66−1.7)·10−4(0.4−1.8)·10−4IIB2βχ01(0.66−1.7)·10−4(0.4−1.8)·10−4IIE2βχ0χ07 1.3 3.2。