6 Development of Plug-N-Play (Flight) Control Systems for Responsive Spacecraft

Development of Plug-N-Play (Flight)Control Systems for

Responsive Spacecraft

Constantine D.Orogo *and Michael Enoch ?and Donald L.Flaggs ?

Lockheed Martin Advanced Technology Center (ATC),Palo Alto,CA,94304

[Abstract]The Operationally Responsive Space (ORS)program envisions building a "6-

day spacecraft"to support fast changing tactical missions.A key requirement would be the

ability to rapidly compose the spacecraft that would perform both the needed mission-and

spacecraft-oriented functionality using "Plug-N-Play"(PnP)enabled spacecraft

components.To address this need,a service-oriented spacecraft architectural model is

under development as part of the Air Force Research Laboratory (AFRL)Responsive Space

Testbed effort to provide a reusable,reference infrastructure for Responsive Space.The

Lockheed Martin ATC is pursuing the development of a Java-based distributed architecture

environment that supports this service-oriented,reference spacecraft architectural model.A

key component of this approach involves a simulation architecture that is based on

spacecraft services,much like the service-oriented models now widely used in the consumer

marketplace,but is an evolutionary step to extend simulation to operations.To span the

entire range from simulation to operations seamlessly,a single vertically integrated software

architecture is needed.The Java-based distributed architecture provides such an

environment with its evolution from desktop,to enterprise,to mobile devices,and now to

real time systems.The Java environment addresses the complexity needed for operational

simulations and ultimate deployment for integrated spacecraft flight and payload control

systems.The Real Time Specification for Java (RTSJ)supports hard real time,soft real

time and non-real time processes all interoperating within the same virtual machine.Initial

prototyping is being done using IBM's Real Time Java (RTJ)implementation of the RTSJ.

The Java platform support several libraries,and one in particular,the JINI protocol,which

supports the operation of dynamically changing networks of distributed services (and

devices).Using JINI,running as a non-real time process within IBM's RTJ environment,

provides the rich set of Plug-N-Play capabilities needed to demonstrate both automatic

configuration,as would be needed for Assembly,Integration and Test (AI&T),as well as for

operational fault tolerance and reconfigurability needed for on-orbit operations.

I.Architecture Model

Lockheed Martin has proposed the layered reference architecture model shown in Figure 1to the AFRL Plug and Play (PnP)community,as a framework for the architecture implementation.

*

Staff Software Engineer,Department ABCS,B153,1111Lockheed Way,Sunnyvale,CA,94089.

?Senior Staff Systems Engineer,Department AFBR,1155University Blvd.,SE Room W227Albuquerque,NM,87106.?Program Manager,Department ABCS,B153,1111Lockheed Way,Sunnyvale,CA,94089.Space 200619-21 September 2006, San Jose, California AIAA 2006-7243

https://www.sodocs.net/doc/6f7883624.html,yered Spacecraft Architecture Model

In its preliminary incarnation,this model is being used in our PnP implementation.The characteristics of each layer are defined below.

?Mission Layer-Addresses the systems implemented by an enterprise to achieve some specific purpose.

Mission layer interface supports end user interaction with the system without requiring the end users to

know the internal details of the system.

?Function Layer-Addresses the functions or processes needed by the mission system(s)to achieve the goals of the mission(enterprise).

?Application Layer-Addresses the activities performed by logical components in the system to address the functional needs of the mission system.

?Services Layer-Addresses the activities or resources required by a set of applications to address the needs of the mission system applications.

?Protocol Layer-Addresses the methods and formats for data exchange between applications and services within the mission system.

?Device Layer-Addresses the need to provide a set of physical units to provide and support the upper layers of the model.

The abstractions associated with and the interfaces between layers are illustrated in the following simple intelligence,surveillance,and reconnaissance(ISR)scenario.

An end user(warfighter)may want a data product,such as annotated imagery,of a specific geographic location collected between specific time intervals.

Then,several functions are performed to address the end user request.They are:Planning,Execution and Production.The Planning function or process determines if and when a spacecraft will be able to service the request.The Execution function or process performs the activities to collect the requested data(according to the directives from the planning function).The Production function or process performs operations on the collected data to generate the requested data product and deliver it to the end user.

In each of the example functions identified above,one or more software application packages are required to perform the activities.1)For the planning function,an orbit analysis application is needed to determine visibility to the target.A scheduling application may be needed to determine the temporal sequencing of actions to collect the data,especially in the case where there are multiple and conflicting https://www.sodocs.net/doc/6f7883624.html,stly,a command generation application may be needed to generate the actual spacecraft command data for execution of the tasking.2)For the execution function,one or more flight software application programs may be running on the spacecraft avionics to operate the spacecraft and payload.3)And finally for the production function,one or more software applications may be needed to perform data reconstruction,image processing,analysis,data fusion and formatting to produce the specific data product requested by the user,such as annotated imagery.Note that functions and applications are location independent.While planning and production are commonly performed in ground systems today,there is nothing that prevents these functions being relocated to the spacecraft.Direct tactical tasking is a desired capability for ORS and may not be achievable unless some function capabilities are available on the spacecraft.

