Categories and Subject DescriptorsD

Categories and Subject Descriptors
D.4.0 [Operating Systems]: General
General Terms
Design, Documentation, Reliability, Standardization
A sensor network operating system has to be efficient, flexible,
and reliable. Energy contraints mean that nodes not only have limited
resources, but they must use those resources sparingly. As deployments
are application domain specific, a flexible OS lets software
make the most of these limited resources in order to meet that
applications requirements without inefficiencies introduced by generality.
Finally, in order for deployments to last unattended for long
periods of time, the underlying OS must be stable and reliable.
The past five years have seen tremendous research and technological
developments in wireless sensor networks. The TinyOS operating
system has been able to adapt and grow with this progress.
However, five years of experience have shown that some of its
structure and abstractions to be problematic. The huge existing
TinyOS codebase means that changing basic aspects of the OS
would break all of this existing work.
This has led us to develop TinyOS 2.0, a second-generation mote
operating system. TinyOS 2.0 keeps many of the basic ideas in
TinyOS 1.x: it is a component-based operating system written in
the nesC language [1]. However, it is a clean-slate rewrite of the entire
OS. Every major subystem has a corresponding TEP (TinyOS
Enhancement Proposal) document, which describes the design and
structure of the subsystem and documents a sample implementation.
TEPs are open to review and comment from the larger community.
As having a broad base of experience is important to guide
design and implementations, the TinyOS 2.0 Working Group (WG)
includes developers from UC Berkeley, TU Berlin, Stanford, UCLA,
Crossbow, Moteiv, Arched Rock and Intel.
TinyOS 2.0 pushes forward in three key areas: greater platform
flexibility, improved robustness and reliability, and the concept of
service distributions. The first is intended to simplify platform development
and interoperability, the second is a general design goal,
and the last simplifies application development.
TinyOS 2.0 supports greater platform flexibility in two ways.
First, it introduces a three-layer Hardware Abstraction Architecture
(HAA) [2]. The bottom layer is the Hardware Presentation Layer
(HPL), which provides access to basic resources, such as registers,
interrupts, and pins, through nesC interfaces. The middle layer is
the Hardware Abstraction Layer (HAL), which has higher-level interfaces
that provide useful abstractions of the full capabilities of
the underlying hardware. The top layer is the Hardware Independent
Layer (HIL), which presents abstractions that are hardware
independent and therefore cross-platform.
Second, TinyOS 2.0 uses version 1.2 of the nesC language, which
has new features to better support cross-platform networking. nesC
Copyright is held by the author/owner.
SenSys’05, November 2–4, 2005, San Diego, California, USA.
ACM 1-59593-054-X/05/0011.
1.2 introduces the notion of a network type at a language level: programs
can declare structs and primitive types that follow a crossplatform
(1-byte aligned, big-endian) layout and encoding. This
allows services to declare cross-platform packet formats without
resorting to macros or explicit marshaling/unmarshaling. Experimental
data shows that the overhead of this encoding is negligible.
TinyOS 2.0 improves system reliability and robustness by redefining
some of the basic TinyOS abstraction and policies, such as
initialization, the task queue, and power management. For example,
in TinyOS 1.x, all components share a fixed-size task queue,
and a given task can be posted multiple times [3]. This causes a
wide range of robustness problems, as if a component is unable to
post a task due the queue being full, it may cause the system to
hang. In TinyOS 2.0, every task has its own reserved slot in the
queue, and can be only posted once. Our initial experiences have
shown these semantics to greatly simplify code and lead to more
robust components.
Finally, TinyOS 2.0 introduces the notion of service distributions.
A service distribution is a collection of services whose underlying
components have been designed and composed to work
well together. A service distribution is essentially a system API.
Because the services are designed to work together as a whole,
users do not have to worry about initialization order, configuration,
or the details of the underlying implementations. Service distributions
also introduce power management policies on top of the
basic OS mechanisms. As a whole, they introduce a seperation of
concerns between low-level systems and applications, simplifying
application development. TinyOS 2.0 supports service distributions
by defining simple OS mechansims and interfaces that can be reused
in many fashions, and through new nesC features: a service i

ผลลัพธ์ (ไทย) 1:

ประเภทและตัวแสดงรายละเอียดของเรื่องD.4.0 [ระบบปฏิบัติการ]: ทั่วไปข้อกำหนดทั่วไปออกแบบ เอกสาร ความน่าเชื่อถือ มาตรฐานระบบปฏิบัติการเครือข่ายเซ็นเซอร์จะต้องมีประสิทธิภาพ คล่อง ตัว มีและเชื่อถือได้ พลังงาน contraints หมายถึง ว่า โหนดที่ไม่มีจำกัดทรัพยากร แต่พวกเขาต้องใช้ทรัพยากรเหล่านั้นเท่าที่จำเป็น เป็นการใช้งานโดเมนโปรแกรมประยุกต์เฉพาะ ระบบปฏิบัติการมีความยืดหยุ่นช่วยให้ซอฟต์แวร์ทำให้ทรัพยากรเหล่านี้จำกัดมากสุดเพื่อตอบสนองที่ความต้องการใช้งานโดยไม่นำมาใช้ โดยทั่วไปใจในที่สุด ในใบสั่งสำหรับการปรับใช้ล่าสุดไม่นานรอบระยะเวลา ระบบปฏิบัติการต้นแบบต้องมีเสถียรภาพ และเชื่อถือผ่านมาห้าปีได้เห็นวิจัยมหาศาล และเทคโนโลยีพัฒนาในเครือข่ายเซนเซอร์ไร้สาย TinyOS ดำเนินงานระบบได้สามารถปรับตัว และเติบโตไปกับความคืบหน้าอย่างไรก็ตาม ประสบการณ์ห้าปีได้แสดงให้เห็นว่าบางส่วนของมันโครงสร้างและ abstractions จะมีปัญหา ที่มีอยู่มากTinyOS codebase หมายความ ว่า การเปลี่ยนแปลงลักษณะพื้นฐานของระบบปฏิบัติการจะทำลายทั้งหมดของงานนี้อยู่ได้นำมาพัฒนา TinyOS 2.0 มลทินเป็นรุ่นที่สองระบบปฏิบัติการ TinyOS 2.0 เก็บของพื้นฐานในTinyOS 1.x: เป็นระบบปฏิบัติการคอมโพเนนต์เขียนในnesC ภาษา [1] อย่างไรก็ตาม มันเป็นการเขียนกระดานชนวนสะอาดของทั้งหมดระบบปฏิบัติการ Subystem ทุกหลักมี TEP สอดคล้องกัน (TinyOSเอกสารข้อเสนอเพิ่ม) ซึ่งอธิบายถึงการออกแบบ และโครงสร้างของระบบย่อย และเอกสารการดำเนินการอย่างนี้TEPs จะเปิด และแสดงความคิดเห็นจากชุมชนใหญ่มี ฐานกว้างของประสบการณ์เป็นสิ่งสำคัญเพื่อเป็นแนวทางออกแบบและใช้งาน การ TinyOS 2.0 ทำงานกลุ่ม (WG)มีนักพัฒนาจาก UC Berkeley เบอร์ลิน TU สแตนฟอร์ด UCLAหน้าไม้ Moteiv หินโค้ง และ IntelTinyOS 2.0 ผลักไปข้างหน้าสำคัญของประเทศ: แพลตฟอร์มมากขึ้นมีความยืดหยุ่น ปรับปรุงเสถียรภาพ และความน่าเชื่อถือ และแนวคิดของการกระจายบริการ ครั้งแรกมีวัตถุประสงค์เพื่อพัฒนาแพลตฟอร์มให้ง่ายขึ้นและทำงานร่วม กัน ที่สองคือ เป้าหมายออกแบบทั่วไปและสุดท้ายทำให้การพัฒนาโปรแกรมประยุกต์TinyOS 2.0 สนับสนุนแพลตฟอร์มอิสระในสองวิธีครั้งแรก มันนำเสนอสถาปัตยกรรม Abstraction ฮาร์ดแวร์แบบสามชั้น(ฮา) [2] . ชั้นล่างสุดเป็นชั้นการ นำเสนอ ฮาร์ดแวร์(HPL), ซึ่งช่วยให้เข้าถึงทรัพยากรพื้นฐาน เช่นลงทะเบียนinterrupts และหมุด ผ่านอินเทอร์เฟซ nesC ชั้นกลางคือการฮาร์ดแวร์ Abstraction Layer (HAL), ซึ่งมีอินเทอร์เฟซที่สูงกว่าที่ให้ abstractions ที่มีประโยชน์เต็มความสามารถของฮาร์ดแวร์พื้นฐาน ชั้นบนสุดเป็นฮาร์ดแวร์อิสระชั้น (HIL), ซึ่งนำเสนอ abstractions ที่เป็นฮาร์ดแวร์อิสระ และดังข้ามแพลตฟอร์มที่สอง TinyOS 2.0 ใช้รุ่น 1.2 ภาษา nesC ซึ่งมีคุณสมบัติใหม่เพื่อให้ รองรับระบบเครือข่ายข้ามแพลตฟอร์ม nesCถือลิขสิทธิ์ โดยผู้เขียนหรือเจ้าของSenSys'05, 2 – 4 พฤศจิกายน 2005 ซานดิเอโก แคลิฟอร์เนีย สหรัฐอเมริกาACM 1-59593-054-X/05/00111.2 แนะนำความคิดของชนิดเครือข่ายในระดับภาษา: โปรแกรมสามารถประกาศ structs และชนิดดั้งเดิมที่ทำตาม crossplatformเค้าโครง (1 ไบต์ชิด ใหญ่ endian) และการเข้ารหัส นี้ให้บริการการประกาศรูปแบบแพ็คเก็ตข้ามแพลตฟอร์มโดยไม่ต้องresorting การแมโครหรือชัดเจน marshaling/unmarshaling ทดลองข้อมูลแสดงให้เห็นว่า ค่าโสหุ้ยของการเข้ารหัสนี้เป็นเล็กน้อยTinyOS 2.0 ปรับปรุงระบบความน่าเชื่อถือและความทนทาน โดยนิยามบางส่วนของพื้นฐาน TinyOS abstraction และนโยบาย เช่นการเริ่มต้น คิวงาน และการจัดการพลังงาน ตัวอย่างเช่นใน TinyOS 1.x ทั้งหมดส่วนประกอบแบ่งเป็นขนาดงานคิวและงานกำหนดให้สามารถโพสต์หลายครั้ง [3] ทำให้การหลากหลายปัญหาเสถียรภาพ ว่าคอมโพเนนต์ไม่สามารถลงรายการบัญชีงานกำหนดคิวจะเต็ม มันอาจทำให้ระบบแขวน ใน TinyOS 2.0 ทุกภารกิจมีช่องสำรองคิว และสามารถจะลงรายการบัญชีเฉพาะหนึ่งครั้ง มีประสบการณ์ครั้งแรกของเราแสดงความหมายเหล่านี้เพื่อช่วยลดความซับซ้อนของรหัส และนำไปเพิ่มเติมส่วนประกอบที่แข็งแกร่งในที่สุด TinyOS 2.0 แนะนำความคิดของการกระจายบริการการกระจายบริการคือชุดของบริการ ที่มีพื้นฐานคอมโพเนนต์ถูกออกแบบ และประกอบด้วยการทำงานกัน การกระจายบริการเป็นหลักระบบ APIเนื่องจากบริการถูกออกแบบให้ทำงานร่วมกันทั้งหมดผู้ใช้ไม่ต้องกังวลเกี่ยวกับลำดับการเตรียมใช้งาน กำหนดค่าหรือรายละเอียดของการใช้งานพื้นฐาน การกระจายบริการยัง ได้แนะนำนโยบายการจัดการพลังงานจากการกลไกพื้นฐานใน OS ทั้งหมด แนะนำบัติการของความกังวลระหว่างระบบระดับต่ำและการใช้งาน ลดความซับซ้อนการพัฒนาโปรแกรมประยุกต์ TinyOS 2.0 รองรับการกระจายบริการโดยการกำหนด mechansims OS ง่ายและอินเทอร์เฟซที่สามารถนำมาในแฟชั่นมากมาย และ ผ่านคุณสมบัติใหม่ ๆ ของ nesC: การบริการผม