Services are considered more general elements than applications in the Application layer,where provide higher order functionality and decision logic is expected to reside.In the examples provided,all the application have similar algorithmic needs for orbit propagation,time related functions,and coordinate system transformations.In order for the space system to service the ISR request,it is necessary for the spacecraft to point the payload in a specific direction at a specific time,a capability provided by attitude determination and control services.When the payload collects the image data,it can be expected that the data collection will be tagged with the time,the location of the spacecraft,the orientation of the spacecraft and other ancillary data that may be needed for data processing,all provided by different service providers available within the space system architecture.The collected data will need to be stored,presumably in some form of file system,for retrieval,processing,compression and transmission, provided by the appropriate service providers.

It is crucial that there are well-defined,consistent and unambiguous definitions of the inputs,outputs and behavior of the services in order for them to communicate and provide the correct functionality,given the inter-dependency of the services in performing the operations necessary for the space system to function,and the likelihood that services may be developed and provided by many different organizations.The protocol layer provides the abstraction layer and mechanism to address this need.The XML Tranducer Electronic Data Sheet (XTEDS)described later in this paper is one example of a protocol layer element that uses XML and takes advantage of the metadata definition mechanism provided in XML via XSD schemas to allow services to describe their interfaces and provide a mechanism to validate and enforce adherence to those interfaces within the system. This can allow different services developed by different suppliers to interact at AI&T without the need to develop custom Interface Control Documents(ICDs),a crucial element to enable Plug and Play.

In all cases,a service will require a physical device to host it,and in many cases,provide the actual mechanism for provision of the service.For example,the attitude determination and control services will require sensors,such as a star tracker,a sun sensor or an inertial measurement unit,as data provider service to support the determination and control algorithm services,hosted on processors,which support the attitude actuators,such as reaction wheels or thrusters,to point the spacecraft in the appropriate direction to allow the payload to collect the desired data.

Shown below in Figure2is a notional mapping of space systems high-level elements to layers in the reference architecture model.Three mission types are described(ISR,Communications,Navigation),with different lower layer implementations in the application layer.However,different services are available to the application code. Lastly,multiple devices are associated with the services.

II.The AFRL's Space Plug and Play Avionics(SPA)Architecture After the basic layered spacecraft model is described above,the role of the SPA architecture being pursued by the Electronics and Protection Branch of the Air Force Research Laboratory Space Vehicles Directorate(VSSE)can now be put in context.Their SPA architecture consists of four components:

1.Plug and Play Physical Layer Interfaces:SPA-U,SPA-S,SPA-E

2.Satellite Data Model(SDM)

3.SPA XML Transducer Electronic Data Sheet(XTEDS)

https://www.sodocs.net/doc/6f7883624.html,mon Data Dictionary(CDD)

The SPA-U1,2,SPA-S3and SPA-E provide a physical mechanism for connecting spacecraft components together.SPA-U is a modified version of the Universal Serial Bus(USB)standard found in personal computers. This interface is envisioned as the primary interconnect interface to management and control of devices within the spacecraft.AFRL has developed an AppliquéSensor Interface Module(ASIM)4as circuit module that can be embedded in spacecraft components to provide the SPA-U interface.SPA-S is a version of SpaceWire intended to provide a high speed interconnect for routing data between spacecraft components,such as from a payload to a processor and/or data storage device.The SPA-E is to be a modified version of Ethernet,but development has lagged behind the SPA-U and SPA-S efforts.

While SPA-U and SPA-S may provide the"plug",a standard and simplified method to interconnect spacecraft components,this is only a preliminary to getting to a functional space system,i.e.,the"play".There is still the need for devices to be able to communicate and function together in an integrated fashion to provide the functions and services needed for a working spacecraft able to perform specific missions.

Satellite Data Model

The Satellite Data Model(SDM)5,6was conceived to provide a unified plug&play mechanism for applications to coordinate,share data,and resources,and provide resources and services without requiring a priori knowledge of the physical location,properties and messaging structure of the spacecraft components.The SDM provides an infrastructure for the higher level spacecraft flight software applications that provides the mission functionality and should allows these applications to be developed in a"generic"manner with the expectation of specific services

available on the spacecraft at a level of abstraction that does not require specific knowledge of the components used to provide those services.

The SDM system consists of four modules plus any number of applications and devices on the spacecraft.The four modules are:

1.Data Manager(DM)-The Data Manager module of the SDM system is responsible for maintaining

information about available data sources and services.

2.Sensor Manager(SM)-The Sensor Manager module of the SDM system is responsible for handling

communications between the SDM system including applications and physical sensors.There can be

any number of SM modules running.

3.Task Manager(TM)-The Task Manager module of the SDM system is responsible for scheduling the

tasks to be run throughout the SDM system.It is also responsible for maintaining the SDM file system.

4.Process Manager(PM)-The Process Manager is responsible for executing tasks in the SDM system.

When idle it requests a task from the TM module and if necessary the code to execute.

This division into modules is transparent to the application.The application communicates with the SDM system through the provided SDM message classes and generic routines.

Electronic Data Sheet

The information needs and data associated with the spacecraft components can vary greatly from one type of component to another,such as a star tracker and magnetometer or between different manufacturers implementation of a component,such as reaction wheels from two different vendors.As such,it would be more advantageous to provide a standardized meta-data mechanism for each component to describe itself rather than try to enforce a standard protocol or format which would ultimately be limiting with regard to adding new components and capabilities without having to extend the standard,and create potential issues with concurrency and back compatibility between devices.

The XML Transducer Electronic Data Sheet(XTEDS)was conceived as a way of providing this capability.The XTEDS provides a XML description of the characteristics of spacecraft hardware and software components.When a device or application is added to the SPA network,it registers itself(its XTEDS information)with SDM Data Manager to announce its presence and its capabilities to provide data and services to other applications.The device or application can also query the SDM for registered XTEDS information and to request data messages from these other processes and devices.

Common Data Dictionary

The last element of the SPA architecture is the Common Data Dictionary(CDD)7.The CDD defines the semantics or contextual meaning of the elements in the SDM and XTEDS to that actual inter-operability and information sharing is possible.

As an example,suppose an application needs to know the spacecraft State Vector,e.g.,orbit position and velocity of the spacecraft at a specific time,to perform a necessary function,such as orbit determination.The CDD defines the information content of the state vector to include the position vector and velocity vector in Cartesian coordinates(X,Y,Z)in meters per second in the Earth Centered Inertial(ECI)J2000coordinate frame.Therefore, any application that needs state vector data can expect to receive it in this defined format,and any application that provides a state vector generation service needs to provide the information defined in the state vector format.When and where possible,the elements in the CDD are defined in accordance existing standards from the IEEE,AIAA, and ISO.

There are several existing COTS software architectures that could serve as the starting point for the SDM implementation.Two specific examples are CORBA8and JINI9.Both architectures are being used at the Lockheed Martin ATC to develop next generation distributed architectures for future space systems.The remainder of this paper focuses on the development of a Java-based reference SDM implementation using the JINI API that interoperates with the other components of the SPA architecture.

III.Java for Real Time Flight Software

The development of flight software is complex,unforgiving of programming errors and must run in an extremely resource-constrained environment.Accordingly,it has historically been tailored for each spacecraft with very little reuse between Programs and missions.However,new developments in software help reduce the complexity.

SUN Microsystems created Java as a development language for network appliances that would overcome all the problems of existing compiled languages,such as C/C++.Since then,it has evolved to span the entire development space from truly Enterprise applications with J2EE,to the desktop with J2SE,to resource-constrained mobile devices with J2ME and now,to real time applications with RTSJ(Real Time Specification for Java).One significant difference in this environment from other real time ones is the ability to mix hard real time(HRT),soft real time(SRT)and non real time(NRT)processes all within the same Java Virtual Machine(JVM).The Real Time Specification for Java(RTSJ)10defines extensions to the Java language in order to support real time systems. These include real time threads and improved garbage collection,which for some implementations such as IBM's RTJ,actually support real time garbage collection.

Figure3.Software programming model for SPA based Plug-n-play

Plug and Play(PnP)of Spacecraft Networked Devices

Plug and play entails the ability to connect varied electronic components and devices and automatically make them function in the distributed environment in their intended way without the need for any explicit configuration during operation.This paper assumes devices on the spacecraft are network-aware.They have Ethernet-based networking capability by supporting TCP/IP,be it via copper,optical or802.11Wifi.

Making devices network-aware by itself is not sufficient to enable PnP of components with remote services,nor in our context are the popular"PnP"USB devices truly PnP since they represent passive resources only known to the local USB controller into which they are plugged.

PnP refers to the capability of a networked device to actively participate in a federation of other devices by both exchanging data as well as performing tasks on behalf of other members.To enable this functionality,each PnP device must conceptually be able to

1.Announce it presence and capabilities to the federation

2.Discover who else is a member of the federation

3.Selectively interact with other members of the federation as required to perform its function

Fault tolerance is a by-product of the last two items above,in that when a device that you're talking to"goes away",you're able to immediately find another one to take its place and resume your activities.

JINI provides the capability to support a semi-autonomous level of device interaction.It is a dynamic distributed network architecture for providing spontaneous networking of services.JINI was originally designed to plug

computers,printers and other peripherals into a network allowing seamless configuration and interaction between them.Since then,this notion of interoperability has been extended to quite general service-based architectures that need to operate in dynamically changing environments where services can seamlessly come and go without degrading system performance.With this capability,an integration of a JINI-based network architecture with the reference service-based spacecraft architecture described earlier provides us with the foundation for our PnP Flight Software System.