ผลลัพธ์ (ไทย) 2:

ประเภทและอธิบายเรื่อง
D.4.0 [ระบบปฏิบัติการ]: ทั่วไป
เงื่อนไขทั่วไป
ออกแบบเอกสาร, ความน่าเชื่อถือมาตรฐาน
เซ็นเซอร์ระบบปฏิบัติการเครือข่ายจะต้องมีประสิทธิภาพและมีความยืดหยุ่น
และเชื่อถือได้ contraints พลังงานหมายความว่าโหนดไม่เพียง แต่ได้รับการ จำกัด
ทรัพยากร แต่พวกเขาต้องใช้ทรัพยากรเหล่านั้นเท่าที่จำเป็น ขณะที่การใช้งานที่
มีประสิทธิภาพโปรแกรมเฉพาะที่มีความยืดหยุ่น OS ช่วยให้ซอฟแวร์
ให้มากที่สุดของทรัพยากรที่มี จำกัด เหล่านี้เพื่อตอบสนองความต้องการที่
ต้องการการใช้งานโดยไม่ต้องไร้ประสิทธิภาพที่รู้จักโดยทั่วไป.
สุดท้ายในการสั่งซื้อสำหรับการใช้งานให้มีอายุการใช้ไม่ต้องใส่นาน
ช่วงเวลา, OS พื้นฐาน จะต้องมีเสถียรภาพและเชื่อถือได้.
ที่ผ่านมาห้าปีได้เห็นการวิจัยอันยิ่งใหญ่และเทคโนโลยี
การพัฒนาในเครือข่ายเซ็นเซอร์ไร้สาย ปฏิบัติการ TinyOS
ระบบได้รับสามารถที่จะปรับตัวและเติบโตไปพร้อมกับความคืบหน้านี้.
แต่ห้าปีของประสบการณ์ได้แสดงให้เห็นว่าบางส่วนของ
โครงสร้างและนามธรรมจะเป็นปัญหา ขนาดใหญ่ที่มีอยู่
TinyOS codebase หมายความว่าการเปลี่ยนแปลงด้านพื้นฐานของ OS
จะทำลายทั้งหมดของการทำงานที่มีอยู่นี้.
นี้ได้นำเราในการพัฒนา TinyOS 2.0 เป็นรุ่นที่สอง Mote
ระบบปฏิบัติการ TinyOS 2.0 ช่วยให้หลายความคิดพื้นฐานในการ
TinyOS 1.x: มันเป็นระบบปฏิบัติการที่เป็นส่วนประกอบตามที่เขียนใน
ภาษา nesC [1] แต่ก็เป็นเขียนสะอาดกระดานชนวนของทั้ง
OS ทุก subystem ที่สำคัญมี TEP ที่สอดคล้องกัน (TinyOS
การเพิ่มประสิทธิภาพของการเสนอ) เอกสารซึ่งอธิบายการออกแบบและ
โครงสร้างของระบบย่อยและเอกสารการดำเนินงานตัวอย่าง.
Teps จะเปิดให้ตรวจสอบและแสดงความคิดเห็นจากชุมชนขนาดใหญ่.
มีฐานกว้างของประสบการณ์เป็นสิ่งสำคัญ เพื่อเป็นแนวทางใน
การออกแบบและการใช้งาน TinyOS 2.0 คณะทำงาน (WG)
รวมถึงนักพัฒนาจาก UC Berkeley, TU เบอร์ลิน, Stanford, UCLA,
หน้าไม้ Moteiv โค้งร็อคและ Intel.
TinyOS 2.0 ผลักดันไปข้างหน้าในสามประเด็นสำคัญ: แพลตฟอร์มมากขึ้น
มีความยืดหยุ่นดีขึ้น ความทนทานและความน่าเชื่อถือและแนวคิดของ
การกระจายบริการ เป็นครั้งแรกที่มีจุดมุ่งหมายเพื่อลดความซับซ้อนในการพัฒนาแพลตฟอร์ม
และการทำงานร่วมกันสองคือเป้าหมายการออกแบบทั่วไป
และสุดท้ายช่วยลดความยุ่งยากการพัฒนาโปรแกรมประยุกต์.
TinyOS 2.0 รองรับความยืดหยุ่นแพลตฟอร์มมากขึ้นในสองวิธี.
แรกก็แนะนำสามชั้นฮาร์ดแวร์ Abstraction สถาปัตยกรรม
(HAA) [2] ชั้นล่างเป็นอุปกรณ์การนำเสนอชั้น
(HPL) ซึ่งมีการเข้าถึงทรัพยากรพื้นฐานเช่นการลงทะเบียน,
การขัดจังหวะและหมุดผ่านอินเตอร์เฟซ nesC ชั้นกลางเป็น
ฮาร์ดแวร์ Abstraction Layer (HAL) ซึ่งมีการเชื่อมต่อในระดับสูง
ที่ให้แนวคิดที่มีประโยชน์จากความสามารถเต็มรูปแบบของ
ฮาร์ดแวร์พื้นฐาน ชั้นบนเป็นฮาร์ดแวร์อิสระ
Layer (HIL) ซึ่งนำเสนอแนวคิดที่มีฮาร์ดแวร์
ที่เป็นอิสระและดังนั้นจึงข้ามแพลตฟอร์ม.
สอง TinyOS 2.0 ใช้รุ่น 1.2 ของภาษา nesC ซึ่ง
มีคุณสมบัติใหม่ที่ให้การสนับสนุนที่ดีกว่าเครือข่ายข้ามแพลตฟอร์ม nesC
ลิขสิทธิ์ที่จัดขึ้นโดยผู้เขียน / เจ้าของ.
SenSys'05, 2-4 พฤศจิกายน 2005, San Diego, California, USA.
ACM 1-59593-054-X / 05/0011.
1.2 แนะนำความคิดของประเภทเครือข่ายที่ ระดับภาษา: โปรแกรม
สามารถประกาศ structs และรูปแบบดั้งเดิมที่เป็นไปตาม crossplatform
(1 ไบต์ชิด big-) รูปแบบและการเข้ารหัส นี้
จะช่วยให้การบริการในการประกาศรูปแบบแพ็คเก็ตข้ามแพลตฟอร์มโดยไม่ต้อง
หันไปแมโครหรืออย่างชัดเจนเรียบเรียง / unmarshaling ทดลอง
ข้อมูลแสดงให้เห็นว่าค่าใช้จ่ายของการเข้ารหัสนี้เป็นเล็กน้อย.
TinyOS 2.0 เพิ่มความน่าเชื่อถือและความทนทานของระบบโดยกําหนด
บางส่วนของนามธรรมและนโยบายเช่น TinyOS พื้นฐาน
เริ่มต้นคิวงานและการจัดการพลังงาน ยกตัวอย่างเช่น
ใน TinyOS 1.x ทุกองค์ประกอบแบ่งปันคิวงานคงที่ขนาด
และเป็นงานที่ได้รับสามารถโพสต์หลายครั้ง [3] นี้ทำให้เกิด
ความหลากหลายของปัญหาความทนทานเช่นถ้าเป็นส่วนประกอบที่ไม่สามารถที่จะ
โพสต์งานเนื่องจากคิวถูกเต็มก็อาจก่อให้เกิดระบบที่จะ
แขวน ใน TinyOS 2.0 งานทุกคนมีช่องเสียบลิขสิทธิ์ของตัวเองใน
คิวและสามารถโพสต์ได้เพียงครั้งเดียว ประสบการณ์ครั้งแรกของเราได้
แสดงให้เห็นความหมายเหล่านี้เพื่อช่วยลดความซับซ้อนรหัสและนำไปสู่การเพิ่มเติม
องค์ประกอบที่แข็งแกร่ง.
สุดท้าย TinyOS 2.0 แนะนำความคิดของการกระจายบริการ.
กระจายบริการเป็นคอลเลกชันของการให้บริการที่มีพื้นฐาน
ส่วนประกอบได้รับการออกแบบและประกอบในการทำงาน
ร่วมกันได้ดี กระจายการบริการเป็นหลักระบบ API.
เพราะบริการที่ถูกออกแบบมาเพื่อการทำงานร่วมกันเป็นทั้ง
ผู้ใช้ไม่ต้องกังวลเกี่ยวกับการสั่งซื้อเริ่มต้นการตั้งค่า
หรือรายละเอียดของการใช้งานพื้นฐาน การกระจายบริการ
นอกจากนี้ยังนำเสนอนโยบายการจัดการพลังงานที่ด้านบนของ
กลไกระบบปฏิบัติการพื้นฐาน เป็นทั้งที่พวกเขาแนะนำแยกของ
ความกังวลระหว่างระบบในระดับต่ำและการใช้งานง่าย
การพัฒนาโปรแกรมประยุกต์ TinyOS 2.0 รองรับการกระจายบริการ
ด้วยการกำหนด mechansims OS ง่ายและอินเตอร์เฟซที่สามารถนำกลับมาใช้
ในแฟชั่นจำนวนมากและผ่าน nesC ใหม่ที่มีคุณสมบัติ: บริการฉัน