Figure4below shows a simple example of how JINI works in practice.First,a new service for a device registers itself with a lookup server in order to advertise its capabilities to any client.Next,an interested client(it could be an application or another device)finds the appropriate service and gets a handle,i.e.a proxy,to the https://www.sodocs.net/doc/6f7883624.html,stly,the client can interact with the service through this proxy,such as getting data or commanding the device associated with the service.

Figure4.JINI Discovery,Join,Lookup,Service Invocation sequence

JINI-based Prototype Development

As discussed above,wrapping devices as JINI services means flight software can be composed using networking as inter-device communication.If active,each device will register with the JINI repository.The repository keeps track of active devices.It also acts to help the discovery mechanism to find devices.For example,a software application can query the repository to discover all gyroscopes that are active,where they are located in the spacecraft and what are the current values.The software application,which can be part of the attitude control software,can process the gyroscope data and produce a new value to be fed into some actuator,which is also a JINI-based device.

The JINI service definition are derived from the SPA's XTEDs.Because an XTED is in XML format,an XML parser converts the XTED's parameter and command definition to JINI attributes and methods.Moreover, configuration information from the XTED is embedded into the device JINI service in order to facilitate device searching.Device proxies are also generated in order for applications or other devices to communicate with a device.

In combination with JINI services,devices that serve data for hard real time routines can make use of features from the RTSJ.Among these are priority scheduling,asynchronous event handling,asynchronous transfer of control and memory allocation.The JINI protocol allows the remote invocation of the devices while the RTSJ handles latency.

IV.Example Spacecraft Scenarios

1.ASSEMBLY AND TEST OF A SPACECRAFT.First,the networked devices or subsystems are plugged-in. The JINI Server then tracks connections and the configuration information of each device,i.e.serial number,model number,category and functioning state.One application running on a Ground Support Equipment(GSE)is a Bill of Material(BOM)checker.The BOM check queries the JINI server for all connected devices and performs check if consistent with the BOM.Once checked with the BOM,the application calls each device to perform a self-test on

itself and report the result back to the BOM check application.Note that the BOM application could run on a wireless LAN PC and not networked with the spacecraft.See Figure5below.

Figure5.Example Scenario:Bill of Material Check using Plug-n-play technology

2.OPEN LOOP CONTROL.Sensor devices and an actuator are selected for this experiment.One sensor could be a networked camera.The actuator could be a reaction wheel that moves the spacecraft to some attitude.An application in the flight software talks to the camera sensor.Real-time image data from the camera is streamed to the application and is processed for attitude information.A corresponding motor value is computed and the application sends the value to the reaction wheel/motor JINI service which makes the spacecraft turn.

3.AUTOMATIC RECONFIGURATION FOR FAULT RECOVERY.Consider the case when there is a failure in subsystem in a spacecraft.During normal operation,part of the spacecraft is disabled.The JINI server detects several subsystems are offline.A flight control application was running that required the offline devices.The spacecraft is placed onto safe mode.Operator on the ground tells the spacecraft to find alternative devices for the flight control.The JINI server locates other suitable devices.It knows the configuration information of gyroscopes, its relative coordinate location in the spacecraft and applies them to the control equation in the flight control application.In essence,the JINI repository data is used to reprogram flight software.

Testbed Implementation

A Plug and Play spacecraft laboratory is setup at the LM ATC in Sunnyvale where the concepts are initially tested.Afterwards,experiments are conducted at the Hexpak laboratory at the LM ATC in Palo Alto11.The experimental systems include PC-104s connected by Ethernet and Wifi to a GSE.The IBM Real Time Java development suite is being used to prototype hard time flight code in conjunction with the JINI inter-device protocol.Several JINI-related tools,described below,are also developed to assist in PnP.

Service Parameters and Values

List of Services

It is envisioned that all networked devices and applications are communicating using the JINI distributed networking protocol,and the number will increase in size in a complex system.Accordingly,it is necessary to display the state of each service's parameters.In Figure6,the Data Manager displays the current timing parameters where the attributes of the services are shown.As a client to the JINI services,the Services Browser contacts each of the services and requests the current parameter information.Also,a prototype graphical view of time-based data and image data is presented in Figure7.More visualizations such as these form the basis of a JINI-based Ground Support Equipment.

Preview of Ground Support Equipment

Lastly,with a multitude of networked devices populating the spacecraft,a mechanism for quickly identifying or searching a specific device is needed.Figure8below is a prototype search engine to find PnP devices of interest where a search can be initiated by attribute value or name.

List of Services

Figure8.Service Search Engine

References

1AIAA SPA Committee on Standards,Draft Standards Development Guidebook For Space Plug And Play Avionics.

2AIAA SPA Committee on Standards,Draft Space Plug and Play Avionics-Universal Serial Bus(USB)Adaptation for Space Use.

3European Committee on Space Standards,ECSS-E50-12A,SpaceWire.

4AIAA SPA Committee on Standards,Draft Spacecraft Plug and Play Avionics Standard for Device Interfaces.

5AIAA SPA Committee on Standards,Draft Spacecraft Plug and Play Avionics Standard for the Satellite Data Model.

6Cannon,Scott,SDM Users Guide,URL:https://www.sodocs.net/doc/6f7883624.html,/~cannon/sdm/sdm.html[cited23April2006].

7AIAA SPA Committee on Standards,Draft Spacecraft Plug and Play Avionics Standard for Common Data Dictionary.

8Common Object Request Broker Architecture(CORBA),OMG,https://www.sodocs.net/doc/6f7883624.html,/gettingstarted/corbafaq.htm [cited23April2006].

9Jini Network Technology,URL:https://www.sodocs.net/doc/6f7883624.html,/software/jini/and https://www.sodocs.net/doc/6f7883624.html,/[cited23April2006]..

10Java Specification Request(JSR)-001,the Real-Time Specification for Java(RTSJ),URL: https://www.sodocs.net/doc/6f7883624.html,/j2se/realtime/index.jsp[cited23April2006].

Hicks,M.T.,Enoch,M.,Capots,L.H.,"HexPak Testbed Development",Paper No.RS4-2006-3006,4th Responsive Space Conference,Los Angeles,CA,Apr.2006.

第六节区域工业化与城市化进程教学设计

第六节区域工业化与城市化进程教学设计（第1课时） —以珠江三角洲为例【课程标准】 以某经济发达区域为例，分析该区域工业化和城市化的推进进程，以及在此过程中产生的问题，了解解决这些问题的对策措施。 【教学目标】 （一）知识与技能 1. 了解城市化的概念。 2. 了解珠江三角洲城市化的进程。 （二）过程与方法 1. 通过对珠江三角洲城市化进程、城市化分布等相关案例的剖析，提高学生从图文资料中提却地理信息的能力和分析问题、解决问题的能力。 2. 通过分析、讨论“工业对珠江三角洲城市化的推动作用”，来培养学生综合分析问题的能力。 （三）情感态度和价值观 1. 在案例的分析过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 2. 在分组辩论的过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 【教学重点】 1. 工业对珠江三角洲城市化的推动作用。 1. 培养学生的分析、解决问题的能力以及合作学习的能力 【教学方法】

1. 自主学习、合作学习与教师指导结合 2. 多媒体辅助教学法 【教学过程】 [导入新课] 对比深圳改革开放三十年前后的图片，提请学生思考是什么原因是深圳发展如此之快深圳发展成功的经验给我们什么启示带着这个问题我们来学习一下今天的内容——区域工业化与城市化进程。 [进入主题] 活动1：体会珠江三角洲的城市化水平 合作探究：对比P66图2-35和2-36，与1983年相比，到2002年珠江三角洲新增加的城市有哪些这种变化从哪些方面反映了城市化水平的提高自主学习：珠江三角洲城市化水平较高的表现。 活动2：分析珠江三角洲城市化快速发展的原因 读下列资料，获取、提炼并归纳促进珠江三角洲工业化和城市化快速发展的背景条件。 归纳：珠江三角洲的优势背景条件 国际背景：发达国家或地区产业结构调整（契机） 国内背景：我国改革开放的政策（先机） 全国最大的侨乡之一 良好的区位：包括优越的地理位置、交通便利、劳动力丰富且廉价、地价低廉、等条件。 思考：在以上优势条件中20世纪80年代促进珠三角工业化与城市化快速发展的关键条件是什么

第二章第六节区域工业化与城市化进程导学案（无答案）-河北省邢台市第二中学湘教版高二地理必修3

第二章第六节区域工业化与城市化进程 ----以珠江三角洲为例 【学习目标】 1.知道区域工业化和城市化之间的关系及它们对区域社会经济发展所起的作用。 2.比较归纳珠江三角洲地城市化进程的两个阶段主要发展特点和形成原因。 3.分析该区域工业化和城市化的推进过程产生的主要问题，知道解决这些问题的对策措施。 【预习案】 【本课时基础知识】（阅读课本后完成） 珠江三角洲位于省中南部，下游。珠江三角洲有狭义和广义之分，广义的珠三角包括地区在内，狭义的不包括。本课所讲的珠三角指狭义的珠江三角洲。 一、珠江三角洲工业化与城市化的区位优势： 1、优越的地理位置：南部，毗邻，靠近； 2、劳动力，地价； 3、便利； 4、国家的大力支持； 5、众多，便于引进资金和技术； 6、发达国家地区的； 7、低平，充足。 二、珠江三角洲城市化进程： 阶段城市化进程形成原因城市化进程特点 改革开放初期以发展为主导，工业企 业发展迅速，分布具 有广泛性，以 工业为主导 城乡融合，农业与非农产 业相混杂的 20世纪90年代中期以后 区域 (广州、深圳) 的辐射带动作用， 产业发展迅速。 以核心城市(广州)为中心 的 三、工业化对珠江三角洲城市化的推动作用： 1、珠三角工业发展第一阶段（1979年-1990年）：

①、原有工业基础薄弱、矿产资源贫乏、丰富→大力发展产业； ②、政策、优势→引进技术、资金、设备→大力发展加工厂； ③、改革开放的初期→外商投资规模。 2、珠三角工业发展第二阶段（1990年以后）： ①、政策优势不明显、经济发展带动→产业优势不明显→发展产业，进行产业； ②、发达国家和地区的新一轮→参与，进行→形成全国最大的基地。 3、工业化对珠三角城市化的推动作用： ①、工业化加速了向城市的集中； ②、工业化加速了向城市的集中； ③、工业化加速了的转变。[来源:学科网] 四、珠江三角洲的工业化和城市化问题： 1、问题： ①、层次偏低，以工业为主，高科技产业和服务业比重不高， 实力和队伍都处于劣势； ②建设相对落后； ③城镇和工业过度密集，大量占用，问题日趋严重。 2、治理措施： ①、调整，推动，加强地域分工； ②、完善区域，构建大珠江城市群； ③、加强城市的； ④、加强，改善城乡环境； 【探究案】 探究一：介绍一下珠江三角洲。（越全面越好）

【地理】湘教版必修3第二章第六节区域工业化与城市化进程——以珠江三角洲为例(教案)

第二章区域可持续发展 第六节区域工业化与城市化进程——以珠江三角洲为例 一、课程标准 ●以某经济发达区域为例，分析该区域工业化和城市化的推进过程，以及在此过程中产生的主要问题，了解解决这些问题的对策措施。 （1）标准解读 1）城市化最显著的特点是城市人口数量的不断增加和城市数量的增加；而城市人口数量的增加，则主要是由于为了满足第二、第三产业发展对劳动力的需求，农村人口向城市集中并向非农业活动转型；在此过程中，既包含着城市景观和城市地域推进等实体的变化过程，也包括城市经济、社会、技术变革在城市等级体系中的扩散并向乡村扩展，甚至城市文化、生活方式、价值观念等向乡村扩散等较为抽象的精神上的变化过程，也包括城市经济、社会、技术变革在城市等级体系中的扩散等较为抽象的精神上的变化过程。因此，城市化过程与经济发展——特别是第二、第三产业的发展是紧密相联系的。事实上，城市化是人类进入工业社会时代，社会经济的发展，农业生产比重下降，非农业生产的比重逐步上升，伴随着这种经济结构的变动，农业人口比重逐渐降低，城市人口比重逐步提高，居民的生活方式逐步向城市性状转化的过程。 2）一个国家的城市化水平受国土大小、人口的多寡、历史基础、自然资源、经济结构等诸多因素影响，但在所有因素中，城市化水平与经济发展水平之间的关系最为密切。可以说，城市化水平与经济发展水平之间是一种粗略的线性关系，即经济发展水平越高，城市化水平也越高，在我国，京津唐地区、长江三角洲地区、珠江三角洲地区是近年城市化发展最快而成为全国城市化水平最高的地区；这是与这些地区经济发展密切相关的。以长江三角洲地区为例，可以看清这种关系： 长江三角洲地区，土地面积仅占全国1%，人口约占全国的5.9%。东部沿海是大的经济带，沿长江又是一条大的经济带，长江三角洲正好是这两者的交汇点，这是区位方面的优势。该地区2000年的GDP占全国的17.2%，2002年的工业总产值占到了全国的21％。可说是我国经济最发达、最活跃的地区。长江三角洲地区城市化水平约已达到40％，15个地级以上城市，除泰州、舟山之外，均已达到中心城市规模，上海、杭州、南京等城市甚至开始出现城市郊区化的现象（上海市正在对郊区的100个城镇进行统一规划，到2020年，外环线外郊区人口约800万，其中600万为城镇人口）。拥有2500年历史的古城苏州今非昔比，“保留中心、发展两翼”的发展原则和正在规划的跨越金鸡湖发展方案，既保护了历史古城，又高速发展了现代经济。杭州则把萧山作为了其战略发展的后备地，向钱塘江南岸拓展，从“西湖时代”走向“钱塘江时代”。常州市向北拓展，把滨长江的武进纳入市区，使常州由内陆城市变为临江通海的港口城市）。可以说，长江三角洲地区已形成了大中小城市密集、中小城镇发育充分的“高密集、高城市化地区”。 长江三角洲地区城市化进程的加快，使沪宁杭公路、铁路和大运河沿线的9个城市基本连接成片，形成了完整的都市群。这个都市群以上海为龙头、与全球互动，产业、金融、贸易、教育、科技、文化等实力雄厚，对于带动长江流域经济的发展，连接国内外市场，吸引海外投资，推动产业与技术转移，参与国际竞争与区域重组具有重要作用。特别是，上海作为国际性大都市已初具框架，“区域城市网络”正在浮现，共同构成一个面向全球市场的一体化城市地区。 3）城市化的发展过程中也会产生某些问题，如环境问题、水资源供给问题、就业问题，等等。关于城市化过程中的环境问题，应采取边发展、边治理的办法。其中包括按照环境保护的要求，合理规划城市布局，并把绿化等纳入城市发展规划；制定有关的政策法规，控制污染的排放；等等。关于水资源的供给问题，可优先发展高科技、高附加值、低耗水的经济

《区域工业化与城市化》教学设计

《区域工业化与城市化》教学设计 —以珠江三角洲为例 开封二十五中栗宁 一、课程标准 以某经济发达区域为例，分析该区域工业化和城市化的推进过程，以及在此过程中产生的主要问题，了解解决这些问题的对策措施。 二、教材分析： 本节教材内容分为三部分：一、是珠江三角洲发展条件，二、工业、城市化的进程，三、是珠江三角洲的工业化和城市化问题。 本节教材的重点是：工业对珠江三角洲城市化的推动作用和珠江三角洲的工业化和城市化的问题。难点是城市如何走可持续发展的道路，今后城市应如何发展。 三、教学目标： （一）知识与技能 1. 了解城市化的概念。 2. 了解珠江三角洲城市化的进程。 （二）过程与方法 1.通过对珠江三角洲城市化进程、城市化分布等相关案例的剖析，提高学生从图文资料中提却地理信息的能力和分析问题、解决问题的能力。 2. 通过分析、讨论“工业对珠江三角洲城市化的推动作用”，来培养学生综合分析问题的能力。 3. 通过对珠三角和长三角的辩论活动，培养学生探究问题和合作学习的能力。 （三）情感态度和价值观 1. 在案例的分析过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 2. 在分组辩论的过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 3. 通过课堂上对长三角地区的了解，让学生更加热爱自己的家乡。 四、教学重点： 1. 工业对珠江三角洲城市化的推动作用。 五、教学难点： 1. 培养学生的分析、解决问题的能力以及合作学习的能力 六、教学方法： 1. 自主学习、合作学习与教师指导结合 2. 多媒体辅助教学法 七、教学过程： [导入新课] 以歌曲“春天的故事”导入。 师：这首“春天的故事”好听吗？ 生：…… 师：在这个美丽的故事中，记述了一件事情，让我们的祖国从此开始了翻天覆地的变化，事情很简单是一位老人在海边画了一个圈。这位老人是谁呢？ （展示邓小平的图）

重庆市高二地理必修三第四章第二节《区域工业化与城市化》全套教案

4.2 区域工业化与城市化进程 一、课程标准 以某经济发达区域为例，分析该区域工业化和城市化的推进过程，以及在此过程中产生的主要问题，了解解决这些问题的对策措施。 二、教材分析： 本节教材注重学习影响城市工业化和城市化因素、进程以及产生的问题和解决的对策。重点在于对城市工业化和城市化的进程及促进条件的理解。本节内容以珠江三角洲为例，通过此案例对“区域工业化与城市化进程”等问题进行了剖析。运用图表和阅读资料了解珠江三角洲工业和城市化发展的基本概况，并通过对活动的探究和分析珠江三角洲工业化和城市化的区位条件，并通过与其他地区发展模式的对比理解推动城市化发展的动力差异。 本节教材内容分为三部分。一、对外开放的前沿，主要探讨珠江三角洲工业化城市化发展的区位因素二、工业对珠江三角洲城市化的推进，珠江三角洲不同阶段主导产业及工业特点探讨珠江三角洲工业化工业化发展的进程及影响其发展的因素，并在工业化发展的基础上理解工业化对城市化的促进作用。三、问题和对策，主要探讨珠江三江洲工业化和城市化进程过程中出现的问题针对问题提出解决的措施。 本节教材的重点是工业对珠江三角洲城市化的推动作用和珠江三角洲的工业化和城市化的问题。难点是城市如何走可持续发展的道路，今后城市应如何发展。 三、教学目标： （一）知识与技能 1. 了解城市化的概念。 2. 了解珠江三角洲城市化的进程。 （二）过程与方法 1.通过对珠江三角洲城市化进程、城市化分布等相关案例的剖析，提高学生从图文资料中提却地理信息的能力和分析问题、解决问题的能力。 2. 通过分析、讨论“工业对珠江三角洲城市化的推动作用”，来培养学生综合分析问题的能力。 3. 通过对珠三角和长三角的辩论活动，培养学生探究问题和合作学习的能力。（三）情感态度和价值观 1. 在案例的分析过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 2. 在分组辩论的过程中，激发学生探究地理问题的兴趣和动机，养成求实、求真的科学态度。 3. 通过课堂上对长三角地区的了解，让学生更加热爱自己的家乡。 四、教学重点： 1. 工业对珠江三角洲城市化的推动作用。 五、教学难点： 1. 培养学生的分析、解决问题的能力以及合作学习的能力 六、教学方法： 1. 自主学习、合作学习与教师指导结合

第六节区域工业化与城市化进程知识结构学案

第六节区域工业化与城市化进程知识结构 学案 学习重点 把握通过不同历史时期珠江三角洲不同的工业化和城市化的进程特点；理解珠江三角洲地区工业化进程呈现的发展阶段，特点及对城市化的影响。 学习目标 了解区域工业化和城市化之间的关系，以及它们对区域社会经济发展所起的作用。 比较归纳珠江三角洲地城市化进程的两个阶段主要发展特点和形成原因。 比较珠江三角洲地区工业化进程的两个主要阶段，归纳出不同时期的主要发展特点，并能够结合具体案例分析工业化进程对城市化的巨大推动。 分析珠江三角洲地区工业化和城市化过程中的问题，并尝试评价目前的一些调整措施和发展方向。 学习提纲 珠江三角洲的地理位置和范围： 珠江三角洲位于广东省，珠江。包括、、、 、、等市的全部和、的部分县市。广义的珠江三角洲还包括、。

一、珠江三角洲的城市化进程 阶段改革开放初期20世纪90年代中期以后 形成原因以发展为主导，发展迅速，分布具有性辐射带动作用 进程特点结合，农业与非农产业相混杂的城乡一体化形成以为中心的和城镇高度密集的体系 珠江三角洲城市化水平较高的四个方面表现：一是。城镇人口比重高达。二是。三是 。四是。 二、工业化对珠江三角洲城市化的推动作用 珠江三角洲的工业发展： 工业化进程存在问题解决措施 夯实基础阶段稳步发展阶段 0世纪年代以来，大力发展“三来一补”企业。在引进、和 方法的优势下，发展了以的多种和制造业，形成了以工业为主的轻型工业体系20世纪年代以后，工业发展在高速度的基础上更加注重和， 得到优化调整，技术水平明显提高，速度保持较高水平不足， 有限发展泛珠江三角洲经济区，扩大经济腹地 泛珠三角区域包括福建、江西、、广东、、、四川、、

第六节-区域工业化与城市化进程(教学设计)

第六节区域工业化与城市化进程教学设计（第一课时) —以珠江三角洲为例 新华爱心高级中学高一地理组 主讲人：任磊 一、课程标准 以某经济发达区域为例，分析该区域工业化和城市化的推进过程,以及在此过程中产生的主要问题,了解解决这些问题的对策措施。 二、教学指导意见 基本要求: 1．了解珠江三角洲城市化进程。 2. 理解工业化对珠江三角洲城市化的推动作用，用联系的观点、综合的观点分析实际问题。 3. 了解珠江三角洲工业化和城市化过程中存在的问题,探讨解决问题的措施，树立正确的人口观、环境观和发展观。 发展要求： 理解城市化与区域经济发展（特别二、三产业的发展）的相互关系;并能结合本地或我国某区域的实际,进行科学分析、找出存在的问题，寻求解决的办法。 说明： 案例的选择可灵活处理,可选择其他学生熟悉或感兴趣的案例替代，案例材料中的知识不作记忆性的考试要求。 三、会考要求: １. 珠江三角洲城市化进程 a ２. 珠江三角洲城市化水平的具体表现 a 3. 工业化对珠江三角洲城市化的推动作用ｂ 4. 珠江三角洲工业化和城市化中存在的问题 b 5．解决工业化和城市化过程中存在问题的措施 c 四、教材分析: 本节教材注重学习城市化进程和城市化问题。城市的合理分布和发展,对促进社会经济的发展有着十分重要的意义。但是,城市在积极推动社会经济发展的同时,也会带来某些消极影响。本节内容以珠江三角洲为例，通过此案例对“区域工业化与城市化进程”等问题进行了剖析。目的在于培养学生观察问题、发现问题、分析问题、解决问题的能力以及培养学生自觉维护和美化环境的良好品德。 本节教材内容分为三部分:一、是珠江三角洲城市化进程,二、工业对珠江三角洲城市化的作用，三、是珠江三角洲的工业化和城市化问题。 本节教材的重点是：工业对珠江三角洲城市化的推动作用和珠江三角洲的工业化和城市化的问题。难点是城市如何走可持续发展的道路，今后城市应如何发展。 五、教学目标: （一）知识与技能 １. 了解城市化的概念。 2. 了解珠江三角洲城市化的进程。 （二)过程与方法 1.通过对珠江三角洲城市化进程、城市化分布等相关案例的剖析,提高学生从图文资料中提却地理信息的能力和分析问题、解决问题的能力。